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>
This mostly upgrades transmission, and does some very minor touchups on
AppArmor support.
In particular, there is now no need to ever specify the umask as part of
the settings, as it will be mixed in by default (which is essentially
always what you want). Also, the default configuration is now more
sensible: Downloads are put in /var/lib/transmission/Downloads, and
incomplete files are put in /var/lib/transmission/.incomplete - this
also allows easy use of file syncing probrams, like BitTorrent Sync.
Finally, this unconditionally enables the AppArmor profiles for the
daemon, if AppArmor is enabled - rather than letting the user specify
profile support, it's best to default to supporting profiles for daemons
transparently in all places.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
Previously we were setting GRKERNSEC_PROC_USER y, which was a little bit
too strict. It doesn't allow a special group (e.g. the grsecurity group
users) to access /proc information - this requires
GRKERNSEC_PROC_USERGROUP y, and the two are mutually exclusive.
This was also not in line with the default automatic grsecurity
configuration - it actually defaults to USERGROUP (although it has a
default GID of 1001 instead of ours), not USER.
This introduces a new option restrictProcWithGroup - enabled by default
- which turns on GRKERNSEC_PROC_USERGROUP instead. It also turns off
restrictProc by default and makes sure both cannot be enabled.
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>
This module adds the security.duosec attributes, which you can use to
enable simple two-factor authentication for NixOS logins.
The module currently provides PAM and SSH support, although the PAM unix
system configuration isn't automatically dealt with (although the
configuration is automatically built).
Enabling it is as easy as saying:
security.duosec.ssh.enable = true;
security.duosec.ikey = "XXXXXXXX...";
security.duosec.skey = "XXXXXXXX...";
security.duosec.host = "api-XXXXXXX.duosecurity.com";
security.duosec.group = "duosec";
which will enforce two-factor authentication for SSH logins for users in
the 'duosec' group.
This requires uid/gid support in the environment.etc module.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
- It now uses JavaScript for configuration (only),
so I had to "convert" config for NetworkManager.
- I tested suspend/restart/(un)mount on KDE/Xfce,
Phreedom tested NetworkManager config conversion.
Sshd *must* use PAM because we depend on it for proper session
management. The original goal of this option (disabling password
logins) can also be implemented by removing pam_auth authentication
from sshd's PAM service.
That is, you can say
security.pam.services.sshd = { options... };
instead of
security.pam.services = [ { name = "sshd"; options... } ];
making it easier to override PAM settings from other modules.
