This allows to create overlayfs mounts by unprivileged containers (i.e.
in user and mount namespace). It's super-useful for containers.
The patch is trivial as I understand from the patch description it's
does not have security implications (on top of what user namespaces
already have). And it's enabled in ubuntu long time ago. Here is a proof:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1357025
This provides support for Ubuntu Fan Networking [1].
This includes:
* The fanctl package, and a corresponding NixOS service.
* iproute patches.
* kernel patches.
closes#9188
1: https://wiki.ubuntu.com/FanNetworking
This updates the new stable kernel to 3.14, and the new testing kernel
to 3.15.
This also removes the vserver kernel, since it's probably not nearly as
used.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
AppArmor only requires a few patches to the 3.2 and 3.4 kernels in order
to work properly (with the minor catch grsecurity -stable includes the
3.2 patches.) This adds them to the kernel builds by default, removes
features.apparmor (since it's always true) and makes it the default MAC
system.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
kernels:
- longterm: 3.4.87 -> 3.4.88
- longterm: 3.10.37 -> 3.10.38
- stable: 3.13.10 -> 3.13.11
- stable: 3.14.1 -> 3.14.2
grsecurity:
- test: 3.0-3.14.1-201404241722 -> 3.0-3.14.2-201404270907
NOTE: technically the 3.13 stable kernel is now EOL. However, it will
become the long-term grsecurity stable kernel, and will have ongoing
support from Canonical.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This module implements a significant refactoring in grsecurity
configuration for NixOS, making it far more usable by default and much
easier to configure.
- New security.grsecurity NixOS attributes.
- All grsec kernels supported
- Allows default 'auto' grsec configuration, or custom config
- Supports custom kernel options through kernelExtraConfig
- Defaults to high-security - user must choose kernel, server/desktop
mode, and any virtualisation software. That's all.
- kptr_restrict is fixed under grsecurity (it's unwriteable)
- grsecurity patch creation is now significantly abstracted
- only need revision, version, and SHA1
- kernel version requirements are asserted for sanity
- built kernels can have the uname specify the exact grsec version
for development or bug reports. Off by default (requires
`security.grsecurity.config.verboseVersion = true;`)
- grsecurity sysctl support
- By default, disabled.
- For people who enable it, NixOS deploys a 'grsec-lock' systemd
service which runs at startup. You are expected to configure sysctl
through NixOS like you regularly would, which will occur before the
service is started. As a result, changing sysctl settings requires
a reboot.
- New default group: 'grsecurity'
- Root is a member by default
- GRKERNSEC_PROC_GID is implicitly set to the 'grsecurity' GID,
making it possible to easily add users to this group for /proc
access
- AppArmor is now automatically enabled where it wasn't before, despite
implying features.apparmor = true
The most trivial example of enabling grsecurity in your kernel is by
specifying:
security.grsecurity.enable = true;
security.grsecurity.testing = true; # testing 3.13 kernel
security.grsecurity.config.system = "desktop"; # or "server"
This specifies absolutely no virtualisation support. In general, you
probably at least want KVM host support, which is a little more work.
So:
security.grsecurity.enable = true;
security.grsecurity.stable = true; # enable stable 3.2 kernel
security.grsecurity.config = {
system = "server";
priority = "security";
virtualisationConfig = "host";
virtualisationSoftware = "kvm";
hardwareVirtualisation = true;
}
This module has primarily been tested on Hetzner EX40 & VQ7 servers
using NixOps.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
In most cases, this just meant changing kernelDev (now removed from
linuxPackagesFor) to kernel.dev. Some packages needed more work (though
whether that was because of my changes or because they were already
broken, I'm not sure). Specifics:
* psmouse-alps builds on 3.4 but not 3.10, as noted in the comments that
were already there
* blcr builds on 3.4 but not 3.10, as noted in comments that were
already there
* open-iscsi, ati-drivers, wis-go7007, and openafsClient don't build on
3.4 or 3.10 on this branch or on master, so they're marked broken
* A version-specific kernelHeaders package was added
The following packages were removed:
* atheros/madwifi is superceded by official ath*k modules
* aufs is no longer used by any of our kernels
* broadcom-sta v6 (which was already packaged) replaces broadcom-sta
* exmap has not been updated since 2011 and doesn't build
* iscis-target has not been updated since 2010 and doesn't build
* iwlwifi is part of mainline now and doesn't build
* nivida-x11-legacy-96 hasn't been updated since 2008 and doesn't build
Everything not specifically mentioned above builds successfully on 3.10.
I haven't yet tested on 3.4, but will before opening a pull request.
Signed-off-by: Shea Levy <shea@shealevy.com>
it helps, but is incomplete.
more fixes are coming, but including these would change too much
generic btrfs code, which might cause trouble for others.
so the best advice is not to use btrfs send yet and wait for 3.11 or 3.12
It has been submitted for inclusion in mainline, so it will probably
make it into 3.11 (or 3.12 as 3.11 is fairly close to release).
It is very local, only affecting people who use the "send" feature.
Without it, send is unstable/unsafe to use incrementally.
It can probably be applied to 3.9 and 3.8 as well, but as I only
tested it against 3.10, so I didn't bother.
(less sigill, less sigbus). Related to bad handling of FPU instructions.
I apply them only to linux 3.4, although I think they can apply to many older kernels too.
svn path=/nixpkgs/trunk/; revision=34522
This incorporates the btrfs fix, so remove that patch. Also, I will test
that this builds after committing, and fix it if it fails
svn path=/nixpkgs/trunk/; revision=33885
This should solve the problem I had, where I could not boot either 3.3 or 3.3.1
in my system, as I got ENOSPC all the time.
svn path=/nixpkgs/trunk/; revision=33714
The patch is currently being discussed on LKML and hopefully will be included
in mainline in some form in the future. Note that booting from the livecd has
to do a lot of work before anything is output to the console, so if the drive
is still busy don't assume the boot has hanged
svn path=/nixpkgs/trunk/; revision=33235
Not merged r32497 (tree conflict, glibc GNU Hurd update). Ludovic, could you
please look at this?
svn path=/nixpkgs/branches/stdenv-updates/; revision=32520
Renamed cifs-timeout-2.6.32 patch to cifs-timeout-2.6.29 as this is the
older kernel version this patch applies to.
svn path=/nixpkgs/trunk/; revision=27711
Currently suffixed with 2.6.32.
This pre-patch prepares the landing of several versions of this patch to
support other Linux kernel versions.
svn path=/nixpkgs/trunk/; revision=27709
This patch adds a "features.aufs2_1" to the aufs-2.1 patch for Linux
2.6.37 to prevent aufs2_1 and aufs2_1_util from being options for
kernels without an aufs 2.1 patch. There were several Hydra build
failures as a result of attempting to build aufs2.1 against older
kernels.
svn path=/nixpkgs/trunk/; revision=26597
* My motivation for this patch is that kernels < 2.6.36 contain an
e1000e that does not support the ethernet card that is part of the
chipset for the second-generation Core-i Intel CPUs, so in order
to have a more useful livecd I needed to get aufs working with a
newer kernel, and 2.6.37 is the latest kernel with an official
aufs release.
* All sources are downloaded with fetchgit. This is because the aufs
upstream doesn't provide release tarballs, they just add a tag to
their git tree for an official release.
* The make target for the aufs2.1 headers uses a Makefile in the
kernel build directory that requires that unifdef be in the
scripts/ subdirectory of the build directory. The way I've dealt
with this here is by adding "make $makeFlags -C scripts unifdef"
to the postBuild in the kernel builder. Since the builder is used
by all kernel versions, this will require rebuilding every kernel
and kernel-dependent package if the patch is accepted, so one
alternative I thought of would be to create a fake kernel build
directory where everything is symlinked to the real build
directory except scripts/, which is first copied and then make
unifdef is run before building aufs2.1. If that more complicated
solution is preferred, or if anyone has ideas for another one, I
can do that and submit a new patch.
* The patch was tested by building a livecd ISO that uses it, then
running the ISO from within virtualbox and installing aufs2.1-util
from within the livecd environment.
* The livecd was built using installation-cd-minimal.nix, with two
changes to the Nixos tree:
1. boot.kernelPackages = pkgs.linuxPackages_2_6_37 was added to
profiles/minimal.nix
2. config.boot.kernelPackages.aufs2 was changed to
config.boot.kernelPackages.aufs2_1 in iso-image.nix
I would have preferred to keep all changes within
profiles/minimal.nix, but I couldn't figure out how to override
iso-image.nix's definition of boot.extraModulePackages. Livecds
that use an older kernel can't be built with this iso-image.nix,
since we don't have aufs2.1 for them (just aufs2). If someone can
point me to how I can override things set in iso-image.nix, I'd
appreciate it.
make -C scripts unifdef compiles the unifdef application in the
scripts/ directory, and when Nix copies over the build tree to
$out/lib/modules/$version/build for kernel modules to reference, it
copies over all of scripts/ except the .o files. I can't speak for
other kernel versions, but at the least for 2.6.37.1 unifdef is not
built by default. If you look at the Makefile in scripts, unifdef is
listed under a comment saying that the following programs are only
built on-demand.
svn path=/nixpkgs/trunk/; revision=26548
