Note: You'll need to add the `_rofi` command to your config of rofi-pass
to make this release work. Refer to config.example for an example of
how this might look like. For more information on this change, see
75cf715158.
I've failed to figure out what why `paxtest blackhat` hangs the vm, and
have resigned to running individual `paxtest` programs. This provides
limited coverage, but at least verifies that some important features are
in fact working.
Ideas for future work includes a subtest for basic desktop
functionality.
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.
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.
This patch replaces the old grsecurity kernels with a single NixOS
specific grsecurity kernel. This kernel is intended as a general
purpose kernel, tuned for casual desktop use.
Providing only a single kernel may seem like a regression compared to
offering a multitude of flavors. It is impossible, however, to
effectively test and support that many options. This is amplified by
the reality that very few seem to actually use grsecurity on NixOS,
meaning that bugs go unnoticed for long periods of time, simply because
those code paths end up never being exercised. More generally, it is
hopeless to anticipate imagined needs. It is better to start from a
solid foundation and possibly add more flavours on demand.
While the generic kernel is intended to cover a wide range of use cases,
it cannot cover everything. For some, the configuration will be either
too restrictive or too lenient. In those cases, the recommended
solution is to build a custom kernel --- this is *strongly* recommended
for security sensitive deployments.
Building a custom grsec kernel should be as simple as
```nix
linux_grsec_nixos.override {
extraConfig = ''
GRKERNSEC y
PAX y
# and so on ...
'';
}
```
The generic kernel should be usable both as a KVM guest and host. When
running as a host, the kernel assumes hardware virtualisation support.
Virtualisation systems other than KVM are *unsupported*: users of
non-KVM systems are better served by compiling a custom kernel.
Unlike previous Grsecurity kernels, this configuration disables `/proc`
restrictions in favor of `security.hideProcessInformation`.
Known incompatibilities:
- ZFS: can't load spl and zfs kernel modules; claims incompatibility
with KERNEXEC method `or` and RAP; changing to `bts` does not fix the
problem, which implies we'd have to disable RAP as well for ZFS to
work
- `kexec()`: likely incompatible with KERNEXEC (unverified)
- Xen: likely incompatible with KERNEXEC and UDEREF (unverified)
- Virtualbox: likely incompatible with UDEREF (unverified)
This update was generated by hackage2nix v20160613 using the following inputs:
- Hackage: b9e58743e7
- LTS Haskell: 2a2cddb443
- Stackage Nightly: 4b8c8abac5
The `mk-ca-bundle.pl` script manages quite well using only curl but
fails without LWP being present due to a `use` statement. This removes
the Perl import of the LWP library and adds curl as a build input.
Without this patch, attempts to install at least some of the packages
that start to use setupHaskellDepends (mostly gtk-related packages)
results in collisions:
building path(s) ‘/nix/store/63k5smns43f5r2ad8wcc242x0gwd70m3-ghc-8.0.1’
collision between `/nix/store/k18i1nm5hgnb82y9w2g9hmlwhk3szjld-ghc-8.0.1/lib/ghc-8.0.1/Cabal-1.24.0.0/Distribution/Compat/Binary.dyn_hi' and `/nix/store/0rwhbwsg9kmywgbrib2bs29p2hmi80za-Cabal-1.24.0.0/lib/ghc-8.0.1/Cabal-1.24.0.0/Distribution/Compat/Binary.dyn_hi'
builder for ‘/nix/store/vrjkfpm8sb96m9i5k74h8vn0rwddgy4v-ghc-8.0.1.drv’ failed with exit code 25
This would appear to me to be a consequence of setupHaskellDepends
entries being added to propagateBuildInputs. It is sufficient in the
cases I'm familiar with (taffyBar), and I think correct, to simply add
it to the otherBuildInputs.
