[kernel-hardening] Re: procfs mount options

[Vasiliy Kulikov <segoon@openwall.com>]

[-- Attachment #1: Type: text/plain, Size: 2243 bytes --]

Solar,

On Fri, Jun 03, 2011 at 23:11 +0400, Solar Designer wrote:
> I welcome suggestions on how to achieve the desired functionality for
> procfs in a non-confusing and generic way.  It should support the
> following reasonable configuration:
> 
> /proc/PID directories restricted to group proc (except for owners and
> root, indeed).  However, /proc/cpuinfo and the like unrestricted.
> Here's what this looks like on Linux 2.4.x-ow:
> 
> dr-xr-x---  3 root    proc         0 Jun  3 22:59 1
> ...
> dr-xr-x---  3 syslogd proc         0 Jun  3 22:59 205
> dr-xr-x---  3 klogd   proc         0 Jun  3 22:59 211
> ...
> -r--r--r--  1 root    proc         0 Jun  3 23:00 cpuinfo
> ...
> -r--------  1 root    proc 536743936 Jun  3 23:00 kcore
> -r--------  1 root    proc         0 May  5 20:36 kmsg
> ...
> dr-xr-x---  5 root    proc         0 Jun  3 23:00 net
> ...
> -r--r--r--  1 root    proc         0 Jun  3 23:00 uptime
> -r--r--r--  1 root    proc         0 Jun  3 23:00 version
> 
> Perhaps gid=proc,umask=007 should result in the above for /proc/PID, but
> how do we justify it not affecting /proc/cpuinfo, uptime, version (and
> many others)?  How do we justify it nevertheless affecting /proc/net (or
> should another option do that)?

I think it should be done with separate mount options for /proc/self/net
(/proc/net is a symlink to /proc/self/net since net namespaces
introduction) and for /proc/PID.  All other files should be e.g.
chmod'ed go= and then some white list should be chmod'ed to the relaxed
perms.

> Indeed, we could set some of these perms with chmod post-mount, but as
> discussed this has drawbacks.

Where its drawbacks were discussed?  I cannot find anything on
owl-dev.  Do you mean some possible diffirences between procfs files
among different kernel versions?  If so, white list instead of black
list should partly solve it.

>  So ideally our preferred configuration
> (which will be the default on Owl) should be achievable with mount
> options alone.

At least for sysfs it is unreachable if we go in the current direction -
umask doesn't change perms of already created files, and additional
"chmod -R" is needed anyway.

Thanks,

-- 
Vasiliy

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]