Re: AF_VSOCK and the LSMs
From: Casey Schaufler <casey@schaufler-ca.com>
Date: 2013-02-23 23:43:23
Also in:
selinux
On 2/22/2013 4:45 PM, Paul Moore wrote:
On Friday, February 22, 2013 03:00:04 PM Casey Schaufler wrote:quoted
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.
quoted
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.