mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Morris <jmorris@namei.org>
To: Andrew Morton <akpm@osdl.org>,
	Olaf Dietsche <olaf+list.linux-kernel@olafdietsche.de>
Cc: Rolf Eike Beer <eike-kernel@sf-tec.de>,
	linux-kernel@vger.kernel.org, Stephen Smalley <sds@tycho.nsa.gov>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: Fw: [PATCH 2.6.16-rc1-git4] accessfs: a permission managing filesystem
Date: Tue, 31 Jan 2006 10:50:12 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0601311013490.21823@excalibur.intercode> (raw)
In-Reply-To: <20060130135315.47d08a28.akpm@osdl.org>


> Can you please include this patch in -mm, to give it wider testing?
> 
> Accessfs is a permission managing filesystem. It allows to control
> access to system resources, based on file permissions.  It also
> includes two modules.  One module allows granting capabilities based
> on user-/groupid. The second module allows to grant access to lower
> numbered IP ports based on user-/groupid.

I don't think this code is suitable for mainline inclusion.

The kernel already a mechanism for implementing extended security 
models for networking in SELinux,  which is far more general and also 
provides a system-wide approach where all security-relevant objects and 
subjects and the interactions between them are controlled.

Also, I think capabilities are inherently problematic in that here, they 
introduce a mechanism for unbounded privilege escalation.  Your security 
model is granting privileges to non-root processes, but not then providing 
any means to contain these privileges.

There are also a lot of hard-coded uid==0 assumptions in userspace which 
will break badly once you start handing out privileges to uid!=0 
processes.  With SELinux we see a lot of these userspace assumptions, 
although, because SELinux is restrictive (i.e. only further restricts 
access), they do not lead to privilege escalation.

This scheme does not integrate well with SELinux, which will be able to 
reject access requests before accessfs sees them; while accessfs will be 
able to reject access requests that SELinux has already granted.  These 
mechanism are also not aware of each other from a policy point of view.

Rather than proliferating new security models in the kernel such as these, 
which tend to be fairly narrowly focused, I think it would be better to 
look at how SELinux (which itself is a general purpose security framework) 
can be adapted to the same or similar purpose.

In this case, aside from the permissive nature of your security model 
(i.e. granting permissions instead of just restricting them), it seems 
that accessfs is primarily a policy interface.   It may be possible to 
achieve something very similar by creating a highly abstracted interface 
to SELinux policy.  Most or even all of which I think could be done in 
userspace.


- James
-- 
James Morris
<jmorris@namei.org>

           reply	other threads:[~2006-01-31 15:50 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20060130135315.47d08a28.akpm@osdl.org>]

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=Pine.LNX.4.64.0601311013490.21823@excalibur.intercode \
    --to=jmorris@namei.org \
    --cc=akpm@osdl.org \
    --cc=davem@davemloft.net \
    --cc=eike-kernel@sf-tec.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olaf+list.linux-kernel@olafdietsche.de \
    --cc=sds@tycho.nsa.gov \
    /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

all inboxes | Powered by JetHome®