From: Casey Schaufler <casey@schaufler-ca•com>
To: Paul Moore <pmoore@redhat•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>,
Casey Schaufler <casey@schaufler-ca•com>
Subject: Re: AF_VSOCK and the LSMs
Date: Sat, 23 Feb 2013 15:43:23 -0800 [thread overview]
Message-ID: <5129541B.4030806@schaufler-ca.com> (raw)
In-Reply-To: <1968537.V0Fsdryuo8@sifl>
On 2/22/2013 4:45 PM, Paul Moore wrote:
> 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.
I suppose. My point, which you may refute if it is incorrect,
is that there are common, legitimate SELinux configurations which
eschew Netlabel in favor of XFRM.
> 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.
I am informed that labeled networking is being developed as an
option for AppArmor.
> 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.
With those being the possibilities, the choice is pretty obvious.
(It's 3, just in case the reader is unfamiliar with the histories
involved)
> 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.
It is reasonably easy to restrict Netlabel to a single LSM,
and since SELinux seems better served by XFRM in most configurations
and AppArmor intends to make networking an option that seems
like a viable strategy until Netlabel gets multiple LSM support.
> 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.
That was my take as well. But, since only SELinux uses those currently,
and I see little pressure for Smack to support them I don't have
a lot of incentive in that direction.
> 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.
Sorry if I presented my position poorly. I'm not trying to
gloss over details, and I apologize if I gave offense or made
statements that disrupted the harmony of the community.
>
>> 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".
Oh believe me, I have made serious effort. I just haven't made
significant progress. The good news is that there can be a
networking configuration (SELinux with XFRM, Smack with Netlabel,
AppArmor with none) that is both supported and rational.
Options I have considered include:
- Netlabel support for discriminating LSM use by host,
just as it currently allows for unlabeled hosts.
- Netlabel as an independent LSM. Lots of refactoring.
- secid maps.
- Remove secids completely in favor of blobs.
I should have an updated patch set by month's end. I think it
will address the current LSM issues. I don't know that I can
say it will address everything new LSMs might want to try.
> 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).
Indeed. Thank you. A blob can contain sub-blobs. A secid is just
a number at the whim of an LSM.
Thanks. Sorry 'bout the whole "prefer" bruhaha.
next prev parent reply other threads:[~2013-02-23 23:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-22 22:33 AF_VSOCK and the LSMs Paul Moore
2013-02-22 22:54 ` Andy King
2013-02-23 0:27 ` Paul Moore
2013-02-25 7:29 ` Gerd Hoffmann
2013-02-25 15:06 ` Paul Moore
2013-02-22 23:00 ` Casey Schaufler
2013-02-23 0:45 ` Paul Moore
2013-02-23 23:43 ` Casey Schaufler [this message]
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
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=5129541B.4030806@schaufler-ca.com \
--to=casey@schaufler-ca$(echo .)com \
--cc=acking@vmware$(echo .)com \
--cc=eparis@redhat$(echo .)com \
--cc=kraxel@redhat$(echo .)com \
--cc=linux-security-module@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pmoore@redhat$(echo .)com \
--cc=selinux@tycho$(echo .)nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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