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. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
