Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 7 Nov 2011 23:54:28 +0400
From: Vasiliy Kulikov <>
To: Eric Paris <>
Cc:,,, Alexey Dobriyan <>,
	Andrew Morton <>,,
	Linus Torvalds <>
Subject: Re: Re: [PATCH] proc: restrict access to

On Mon, Nov 07, 2011 at 14:48 -0500, Eric Paris wrote:
> On Mon, Nov 7, 2011 at 2:29 PM, Vasiliy Kulikov <> wrote:
> > On Mon, Nov 07, 2011 at 11:18 -0800, H. Peter Anvin wrote:
> > As to procfs, I see no real need of adding mode/group mount option for
> > global procfs files (/proc/interrupts, /proc/stat, etc.) - it can be
> > done by distro specific init scripts (chown+chmod).  I don't mind
> > against such an option for the convenience, though.
> While possible, the chmod+chown 'solutions' just aren't as simple as
> you pretend.  Every time one creates a chroot environment and mounts
> /proc it has be manually fixed there as well.  Same thing with a
> container.

I admit I don't fully realize all possible containers' uses, but doesn't
procfs is mounted inside of containers for only restricted full-featured
Linux distros usermods with the whole init and init scripts set?  I
didn't see any consistent usages of procfs for other things, do they

Creating separate namespaces is very useful for additional daemon
restrictions like vsftpd does it, but procfs inside of such namespace is
obviously denied by design ;)

And as procfs is a one instance per pid namespace, it has the same
permissions in all mount points, so I see no problem with chroot
(however, I find chroot not very useful with procfs inside).


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.