Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 22 Nov 2011 14:07:03 +0400
From: Vasiliy Kulikov <>
To: Andrew Morton <>
	Alexey Dobriyan <>,
	Al Viro <>, "H. Peter Anvin" <>,
	Greg KH <>, Theodore Tso <tytso@....EDU>,
	Alan Cox <>,
	Linus Torvalds <>
Subject: Re: [RFC v2 1/3] procfs: parse mount options

Hi Andrew,

On Mon, Nov 21, 2011 at 16:34 -0800, Andrew Morton wrote:
> On Sat, 19 Nov 2011 15:01:26 +0400
> Vasiliy Kulikov <> wrote:
> > This patch adds support of procfs mount options.
> > Actual mount options are coming in the next patches.
> The patches look sane to me.

Thank you for the review!

> I assume that `mount -o remount' has been tested and works as expected?


> I also assume that any file which was opened prior to the remount will
> remain accessible to any process which has the fd.  Is this acceptable
> from a security/operational POV?

No, currently this "check permissions on open()" is violated at least in
getattr().  On each access the full permission checking is done.

It is trivial to fix (by moving hide_pid to inode), but does it worth it?
I see the scheme is totally constant during the system lifetime, i.e.
procfs policy is defined during the boot in boot mount scripts and is not
changed during the system lifetime at all.  I see it as an ability to
define different policies on per-container basis, but not a "change it
from time to time" thing.

If anybody see the case where it makes sense, I'll move hide_pid to

FWIW, in grsecurity it is a CONFIG_ option and there is no such problem
at all. :-)


Vasiliy Kulikov - 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.