Messages in this thread |  | | | Date | Wed, 29 Jun 2011 23:16:15 +0400 | | From | Vasiliy Kulikov <> | | Subject | Re: [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
|  |