public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vasiliy Kulikov <segoon@openwall.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: kernel-hardening@lists.openwall.com,
	linux-kernel@vger.kernel.org,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	"H. Peter Anvin" <hpa@zytor.com>, Greg KH <greg@kroah.com>,
	Theodore Tso <tytso@MIT.EDU>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC v2 1/3] procfs: parse mount options
Date: Tue, 22 Nov 2011 14:07:03 +0400	[thread overview]
Message-ID: <20111122100703.GA3856@albatros> (raw)
In-Reply-To: <20111121163407.d8946ad8.akpm@linux-foundation.org>

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@gmail.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

      reply	other threads:[~2011-11-22 10:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-19 11:01 [RFC v2 1/3] procfs: parse mount options Vasiliy Kulikov
2011-11-19 11:02 ` [RFC v2 2/3] procfs: add hidepid= and gid= " Vasiliy Kulikov
2011-12-05 22:55   ` Hugh Dickins
2011-12-08 19:21     ` Vasiliy Kulikov
2011-11-19 11:02 ` [RFC v2 3/3] procfs: add documentation for procfs " Vasiliy Kulikov
2011-11-22  0:34 ` [RFC v2 1/3] procfs: parse " Andrew Morton
2011-11-22 10:07   ` Vasiliy Kulikov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111122100703.GA3856@albatros \
    --to=segoon@openwall.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=greg@kroah.com \
    --cc=hpa@zytor.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@MIT.EDU \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox