grsecurity: Kernel version mismatch

[aherrmann]

Hi,

I was trying out the grsecurity module and found that there is a mismatch in the kernel version and the grsecurity patch version. That is the case for both the stable, and testing(unstable) version. The problem also exists in the release-14.04 branch.

stable: kernel 3.14.14, but grsecurity patch 3.14.10

testing: kernel 3.15.7, but grsecurity patch 3.15.3

That mismatch triggers the assertion in the grsecurity package.

[vcunat]

AFAIK release-14.04 doesn't even contain the complex patches that allow packages work on a grsecurity-enabled kernel (pax-marking, etc.). They're considered too disruptive for inclusion in the stable release, I believe.

[thoughtpolice]

Thanks for the reminder; I need to update the latest kernel patches and whatnot soon (hopefully today)

@vcunat is right that you're far better off using master as opposed to release-14.04, since it has a lot of improvements to actually make things usable. Hopefully there will be prebuilt kernel packages soon as well.

[aherrmann]

Thanks for letting me know. I was using master first, but then switched to release because I thought master might be too unstable

On 1. August 2014 16:49:21 MESZ, "Vladimír Čunát" notifications@github.com wrote:

AFAIK release-14.04 doesn't even contain the complex patches that allow
packages work on a grsecurity-enabled kernel (pax-marking, etc.).
They're considered too disruptive for inclusion in the stable release,
I believe.

---

Reply to this email directly or view it on GitHub:
#3427 (comment)

[aherrmann]

@thoughtpolice I aligned the kernel version and grsecurity version in order to test it a little further. The corresponding nixpkgs are here. A simple test machine is given here.

Unfortunately, it fails to deploy due to an issue with apparmor. Here is the error message after a fresh create, and deploy:

vboxGuest> updating GRUB 2 menu...
vboxGuest> stopping the following units: get-vbox-nixops-client-key.service, local-fs.target, network-interfaces.target, remote-fs.target, systemd-sysctl.service, virtualbox.service
vboxGuest> activating the configuration...
vboxGuest> setting up /etc...
vboxGuest> starting the following units: default.target, encrypted-links.target, get-vbox-nixops-client-key.service, getty.target, ip-up.target, local-fs.target, multi-user.target, network-interfaces.target, network.target, paths.target, remote-fs.target, sockets.target, swap.target, systemd-sysctl.service, timers.target, virtualbox.service
vboxGuest> warning: the following units failed: apparmor.service
vboxGuest>
vboxGuest> ● apparmor.service
vboxGuest>    Loaded: loaded (/nix/store/7jgkyw4hzrwswh4cc0shqrq2nai4ypdb-unit/apparmor.service)
vboxGuest>    Active: failed (Result: exit-code) since Wed 2014-08-06 00:04:20 CEST; 85ms ago
vboxGuest>   Process: 2348 ExecStart=/nix/store/ykbrwy2c5wyf5a2yq0ys1m3dcl03rkn6-apparmor-2.8.3/sbin/apparmor_parser -rKv -I /nix/store/ykbrwy2c5wyf5a2yq0ys1m3dcl03rkn6-apparmor-2.8.3/etc/apparmor.d/ /nix/store/j1khg8q58yn0hlw4yw89chqrww1qxcpd-ping (code=exited, status=1/FAILURE)
vboxGuest>  Main PID: 2348 (code=exited, status=1/FAILURE)
vboxGuest>
vboxGuest> Aug 06 00:04:20 vboxGuest apparmor_parser[2348]: Warning: unable to find a suitable fs in /proc/mounts, is it mounted?
vboxGuest> Aug 06 00:04:20 vboxGuest apparmor_parser[2348]: Use --subdomainfs to override.
vboxGuest> Aug 06 00:04:20 vboxGuest systemd[1]: apparmor.service: main process exited, code=exited, status=1/FAILURE
vboxGuest> Aug 06 00:04:20 vboxGuest systemd[1]: Failed to start apparmor.service.
vboxGuest> Aug 06 00:04:20 vboxGuest systemd[1]: Unit apparmor.service entered failed state.
vboxGuest> error: unable to activate new configuration
error: activation of 1 of 1 machines failed (namely on ‘vboxGuest’)

journalctl says:

Aug 06 00:04:20 vboxGuest systemd[1]: Starting Apply Kernel Variables...
Aug 06 00:04:20 vboxGuest apparmor_parser[2327]: Warning: unable to find a suitable fs in /proc/mounts, is it mounted?
Aug 06 00:04:20 vboxGuest apparmor_parser[2327]: Use --subdomainfs to override.
Aug 06 00:04:20 vboxGuest VBoxService[2324]: VBoxService 4.3.12 r93733 (verbosity: 0) linux.amd64 (May 16 2014 14:14:24) release log
Aug 06 00:04:20 vboxGuest VBoxService[2324]: 00:00:00.000398 main     Log opened 2014-08-05T22:04:20.259230000Z
Aug 06 00:04:20 vboxGuest VBoxService[2324]: 00:00:00.001217 main     OS Product: Linux
Aug 06 00:04:20 vboxGuest VBoxService[2324]: 00:00:00.001755 main     OS Release: 3.4.67
Aug 06 00:04:20 vboxGuest VBoxService[2324]: 00:00:00.002056 main     OS Version: #1-NixOS SMP Thu Oct 24 13:12:48 UTC 2013
Aug 06 00:04:20 vboxGuest VBoxService[2324]: 00:00:00.002332 main     OS Service Pack: #1-NixOS SMP Thu Oct 24 13:12:48 UTC 2013
Aug 06 00:04:20 vboxGuest VBoxService[2324]: 00:00:00.002637 main     Executable: /nix/store/0x7gp1yi0pipmhd2qkwcm0qhr5l87bra-VirtualBox-GuestAdditio
Aug 06 00:04:20 vboxGuest VBoxService[2324]: 00:00:00.002638 main     Process ID: 2324
Aug 06 00:04:20 vboxGuest VBoxService[2324]: 00:00:00.002639 main     Package type: LINUX_64BITS_GENERIC
Aug 06 00:04:20 vboxGuest VBoxService[2324]: 00:00:00.008499 main     4.3.12 r93733 started. Verbose level = 0
Aug 06 00:04:20 vboxGuest systemd[1]: Started SCSI Link Power Management Policy.
Aug 06 00:04:20 vboxGuest systemd[1]: apparmor.service: main process exited, code=exited, status=1/FAILURE
Aug 06 00:04:20 vboxGuest systemd[1]: Failed to start apparmor.service.
Aug 06 00:04:20 vboxGuest systemd[1]: Unit apparmor.service entered failed state.
Aug 06 00:04:20 vboxGuest systemd[1]: Started Apply Kernel Variables.

/proc/mounts contains the following:

rootfs / rootfs rw 0 0
none /proc proc rw,relatime 0 0
none /sys sysfs rw,relatime 0 0
none /dev devtmpfs rw,relatime,size=51232k,nr_inodes=127240,mode=755 0 0
none /run tmpfs rw,relatime,size=256148k,mode=755 0 0
/dev/disk/by-label/nixos / ext4 rw,relatime,data=ordered 0 0
/dev/disk/by-label/nixos /nix/store ext4 ro,relatime,data=ordered 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=3,mode=620,ptmxmode=000 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/run/current-system/systemd/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
tmpfs /run/user/0 tmpfs rw,nosuid,nodev,relatime,size=102460k,mode=700 0 0

During an attempted reboot the kernel panics at start-up, giving the following message:

After a cold start the system boots and further deploy operations work. Though, this is a bit shaky.

If I comment out all the grsecurity stuff, then the machine is configured without any errors. Am I doing something wrong, or is it one of those places where grsecurity is not ready for production yet?

[lucabrunox]

Apart adapting the patches, can we keep around in nixpkgs a particular kernel version just for grsec? Shouldn't be that heavy for the nixos cache. Otherwise grsec will break very often.

[thoughtpolice]

Okay, I see what's going on here. CONFIG_GRKERNSEC_GID is set to the grsecurity ID (a pre-created group), but AppArmor probably isn't part of this group causing apparmor_parser to fail since it can't read /proc. Simple enough fix.

Keeping this open so I can fix it in #7220.

[Nekroze]

Hello, It has been a little while since this issue was last looked at but I have been experiencing the same issue as described in the OP. A version mismatch between the kernel and grsecurity patches.

I have been trying for awhile to get a match but I cannot make anything work. At present I am using nixos-unstable channel hoping that it will be fixed one day, but I thought I should lodge and issue or at least comment here that this is still a problem.

I would greatly appreciate any assistance and would like to thank everyone for their work on Nixos which is amazing.

[joachifm]

Closing, I believe this has been resolved by #13505