Currently all Linux kernel security patch projects seem to be sleeping. There is no useful kernel patch that provides us with a decent patch set allowing us to strengthen the Linux kernel. Some years ago I was using Grsecurity, a wonderful solution to enforce security on 2.4.x kernels at that time. The project seems to be pretty dead by now.
During the last months I was using RSBAC, a great set of security enhancements to the 2.6.x kernels. RSBAC seems to be a great project and I like the way they provide pre-patched vanilla kernels. But again, reaction time is way too slow. Root exploits for Linux kernels seem to appear all the time and force a server administrator to react fast. The lately published vmsplice root exploit made me give up on RSBAC as it’s just always a step behind. I decided to switch back to self compiled vanilla kernels from kernel.org.
Besides that, all I was looking for was a tiny little kernel patch for user based process hiding. (check my previous article about process hiding in RSBAC)
Finally I found a simple way to accomplish this. Actually it is a simple patch nothing more than 6 lines found on the debian-kernel mailing list. The patch found in this thread was done for Linux kernel 2.6.23.8.
I’d like to provide you with an updated patch for the current stable kernel where the vmsplice root exploit should be fixed, 2.6.24.2 (UPDATED 2008-04-25: 2.6.24.5):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 |
diff -u8 -r linux-2.6.24.5/fs/Kconfig linux-2.6.24.5-prochide/fs/Kconfig --- linux-2.6.24.5/fs/Kconfig 2008-04-19 03:53:39.000000000 +0200 +++ linux-2.6.24.5-prochide/fs/Kconfig 2008-04-24 11:59:53.000000000 +0200 @@ -941,16 +941,46 @@ config PROC_VMCORE bool "/proc/vmcore support (EXPERIMENTAL)" depends on PROC_FS && EXPERIMENTAL && CRASH_DUMP default y help Exports the dump image of crashed kernel in ELF format. +choice + prompt "Restrict access to /proc/<pid>-dirs" + default PROC_PIDDIRS_UNRESTRICTED +config PROC_PIDDIRS_UNRESTRICTED + bool "no restriction" + depends on PROC_FS + help + Don't restrict access to /proc/<pid>-dirs, i.e. leave mode at 555 + respectively r-xr-xr-x . This is the traditional mode of operation. + + If unsure, say Y. +config PROC_PIDDIRS_RESTRICT_TO_UG + bool "restrict to user and group + depends on PROC_FS + help + Restrict access to /proc/<pid>-dirs to user and group, i.e. set mode + to 550 respectively r-xr-x--- . + + If unsure, say N. + +config PROC_PIDDIRS_RESTRICT_TO_U + bool "restrict to user + depends on PROC_FS + help + Restrict access to /proc/<pid>-dirs to user only, i.e. set mode to + 500 respectively r-x------ . + + If unsure, say N. +endchoice + config PROC_SYSCTL bool "Sysctl support (/proc/sys)" if EMBEDDED depends on PROC_FS select SYSCTL default y ---help--- The sysctl interface provides a means of dynamically changing certain kernel parameters and variables on the fly without requiring diff -u8 -r linux-2.6.24.5/fs/proc/base.c linux-2.6.24.5-prochide/fs/proc/base.c --- linux-2.6.24.5/fs/proc/base.c 2008-04-19 03:53:39.000000000 +0200 +++ linux-2.6.24.5-prochide/fs/proc/base.c 2008-04-24 11:59:53.000000000 +0200 @@ -2373,17 +2373,24 @@ { struct dentry *error = ERR_PTR(-ENOENT); struct inode *inode; inode = proc_pid_make_inode(dir->i_sb, task); if (!inode) goto out; - inode->i_mode = S_IFDIR|S_IRUGO|S_IXUGO; + #if defined CONFIG_PROC_PIDDIRS_UNRESTRICTED + inode->i_mode = S_IFDIR|S_IRUGO|S_IXUGO; + #elif defined CONFIG_PROC_PIDDIRS_RESTRICT_TO_UG + inode->i_mode = S_IFDIR|S_IRUSR|S_IRGRP|S_IXUSR|S_IXGRP; + #elif defined CONFIG_PROC_PIDDIRS_RESTRICT_TO_U + inode->i_mode = S_IFDIR|S_IRUSR|S_IXUSR; + #endif + inode->i_op = &proc_tgid_base_inode_operations; inode->i_fop = &proc_tgid_base_operations; inode->i_flags|=S_IMMUTABLE; inode->i_nlink = 5; #ifdef CONFIG_SECURITY inode->i_nlink += 1; #endif |
You see? Actually it’s just a six line patch of fs/proc/base.c.
It works like a charm. In make menuconfig you can setup process hiding under:
|
1 2 3 4 5 6 7 8 |
File systems ---> Pseudo filesystems ---> Restrict access to /proc/-dirs (restrict to user) ---> ( ) no restriction ( ) restrict to user and group (X) restrict to user |
Here’s my patch: prochide-patch_2.6.24.2.diff
UPDATED 2008-04-25: prochide-patch_2.6.24.5.diff
Feb 27, 2008 - 06:57 PM
Interesting hint, though I have no need for such a feature currently (maybe later). I use a Gentoo Xen kernel I customized – works pretty well. Cheers
Apr 06, 2008 - 12:34 AM
Actually RBSAC protects from vmsplice 😉
Proving new kernel support however for a project of this size is sometimes difficult for the few RSBAC developper. E.g. 2.6.24 (which has the vmsplice fix, if you aren’t willing to patch 2.6.23 yourself) introduced a whole new PID architecture using structs. This means changing the core way RSBAC identify processes.
It took 2 weeks to code.
IMHO this is rather fast, even if not acceptable for security. But in that case, you *should* use your distro kernels or kernel patches of course. Distro kernels are rarely bleeding edge, they simply patch them for the security issues found.
Although unlikely, if e.g. your patch has to change totally in the next kernel version you will feel the problem at it’s core.
Okt 08, 2011 - 12:19 PM
This patch works but it doesn’t show any defunct/zombie processes even if you started them. I don’t think that is the correct behavior. So, the state of the process needs to be checked before setting inode->i_mode. So if the process is a zombie, then the mode must be S_IFDIR|S_IRUGO|S_IXUGO regardless of what option was chosen.
Any ideas?