[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
