|
Message-ID: <20110629191615.GA9343@albatros> Date: Wed, 29 Jun 2011 23:16:15 +0400 From: Vasiliy Kulikov <segoon@...nwall.com> To: Andrew Morton <akpm@...ux-foundation.org> Cc: linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com, Greg Kroah-Hartman <gregkh@...e.de>, "David S. Miller" <davem@...emloft.net>, Arnd Bergmann <arnd@...db.de>, Alexey Dobriyan <adobriyan@...il.com>, linux-security-module@...r.kernel.org 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.