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>
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 0194a44d63 because
it breaks udisks on 13.10 (e.g. running "udisks --enumerate" will
print "Unit udisks.service failed to load").
(cherry picked from commit d7daf1a47f)
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>
