selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <pmoore@redhat.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: netdev@vger.kernel.org, linux-security-module@vger.kernel.org,
	selinux@tycho.nsa.gov, Andy King <acking@vmware.com>,
	Gerd Hoffmann <kraxel@redhat.com>, Eric Paris <eparis@redhat.com>
Subject: Re: AF_VSOCK and the LSMs
Date: Fri, 22 Feb 2013 19:45:54 -0500	[thread overview]
Message-ID: <1968537.V0Fsdryuo8@sifl> (raw)
In-Reply-To: <5127F874.1050907@schaufler-ca.com>

On Friday, February 22, 2013 03:00:04 PM Casey Schaufler wrote:
> Please add an LSM blob. Please do not use a secid. I am currently
> battling with secids in my efforts for multiple LSM support.
>
> ...
> 
> I am going to be able to deal with secids for AF_INET only because
> SELinux prefers XFRM, Smack requires CIPSO, and AppArmor is going to
> be willing to have networking be optional.

"prefers"?  Really Casey, did you think I would let you get away with that 
statement?  What a LSM "prefers" is really not relevant to the stacking 
effort, what a LSM _supports_ is what matters.

SELinux _supports_ NetLabel (CIPSO, etc.), XFRM (labeled IPsec), and secmark.

Smack _supports_ NetLabel (CIPSO).

AppArmor and TOMOYO don't really do any of the forms of labeled networking 
that are relevant for this discussion.  If you are going to do stacking with 
LSMs that conflict when it comes to what they _support_, not what they 
_prefer_, with labeled networking then you are either going to have to either:

1. Selectively remove support from all but one of the LSMs. (ungh ...)
2. Convince netdev to give you a blob in the sk_buff. (the pigs are flying!)
3. Work some sub-system dependent magic.

If you want to try option #3 I think we might be able to do something with 
NetLabel to support multiple LSMs as the label abstraction stuff should 
theoretically make this possible; although the NetLabel cache will need some 
work.  Labeled IPsec is likely out due to the way it was designed unless you 
want to attempt to negotiate two labels during the IKE exchange (yuck).  I 
think we can also rule out secmark as multi-LSM enabled due to the limitations 
on a 32 bit integer.

If you want to talk about this further let me know - I think we've talked 
about this at the past two security summits - but don't attempt to gloss over 
details with this "prefers" crap.

> If you have two LSMs that use secids you are never going to have a
> rational way to get the information for both into one secid.

Exactly, I don't disagree which is why I've always said that networking was 
going to be a major problem for the stacked LSM effort.  Unfortunately it 
sounds like you haven't yet made any serious effort into resolving that 
problem other than saying "don't do that".

Now, circling back to the issue of secid/blob in the AF_VSOCK/VMCI context ... 
based on Andy's email I think I'm still missing some critical bit of 
understanding regarding how VMCI is used so let's punt on this for a moment; 
however, your preference for a blob is noted (you also remember that I prefer 
blobs when they make sense, reference a lot of our earlier discussions).

-- 
paul moore
security and virtualization @ redhat


--
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:[~2013-02-23  0:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-22 22:33 AF_VSOCK and the LSMs Paul Moore
2013-02-22 23:00 ` Casey Schaufler
2013-02-23  0:45   ` Paul Moore [this message]
2013-02-23 23:43     ` Casey Schaufler
2013-02-25 16:55       ` Paul Moore
2013-02-25 18:02         ` Casey Schaufler
2013-02-25 21:05           ` Paul Moore
2013-02-25 23:06             ` Casey Schaufler
2013-02-26 21:21               ` LSM stacking and the network access controls (was: AF_VSOCK and the LSMs) Paul Moore
2013-02-26 23:12                 ` LSM stacking and the network access controls Casey Schaufler
2013-02-27 16:43                   ` Paul Moore
2013-02-27 16:51                     ` Casey Schaufler
2013-02-27 17:31                       ` Paul Moore
2013-02-27 17:40                         ` Casey Schaufler
     [not found] ` <888679886.3769933.1361573683299.JavaMail.root@vmware.com>
2013-02-23  0:27   ` AF_VSOCK and the LSMs Paul Moore
     [not found]     ` <512B12EA.1000003@redhat.com>
2013-02-25 15:06       ` Paul Moore

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=1968537.V0Fsdryuo8@sifl \
    --to=pmoore@redhat.com \
    --cc=acking@vmware.com \
    --cc=casey@schaufler-ca.com \
    --cc=eparis@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=selinux@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;
as well as URLs for NNTP newsgroup(s).