Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

grsecurity: Kernel version mismatch #3427

Closed
aherrmann opened this issue Aug 1, 2014 · 8 comments
Closed

grsecurity: Kernel version mismatch #3427

aherrmann opened this issue Aug 1, 2014 · 8 comments
Assignees
@thoughtpolice
Labels
6.topic: kernel The Linux kernel

Comments

@aherrmann
Copy link
Member

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
Copy link
Member

vcunat commented Aug 1, 2014

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
Copy link
Member

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
Copy link
Member Author

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" [email protected] 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
Copy link
Member Author

@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:
kernel_panick

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
Copy link
Contributor

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 thoughtpolice self-assigned this Apr 14, 2015
@thoughtpolice
Copy link
Member

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.

@thoughtpolice thoughtpolice added the 6.topic: kernel The Linux kernel label Jun 1, 2015
@Nekroze
Copy link
Contributor

Nekroze commented Dec 14, 2015

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
Copy link
Contributor

joachifm commented Apr 3, 2016

Closing, I believe this has been resolved by #13505

@joachifm joachifm closed this as completed Apr 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@thoughtpolice thoughtpolice

Labels
6.topic: kernel The Linux kernel
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@thoughtpolice @joachifm @lucabrunox @aherrmann @Nekroze @vcunat