linux-kernel - Re: [RFC v2 1/3] procfs: parse mount options

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Nov 2011 14:07:03 +0400
From:	Vasiliy Kulikov <segoon@...nwall.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	kernel-hardening@...ts.openwall.com, linux-kernel@...r.kernel.org,
	Alexey Dobriyan <adobriyan@...il.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	"H. Peter Anvin" <hpa@...or.com>, Greg KH <greg@...ah.com>,
	Theodore Tso <tytso@....EDU>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>
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 <segooon@...il.com> 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?

Yes.

> 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
inode.

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

Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/