Previously, the list of CA certificates was generated with a perl script
which is included in curl. As this script is not very flexible, this commit
refactors the expression to use the python script that Debian uses to
generate their CA certificates from Mozilla's trust store in NSS.
Additionally, an option was added to the cacerts derivation and the
`security.pki` module to blacklist specific CAs.
It looks like the cpu type part of modalias might have changed, my
systems (4.4.20 and 4.7.2) show something like the following:
```
cpu:type:x86,ven0000fam0006mod003F:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0017,0018,0019,001A,001C,002B,0034,003B,003D,0068,006F,0070,0072,0074,0075,0076,007D,0080,0081,0089,008C,008D,0091,0093,0094,0095,0096,0097,0098,0099,009A,009B,009C,009D,009E,009F,00C0,00C5,0120,0123,0125,0127,0128,0129,012A,0140
```
Update the rngd modalias rule to match this so udev properly has
systemd start rngd.
This reverts commit 1010271c63.
This reverts commit e85e51d41f.
The first commit causes multiple regressions. The second commit tries to
fix the regressions, but does not catch all of them. There are multiple
failing tests, one of which is blocking a package update. That is not
acceptable for a cosmetic patch.
Regression introduced by 1010271c63.
This caused the line after using the loginuid module to be concatenated
with the next line without a newline.
In turn this has caused a lot of the NixOS VM tests to either run very
slowly (because of constantly hitting PAM errors) or simply fail.
I have tested this only with one of the failing NixOS tests.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The generated files in /etc/pam.d/ typically have a lot of empty lines
in them, due to how the generated Nix strings are joined together;
optional elements that are excluded still produce a newline. This patch
changes how the files are generated to create more compact,
human-friendly output files.
The change is basically this, repeated:
- ''
- ${optionalString use_ldap
- "account sufficient ${pam_ldap}/lib/security/pam_ldap.so"}
- ''
+ optionalString use_ldap ''
+ account sufficient ${pam_ldap}/lib/security/pam_ldap.so
+ ''
Before this commit updating /var/setuid-wrappers/ folder introduced
a small window where NixOS activation scripts could be terminated
and resulted into empty /var/setuid-wrappers/ folder.
That's very unfortunate because one might lose sudo binary.
Instead we use two atomic operations mv and ln (as described in
https://axialcorps.com/2013/07/03/atomically-replacing-files-and-directories/)
to achieve atomicity.
Since /var/setuid-wrappers is not a directory anymore, tmpfs mountpoints
were removed in installation scripts and in boot process.
Tested:
- upgrade /var/setuid-wrappers/ from folder to a symlink
- make sure /run/setuid-wrappers-dirs/ legacy symlink is really deleted
A new internal config option `fileSystems.<name>.early` is added to indicate
that the filesystem needs to be loaded very early (i.e. in initrd). They are
transformed to a shell script in `system.build.earlyMountScript` with calls to
an undefined `specialMount` function, which is expected to be caller-specific.
This option is used by stage-1, stage-2 and activation script to set up and
remount those filesystems. Options for them are updated according to systemd
defaults.
While useless, some builds may dabble with setuid bits (e.g.,
util-linux), which breaks under grsec. In the interest of user
friendliness, we once again compromise by disabling an otherwise useful
feature ...
Closes https://github.com/NixOS/nixpkgs/issues/17501
Closes#17460
Changed the wrapper derivation to produce a second output containing the sandbox.
Add a launch wrapper to try and locate the sandbox (either in /var/setuid-wrappers or in /nix/store).
This launch wrapper also sheds libredirect.so from LD_PRELOAD as Chromium does not tolerate it.
Does not trigger a Chromium rebuild.
cc @cleverca22 @joachifm @jasom
Enabling EFI runtime services provides a venue for injecting code into
the kernel.
When grsecurity is enabled, we close this by default by disabling access
to EFI runtime services. The upshot of this is that
/sys/firmware/efi/efivars will be unavailable by default (and attempts
to mount it will fail).
This is not strictly a grsecurity related option, it could be made into
a general option, but it seems to be of particular interest to
grsecurity users (for non-grsecurity users, there are other, more
immediate kernel injection attack dangers to contend with anyway).
The new module is specifically adapted to the NixOS Grsecurity/PaX
kernel. The module declares the required kernel configurations and
so *should* be somewhat compatible with custom Grsecurity kernels.
The module exposes only a limited number of options, minimising the need
for user intervention beyond enabling the module. For experts,
Grsecurity/PaX behavior may be configured via `boot.kernelParams` and
`boot.kernel.sysctl`.
The module assumes the user knows what she's doing (esp. if she decides
to modify configuration values not directly exposed by the module).
Administration of Grsecurity's role based access control system is yet
to be implemented.
The motivation is using sudo in chroot nix builds, a somewhat
special edge case I have and pulling system path into chroot
yields to some very nasty bug like
https://github.com/NixOS/nixpkgs/issues/15581
Previously:
$ cat /var/setuid-wrappers/sudo.real
/nix/store/3sm04dzh0994r86xqxy52jjc0lqnkn65-system-path/bin/sudo
After the change:
$ cat /var/setuid-wrappers/sudo.real
/nix/store/4g9sxbzy8maxf1v217ikp69c0c3q12as-sudo-1.8.15/bin/sudo
The chroot caps restriction disallows chroot'ed processes from running
any command that requires `CAP_SYS_ADMIN`, breaking `nixos-rebuild`. See
e.g., https://github.com/NixOS/nixpkgs/issues/15293
This significantly weakens chroot protections, but to break
nixos-rebuild out of the box is too severe.
This module adds an option `security.hideProcessInformation` that, when
enabled, restricts access to process information such as command-line
arguments to the process owner. The module adds a static group "proc"
whose members are exempt from process information hiding.
Ideally, this feature would be implemented by simply adding the
appropriate mount options to `fileSystems."/proc".fsOptions`, but this
was found to not work in vmtests. To ensure that process information
hiding is enforced, we use a systemd service unit that remounts `/proc`
after `systemd-remount-fs.service` has completed.
To verify the correctness of the feature, simple tests were added to
nixos/tests/misc: the test ensures that unprivileged users cannot see
process information owned by another user, while members of "proc" CAN.
Thanks to @abbradar for feedback and suggestions.
Add a module to make options to pam_oath module configurable.
These are:
- enable - enable the OATH pam module
- window - number of OTPs to check
- digits - length of the OTP (adds support for two-factor auth)
- usersFile - filename to store OATH credentials in
- Now `pkg.outputUnspecified = true` but this attribute is missing in
every output, so we can recognize whether the user chose or not.
If (s)he didn't choose, we put `pkg.bin or pkg.out or pkg` into
`systemPackages`.
- `outputsToLink` is replaced by `extraOutputsToLink`.
We add extra outputs *regardless* of whether the user chose anything.
It's mainly meant for outputs with docs and debug symbols.
- Note that as a result, some libraries will disappear from system path.
Part of the way towards #11864. We still don't have the auditd
userland logging daemon, but journald also tracks audit logs so we
can already use this.
Run pam_unix an additional time rather than switching it from sufficient
to required. This fixes a potential security issue for
ecryptfs/pam_mount users as with pam_deny gone, if cfg.unixAuth = False
then it is possible to login without a password.
- upgrade 106 -> 108
- fix passphrase rewrapper (password changing should now work fine) as
discussed on https://bugs.launchpad.net/ecryptfs/+bug/1486470
- add lsof dependency so ecryptfs-migrate-home should work out of the
box
Enables attaching AppArmor profiles at the user/group level.
This is not intended to be used directly, but as part of a
role-based access control scheme. For now, profile attachment
is 'session optional', but should be changed to 'required' once
a more comprehensive solution is in place.
This allows for module arguments to be handled modularly, in particular
allowing the nixpkgs module to handle the nixpkgs import internally.
This creates the __internal option namespace, which should only be added
to by the module system itself.
