This GID was used to exempt users from Grsecurity's
`/proc` restrictions; we now prefer to rely on
`security.hideProcessInformation`, which uses the `proc` group
for this purpose. That leaves no use for the grsecurity GID.
More generally, having only a single GID to, presumably, serve as the
default for all of grsecurity's GID based exemption/resriction schemes
would be problematic in any event, so if we decide to enable those
grsecurity features in the future, more specific GIDs should be added.
Option aliases/deprecations can now be declared in any NixOS module,
not just in nixos/modules/rename.nix. This is more modular (since it
allows for example grub-related aliases to be declared in the grub
module), and allows aliases outside of NixOS (e.g. in NixOps modules).
The syntax is a bit funky. Ideally we'd have something like:
options = {
foo.bar.newOption = mkOption { ... };
foo.bar.oldOption = mkAliasOption [ "foo" "bar" "newOption" ];
};
but that's not possible because options cannot define values in
*other* options - you need to have a "config" for that. So instead we
have functions that return a *module*: mkRemovedOptionModule,
mkRenamedOptionModule and mkAliasOptionModule. These can be used via
"imports", e.g.
imports = [
(mkAliasOptionModule [ "foo" "bar" "oldOption" ] [ "foo" "bar" "newOption" ]);
];
As an added bonus, deprecation warnings now show the file name of the
offending module.
Fixes#10385.
In this case, they're equivalent to setting ‘password’ and
‘hashedPassword’ (since there is no distinction between an initial and
non-initial user account state).
This hopefully fixes a regression introduced by 08b214a.
In bf129a2, it was already fixed for normal uid/gid values and it got
reintroduced by sub-uid/gid-handling again, so I've refactored it a bit
into a filterNull function which takes care of also the filtering
introduced by bf129a2.
I have not tested this extensively, but master is already broken for
systems with `mutableUsers = true` and no uid values set.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
With mutableUsers = true, we now ensure that all users and groups that
were created declaratively, are updated or removed
appropriately. Thus, adding a user to users.extraUsers and then
removing it now causes the acoount to be removed from
/etc/passwd. Thus user/group management is fully congruent except that
users and groups that were created imperatively (via useradd/groupadd)
are not touched. We distinguish between declarative and imperative
users/groups by tracking the former in
/var/lib/nixos/declarative-{groups,users}.
With mutableUsers = false, you are now no longer required to specify
UIDs/GIDs for all users. The handling of mutableUsers = true/false is
the same code path; the only difference is that the "false" mode
ignores the existing contents of /etc/{passwd,group}.
The attribute ‘createUser’ is gone. It doesn't really make sense to
specify users that shouldn't be created.
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.
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>
The mutableUsers feature uses `chpasswd` to set users passwords.
Passwords and their hashes were being piped into the program using
double quotes ("") to escape. This causes any `$` characters to be
expanded as shell variables. This is a serious problem because all the
password hash methods besides DES use multiple `$` in the hashes. Single
quotes ('') should be used instead to prevent shell variable expansion.
