All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mikel L. Matthews" <mikel@argus-systems.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: David Howells <dhowells@redhat.com>,
	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 10:46:02 -0500	[thread overview]
Message-ID: <46D837BA.9000707@argus-systems.com> (raw)
In-Reply-To: <1188572504.26572.459.camel@moss-spartans.epoch.ncsc.mil>

Stephen Smalley 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.

How about looking at it this way, I am work for company A and therefore 
I can see all of their engineering documents. You work for company B and 
are not supposed to see any of our engineering documents. Company A's 
policy states that I can't disclose company private information to any 
one who is not cleared for it. So by giving you access to this 
information (either by telling you (e.g., passing a file descriptor) or 
handing you a document) I am in violation of company policy. MAC is 
there to enforce the company policy so I won't give you the information 
you are not supposed to have.

> 
>> To put it another way, how does A now legitimately pass on to B the grant of
>> rights A had on that specific file descriptor?
> 
> That would be discretionary, and therefore vulnerable to flawed and
> malicious code.  That's the point.

Or B is a privileged (trusted) process that can raise/change the correct 
privilege/capability/context to access the information/descriptor.


-- 
Thanks,
Mike
----
Mikel L. Matthews
Chief Technology Officer
Innovative Security Systems, Inc. (dba Argus Systems Group)
1809 Woodfield Dr.
Savoy IL 61874
+1-217-355-6308
www.argus-systems.com

"Any intelligent fool can make things bigger, more complex, and more
violent.  It takes a touch of genius - and a lot of courage - to move
in the opposite direction."
				Albert Einstein

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

  parent reply	other threads:[~2007-08-31 15:46 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
2007-08-31 15:46       ` Mikel L. Matthews [this message]
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=46D837BA.9000707@argus-systems.com \
    --to=mikel@argus-systems.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.