lkml.org 
[lkml]   [2011]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options
On Wed, Jun 22, 2011 at 10:45 +0400, Vasiliy Kulikov wrote:
> > This all seems highly specific to one particular set of requirements.
>
> Yes, I admit this. The problem with procfs is that it's possible to
> chmod/chown some procfs files, but not /proc/PID/*. Even if make it
> possible to chmod/chown them (and introducing an inodes revalidation on
> execve() setuid and similar binaries) it is still racy - new processes
> would have /proc/PID/ and some files inside with perms=0555. So, for
> more generic mechanism something like umask is needed. The patch in
> question implements 2 border cases:
>
> 1) relaxed. umask=0555.
>
> 2) restricted. umask=0550 (with tricky gid) and files are still not
> chmod'able.
>
>
> More generic solution (I'm not suggesting it, but merely discussing)
> would use some user-supplied set of files to restrict access to (or,
> better, the set of allowed files because white list is almost always
> better than black list). Maybe this one:
>
> mount -t proc -o "pid_allow=exe,status,comm,oom_*" proc /proc

Does this scheme make sense? Should I rensend the patch with these
architecture?

pid_allow=, tid_allow=, attr_allow= and watch_gid= or smth like that.


Thanks,

--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments


\
 
 \ /
  Last update: 2011-06-29 21:19    [from the cache]
©2003-2011 Jasper Spaans