This now provides a handful of different grsecurity kernels for slightly
different 'flavors' of packages. This doesn't change the grsecurity
module to use them just yet, however.
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>
systemd-tmpfiles-setup.service pulls in local-fs.target, which
interferes with NixOps' send-keys feature (since sshd.service depends
indirectly on sysinit.target). Since in NixOS we don't use
systemd-tmpfiles for creating files (that's done by activation scripts
and preStart scripts), it's not a problem to start it a bit later.
Backport: 14.04
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>
Upstream has not been tagging new versions for a long time, but we need
compatibility with newer kernels. The 0.6.2 versions already have a bunch of
backported compatibility patches, but 3.14 kernels need even more.
Also, the git versions have fixed a bunch of crashes and other bugs, so perhaps
we should just bite the bullet and just use recent git versions (as sometimes
upstream recommends, when people run into bugs).
This adds a new "boot.zfs.useGit" boolean option, so that a user can
easily opt into using the git versions.
This creates static device nodes such as /dev/fuse or
/dev/snd/seq. The kernel modules for these devices will be loaded on
demand when the device node is opened.
Note that systemd no longer depends on dbus, so we're rid of the
cyclic dependency problem between systemd and dbus.
This commit incorporates from wkennington's systemd branch
(203dcff45002a63f6be75c65f1017021318cc839,
1f842558a95947261ece66f707bfa24faf5a9d88).
(And update liburcu to 0.8.4 according to release notes for lttng 2.4.x.)
In addition to new features and bug fixes, version 2.4.x is needed to build
against Linux 3.12 (our new stable kernel).
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>
Realistically, common-config is useful, but there are a lot of things in
there that are non-optionally specified that aren't always useful. For
example, when deploying grsecurity, I don't want the bluetooth,
wireless, or input joystick/extra filesystem stack (XFS, etc), nor the
staging drivers tree.
The problem is that if you specify this in your own kernel config in the
grsecurity module, by saying 'BT n' to turn off bluetooth,
common-config turns on 'BT_HCIUART_BCSP y', which then becomes unused
and errors out.
This is really just an arbitrary picking at the moment, but it should be
OK.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Lockdep doesn't *really* require the kernel package - just the kernel
sources. It's really a user-space tool just compiled from some portable
code within the kernel, nothing more.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
NB: This currently doesn't add a working musl-wrapper around musl-gcc to
allow it to work properly (musl has its own dynamic linker as well as
libc too which must be accounted for). But at the moment it builds fine,
and I plan on working more on it in the future. So lets get it
integrated and building on Hydra.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This reverts commit 0194a44d63c613065bb5c55d50470881c00563c2 because
it breaks udisks on 13.10 (e.g. running "udisks --enumerate" will
print "Unit udisks.service failed to load").
(cherry picked from commit d7daf1a47f0d3d759555a3f0a0f09398c69c6b28)
This is necessary for gradm's learning mode to work, as otherwise the
/nix/store directory is marked hidden, which causes the kernel to reject
the linker loading ld-linux.so
Signed-off-by: Austin Seipp <aseipp@pobox.com>
We alredy rewrote /sbin/gradm, which technically matches
/sbin/gradm_pam, so this ends up working exactly as we want. Otherwise
we rewrite twice and gradm can't execute the PAM module with '-p'
Signed-off-by: Austin Seipp <aseipp@pobox.com>
- longterm: 3.4.83 -> 3.4.85
- longterm: 3.10.33 -> 3.10.35
- longterm: 3.12.14 -> 3.12.15
- stable: 3.13.7 -> 3.13.8
NOTE: This will break the testing grsec kernel at the moment (there's
not a 3.13.8 patch yet), but it's destined to be upgraded to 3.14 soon
anyway.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
- longterm: 3.4.83 -> 3.4.85
- longterm: 3.10.33 -> 3.10.35
- longterm: 3.12.14 -> 3.12.15
- stable: 3.13.7 -> 3.13.8
NOTE: This will break the testing grsec kernel at the moment (there's
not a 3.18.8 patch yet), but it's destined to be upgraded to 3.14 soon
anyway.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Lockdep is the kernel's locking validation/debugging tool and has seen
heavy pro-active usage and development. In Linux 3.14, it's now
available directly to userspace for the same purpose. It comes with a
convenient utility to LD_PRELOAD a shared library for validation, or a
user-space API to link to directly.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Latest update to udisks in 344f2e65 broke it for me. Fix it by doing the
following:
- Add udisks.service to /etc/systemd/system (via systemd.packages)
- Fix path to udisks-daemon in udisks.service (libexec/ instead of lib/)
- Make dhcp work, use dhcpcd without udev in container
- Make login shell work, patch getty to not wait for /dev/tty0
- Make ssh work, sshd/pam do not start session
looking at our git history, I think it is very peculiar that we
managed to have this version (22.21) 2 months before release :)
So I think we were using some beta/rc that accidentally got called
22.21
CAN userspace utilities and tools (for use with Linux SocketCAN).
There is no real "homepage" for this project (the only thing I could
find was the gitorious page) and they haven't produced any proper
releases (source archives and/or git tags), even though git history goes
back to 2006 and things seem stable.
It turns out that some of gcc 4.8's aggressive optimizations may
cause minor filesystem corruption in ZFS. To fix it, a patch was
cherry-picked from the upstream's git tree.
See: https://github.com/zfsonlinux/zfs/pull/2051
