Package: linux-2.6 Severity: wishlist Tags: patch (resending without attachments so it's not too big for the list, they can be found on the bug report, sorry for the inconvenience) Hey people, First, please excuse me, I wasn't able to attend the Paris Miniconf and thus the kernel summit, to propose this at that time. In any case, it's not about Squeeze so there's still a lot of time to discuss this anyway. I'd like to propose adding a new featureset to Debian kernels for Wheezy, using grsecurity (http://www.grsecurity.net) patchset. == Introduction For people not familiar with grsecurity, the website as plenty of information, but it's basically a hardening patch for the Linux kernel, with major features beeing: * a role-based access control system * chroot() hardening * memory protection using PaX (address randomization, arbitrary code execution prevention...) * auditing On the long term the best would be to upstream those features mainline, and there's actually a process to do that from Ubuntu developers (https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening), but in the meantime having a grsecurity enabled kernel by default in Debian would be really nice, in my opinion. I know some people concerned about security have the habit to rebuild a vanilla kernel anyway, but I think some people and organization would be very interested by having a hardened kernel available in Debian, like virtual hosting companies etc. Doing it using a featureset is nice because it's not too intrusive (it's not the default, it has to be chosen explicitly by the user and it's a separate patch in the source package) and using the existing linux-2.6 package architecture it's actually quite easy. == Implementation Attached is a patch (against Debian linux-2.6 svn tree, for the 2.6.32-28 kernel, targeted to Squeeze) which do that. Basically it adds the latest grsecurity patch, defines the variants where it's used and the default config. So far I've only tested on i386 and amd64 so I didn't do anything on other architectures. The grsecurity patch itself has been edited because some of the files touched by the patch have already been patched by backports from latest kernel versions, for example. It's not really hard work to do, and it shouldn't be necessary for 2.6.36 kernel. The sha256sum of the edited patch is: 8df533f83817542277e34fed9ae766b9059a144a73fe536d003569b17ac03f1f grsecurity-2.2.0-2.6.32.25-201011151726+debian.patch and I've attached it to the bug so it's easier to look at it independantly of the svn patch. Packages based on Squeeze kernel are available on http://molly.corsac.net/~corsac/debian/kernel-grsec (it's apt-get'able for amd64 or the dsc is present for those who just want to look at the source package). == Configuration The KConfig is the one I use, which is open to discussion (like everything else anyway). I've tried to be fairly secure, so some features might not work for some people. When possible, options are configurable at runtime using sysctl. Attached is a tentative grsec.conf file to be put in /etc/sysctl.d so people can fine-tune their installation. I didn't find a way to ship it cleanly in a linux-image package so if anyone has an idea please say so. For example, I've set kernel.grsecurity.disable_priv_io=0 so Xorg with KMS works fine (it still won't work for non-KMS people though). Without that, Xorg will fail to start with: xf86EnableIOPorts: failed to set IOPL for I/O (operation not permitted) so it's still clear why this happen and it's easy to fix. I've tried to provide a default config which could fit for most people, but I think it should be tuned by users in the end, so besides the gids I'm not sure there's much to discuss. === Chroot chroot sysctls are all configured to 1, but for people working on Debian stuff, especially building in chroots, it might be a good idea to set: kernel.grsecurity.chroot_execlog=0 kernel.grsecurity.chroot_deny_chmod=0 === Trusted Path Execution Trusted Path Execution (TPE) is a way to restrict code execution. Basically, binaries execution is forbidden from paths not owned by root. It's configured using a GID (which I chose to be 500, once again it can and should be discussed), it and can be opt-in (users belonging to the group are prevented to execute “untrusted” binaries) or opt-out (only people belonging to the group can execute “untrusted” binaries). I chose the latter, to have a “secure by default” system. === Socket restrictions The same kind of restrictions exist on socket, gid-based again: when you add users to the relevant group, you deny them the right to create sockets. I've chosen gids 501, 502 and 503 for respectively “all” sockets, “client” sockets and “server” sockets. Once again, this is configurable using sysctls. == Maintenance While I'd like to participate in the upstreaming effort, as noted above I still think it'd be a good idea to have a grsecurity kernel for Wheezy. As it means more work for the kernel team, I volunteer to give help to handle that (in fact, I've already been following the linux-2.6 svn and the grsecurity release for some time). == Rebuild the kernel You can rebuild the kernel easily using the .dsc or using a linux-2.6 debcheckout. In the latter case, you have to apply the attached patch, then: * download linux-2.6.32.tar.z2 * python debian/bin/genorig.py ../linux-2.6.32.tar.bz2 * debian/rules orig * debian/rules debian/control * fakeroot debian/rules source * fakeroot make -f debian/rules.gen binary-arch_amd64_grsec_amd64 (or any other target) and follow the kernel handbook which is pretty nice: http://kernel-handbook.alioth.debian.org/ == Conclusion So, what do you think? Does it look like a good idea, are there some blockers, some implementation details to discuss? Any comment is welcome. Thanks anyway for your time. Regards, -- Yves-Alexis Perez -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-grsec-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
Attachment:
signature.asc
Description: This is a digitally signed message part