All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Stephen Smalley <sds@tycho.nsa.gov>, David Howells <dhowells@redhat.com>
Cc: viro@ftp.linux.org.uk, selinux@tycho.nsa.gov,
	LSM List <linux-security-module@vger.kernel.org>,
	James Morris <jmorris@namei.org>,
	Eric Paris <eparis@parisplace.org>
Subject: Re: SELinux security and passed file descriptors
Date: Fri, 31 Aug 2007 08:39:43 -0700 (PDT)	[thread overview]
Message-ID: <642474.66018.qm@web36605.mail.mud.yahoo.com> (raw)
In-Reply-To: <1188572504.26572.459.camel@moss-spartans.epoch.ncsc.mil>


--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On Fri, 2007-08-31 at 15:32 +0100, David Howells wrote:
> > Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > 
> > > That's how mandatory access control is supposed to work; otherwise, a
> > > flaw in A can leak the descriptor to B at will in violation of security
> > > policy.
> > 
> > Yeah, but by making it impossible to have the flaw, you've also made it
> > impossible for A to validly pass to B a file descriptor B wouldn't
> otherwise
> > be able to access directly, but should be able to access on behalf of A.
> 
> Let me say it again:  that's how mandatory access control is supposed to
> work.  A program (or user) isn't supposed to be able to delegate access
> under a mandatory policy.

Stephen is correct. Some of the Unix MLS systems went so far as to
prohibit passing file descriptors all together. The ability to pass file 
descriptors is one of those things that make one wonder what could
possibly have been going through the mind (or bloodstream) of the
original author. Yes, I understand that it is useful. It is also one
of those fringe cases that makes it really hard to protect a system
against clever programmers. SELinux currently treats the mechanism
with more respect than it needs to. I expect that in the grand scheme
of things we'd all be better off if the mechanism where abandoned
before the exploits get too thick and someone adds a half dozen layers
of complexity to address the issues one by one.

But, that's just me.





Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  reply	other threads:[~2007-08-31 15:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-30 15:12 SELinux security and passed file descriptors David Howells
2007-08-30 15:19 ` Stephen Smalley
2007-08-31 14:32   ` David Howells
2007-08-31 15:01     ` Stephen Smalley
2007-08-31 15:39       ` Casey Schaufler [this message]
2007-08-31 15:46       ` Mikel L. Matthews
2007-08-31 15:39     ` James Antill

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=642474.66018.qm@web36605.mail.mud.yahoo.com \
    --to=casey@schaufler-ca.com \
    --cc=dhowells@redhat.com \
    --cc=eparis@parisplace.org \
    --cc=jmorris@namei.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=viro@ftp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.