 Thank you. That's the first time I've ever seen the AV guy attack the thing with a knife. We're in Scotland after all Thank you very much So I'm talking to a little bit about the work we're doing on security modules stacking I Decided that a good title is worth a thousand words. And so I Yeah, I came up with this one It's a new clicker. There we go. I said there we go Come to papa. There we go Okay, so there I am in case you haven't seen the slide before So security mod Linux security modules, why do we have Linux security modules? Because Linus wanted to make didn't want to be involved in the discussions about what security security policies We should have in the kernel anymore. And so he dictated that there'd be a Framework that you could plug your security module in and then he didn't have to worry about it anymore What is the security module stack? I? You might ask who on the answer is it's a collection of security modules. They're called in called in order and The first one that fails You stop it's a bail on fail model We have minor security modules. These are little teeny security modules that do Little interesting things but most importantly It's based on available state. They don't maintain any state of their own They just use information that's already available with a slight asterisk on that major security modules on the other hand Managed state manage information about Objects objects other other aspects of the system, but they may take they keep track of that themselves. They maintain it We have mechanisms for Allowing the security modules to hang hang their information off of system system data structures like i-nodes tasks, etc And since the the module is is maintaining those That makes them we call that a major one they also might use networking facilities like net label and sec marks in order to Propagate information about the networking so as of today What the security module stacking looks like is you have a set of minor modules Capability being the first one then yama and load pin and then you get to choose one of the major modules So why can't we just stack it all together well, we've got a stumbling block that is blob pointers Because the various modules want to use security blobs And we've only got one pointer on each of these data structures to point to security blobs You can't share them if you Have se linux and smack running at the same time for example they will each want to use the The pointer in the i-nodes structure and the cred structure and a bunch of other structures To maintain their data, and if you Random both at the same time what you would find is that se linux would put its information into the structure And then smack it come on put its information into the structure And then when you went to do the check the se linux would say hey I'm going to go look at this information and heads yes, it's the smack information and bad things would happen so the solution to this is To have the security module infrastructure manage the blobs instead of the individual modules This is actually reasonably straightforward to do You have the security modules when they get initialized tell the infrastructure how much space they need and The infrastructure will then tell the module when you use this information use it at this offset Which if there's only one module grinding will always be zero But if you've got multiple modules it will point out point off to an appropriate offset in the blob that the Infrastructure is managing and then you can go ahead and share those blobs When I wrote up the slides this seemed like it was still kind of pie in the sky something will do some day But it's starting to look like we've Kind of crested the hill on this and we may have it in the next release or two so that will be really good, but That's still not going to solve all our problems When we when we actually have this we'll be able to pull app armor out I'm sorry to moio out of the the list of major modules put it there so that you can put that on the stack But it's not going to solve all the problems We still have more stumbly blocks First one is sec IDs. Anybody know what a sec ID is? Okay, good anybody care what a second. Yeah. Well Thank you, James Well a sec ID is a 32-bit quantity that identifies the security information associated with with an object or Packet or some other set of information But each of the security modules that uses sec IDs Wants the whole thing Unfortunately, you can't if you have two modules that use sec IDs That's 64 bits of information and we still haven't figured out how to get 64 bits into a 32-bit integer and to Make things a little bit more dip more difficult one of the places where we use sec IDs is in a sec mark Which is in the IP packet? Sorry in the IP packet handling code and We have been told without with that unequivocably That No way are we going to get any more information and any more space in there. We get 32 bits and that's it Well, gosh, what are we going to do there? We've got 32 bits. We have more than 30 bits information. We need to have how are we going to deal with this? and This is one of the more major pieces of Construction needs to be done on this and as we have to replace that 32 bits with a Structure that has information from all of the security modules that are using sec IDs in order to Propagate that now Yeah, with stacking we have a structure here that's got This example we got that the three three instances for SC Linux smack and app armor And if we don't have stacking well, we just make it a union instead and so you still only got one So, you know, we're not adding a lot of expense there especially in the non stacking case But then we have to decide have to have a mechanism for defining which one of these Sack IDs to use in any particular case Well within a security module stats easy. We just use the Use the field that's associated with that that module and we're done If we're in net filter Net filter currently has a single entry in it which says if you're using SC Linux, here's where the here's where the information is We need to break that out and say well if you're using smack Here's where the information is now it turns out that in both cases that again if you're not stacking it'll be the same 32 bits And if you are you'll have to tell it which one it which one it is Currently smack is a bad citizen in this particular case and that it uses the SC Linux mode In sec mark, but that's something needs to get fixed when it's broken Now if you're in it so if you want to do something like So pure sec or any of the other mechanisms that are available for getting information about the security label of an entity You have to have a mechanism for determining which one of these you're going to get by default you're going to get the first one in in the security module list which Today is SC Linux, but if you want to explicitly say which one you want we have to add a PR control to say When I call SO peer sec give me the one for SC Linux in this example now we could have done it number of other ways One way that that had been suggested was to when you call SO peer sec You would get a list based In order list of the attributes for all the security modules you have that would probably have broken user space in hideous and Uncomfortable ways, so we decided not to do that so if we go ahead and do this and Make sec IDs generally useful Okay, well then It turns out we can we can with the current implementation at least pull up armor out as well so now you've got your choice of smack RSC Linux and then app armor and Tomoyo and Everybody's happy here But we're still not done. So what's our next stumbling block? Next stumbling block of mount options What is about mount options? Well today If you have an unrecognized option in your in your mount Your mount system call it fails Now in this particular case here, we've said We've specified a mount option that SC Linux recognizes and a mount option that smack recognizes with the old code if you Go into SC Linux it's going to say up. I don't recognize smack FS root. So it's an error So we have to change it is so that the security modules don't make judgment on options that they don't recognize Unfortunately, what this means is that? If none of the security modules recognize it, it's still unrecognized This no one is going to detect that it's completely unrecognized and will will succeed in a case where it might have otherwise failed Not insurmountable, but Annuisance and probably not worth dealing with unlike so long as David Howells is still working on completely redoing the mount The world of mount from the ground up Which we're very very much hoping for real soon now, but he talked about that earlier. All right, so It's not our only stumbling block. No, unfortunately. It isn't The next one is net label now the net label subsystem is a really cool bit of code It allows you to put sipso and calypso options on to packets so you can get the Security information about your process across the network across the socket interface to Do other processes on this machine or on other ones? Well, unfortunately We get you get one sipso tag period and that's the way the spec works and If your security security modules don't agree on what that labeling should be You have a problem. What do you do? You could consider adding them together, but that would be wrong could consider doing an Doing an or and only including the bits that they both agree on but that would still be wrong So the only thing that really makes sense there is to have is to deny it Unless the security modules agree That's Probably not going to give you a whole lot of cases where you actually get anything to work because The security modules are likely to use the use the labels in Different ways and they're almost they're gonna have different granularities as well Another issue here with the net label code is that whereas all whereas the other security and interfaces are pull interfaces that is The attributes in the security module you you pull the attributes from the the code you're you're running in With net label the security module pushes its information into the net label system and says here I want you to use this information and Then those attributes are converted to actual sipso header information and put into the socket Which means that it you can't do any kind of abstract comparison you can only compare directly against what would actually be on the wire so that makes things a little bit more difficult and there are cases where if you're using network selectors and deciding that network address selectors They are not going to use what's in the socket after all anyway, so It gets a little bit hairy to determine this and But once you've actually come we're looking at a Couple of options on how to do that and in particular the Well next slide here net label config the configuration The security modules aren't always going to use the same Defaults with regard to what they want. This is how they want the system to behave for example most SC Linux sockets Most well most networks on an SC Linux system are unlabeled This is in part because SC Linux only uses the the sipso label for the MLS component smack on the other hand dumps the entire smack label into this the sipso header in a somewhat Clever way And does that by default for all all networks? so there there are very much at odds with the way they use it and address selectors Where you're allowed to say that this host should be given this label and information coming from this host should be given this label Is deferred until delivery So if you're using those you're not actually going to make the decision at the same point You're not going to make the decisions at socket creation. You're gonna make the decisions at packet delivery. So there's a bit of Complication their complexity also granularity like I said security modules Did the security modules aren't going to use the same granularity if they were then you'd probably only need one so The smack label the process is going to change at a different rate than the smack than the SC Linux label of a process is going to change There's the SC Linux context. It's going to change And Again, that's going to make Make things difficult and just to add another another loop Smack allows you to change the label that's used on the socket after you've created it Whereas SC Linux always does it at socket creation But once we get all these issues addressed That gives a situation where if we can actually Come get it to the point where we get that that done correctly Then we can stack all the security modules and everybody can be happy And what could possibly still cause any problems more than that, right? Well, one of the problems is you might have is if you you stack your modules you could have redundant purpose There really isn't any point in having smack in a sea Linux at the same time if you want a full-up mandatory access control policy pick one Sorry now app armor app armor does things differently. Hey app armor's policy Although it's a mandatory access control policy. It's not a straight subject object access kind of thing So you might want to use that in conjunction with another with one of the others Networking there are things you can do to confuse How you're using the system If you want to want things to be sane don't I don't mix the Network using policy network policy using modules because getting them to agree is going to be really tough There are issues with user space User space may get confused over which security module you're using if you're using multiples The ID command is my personal favorite say ID it will If you ID dash Z which is supposed to tell you the security context It'll tell you oh You don't have se linux and yeah You don't have se linux and but Installed I won't give it to you if you do have se linux it will always give you se linux But what about the other information you probably want to get? Get you might want to get more information Out of ID LS dash dash Z as well. I was like well. I want to see all the security information about that and Good news the system D seems to be doing a pretty good job of keeping up with the security modules and I think it actually well my experience is that it actually will Support things out of the box, but again, there are cases you can confuse it The good news is if you we have a file in in Sys kernel security called LSM which will give you a list of the modules that are in actually installed so you can actually do something So I just hit the wrong button There we go Alright, so if you're writing a new Linux security module and you're looking for for the potential of stacking it In the near future What do you need to know? Well, first thing is if you're using networking make it optional if You want to put if you're gonna want to plug it in with one of the other modules that uses secure uses networking You might not want to be the one who owns the networking. You might want to let the other guy have the networking In practical configurations Read the Netlubla code before you use it. I didn't and I have a lot of rework to do and You define what what it mean what What what it would mean for sent for same behavior to be if your network doesn't have labels on it? just Those are important things process attributes Traditionally you look in proc in proc adder to find proc adder current To find what your current process context is We're adding a sub directory in proc adder for your particular LSM Makes things a whole lot easier. You know, you know, you're never gonna be any conflicting there SO pure sec You might want to have a wrapper for that to make sure that you're getting your information not somebody else's Think twice about using sec IDs Oh Do you really want to have that? Do you really need to have the things that that you get with sec IDs like audit like audit filtering? You probably do but if you don't if you can avoid that you're probably gonna make your life simpler And be careful with the estate okay remember that in a stacking environment if The guy ahead of you fails. You're not gonna get called so if you're counting on on balancing your state Throughout all all the hooks that you're calling and you're and something else fails ahead of you You won't get called so you just need to be really really careful with that if you're gonna have State that you're out memory you're allocating to keep track of things outside of what's in the in the infrastructure managed blobs on On process exit you're gonna need to clean that up because Well, you're gonna have to do that so Wrapping up here. All right, so stacks of the similar modules are good It's like we like to be able to do all kinds of interesting interesting and unnatural things in In unison because well the more unnatural things you do the better right Um stacks should avoid fighting over the network because the network configuration always has been and always will be sophisticated exercise and If you color within the lines play by the rules don't try to do things that are esoteric or Require a dish Require extremes of memory management. You're probably gonna be happier And that's what I have so questions Questions So how do I debug when I get it in denial is it like I Just have to check all three. Is there any sort of unified? Have you thought about like unifying that at all or okay? So You get an e you get an e-access You do an open you get any access Well, what do you do now I? Hate to to say things like this, but probably a third of the programmers out there don't understand mode bits So people get an error they throw up their hands they they do a screenshot they send it out to a mailing list um Yeah, I just The answer is That if you're using a sophisticated stacked security module environment You're probably not much worse off than you are with a single security module if you're using more than one If you're not a if you're a programmer who's not aware of your environment You're no worse off than you are now if you're a programmer who is aware of your environment You should be aware of the fact that it might be several things that could cause this we actually Had Something very similar to this that we tried to answer several years ago just with s c Linux and the traditional DAC Mechanisms, so it's the same sort of problem. Obviously it gets worse with stacking But same idea you can have multiple places where you can get an access control denial and we called it the friendly e-perm Effort and we spent a lot of time looking at the problem is Coming up with any mechanism is just going to be inherently very racy You know there were we never could find a good solution So I mean somebody's got an idea and they can demonstrate that it wouldn't be Racy as all hell, you know, I think we'd love to hear it because it's it would be something that would be useful today independent of stacking But I think basically from The way we approach it now between at least in the s c Linux land between DAC and s c Linux Is largely with auditing? You know, you'll get the denials the s e Linux now to the auto log and so Presumably if you have a well-developed LSM, you're going to have some auditing mechanism when you have a denial So presumably in a stacked environment each of the LSM's would generate Denials when they hit it so now there would be all sorts of interesting questions that would come about because you know You might all the hooks might not be triggered and in reality you have that today Because if DAC denies The access the LSM never sees it so Basically, it's it's sort of if you don't see a denial in the audit log Then you would assume that the denial happened somewhere else Do you what what is actually shows up in proc self-adder like current for this? Okay, so proc self-adder current is going to get the first security module that supports Credentials credential hooks in the list Okay, unless You've used the PR control to tell it which one to which one to provide This is why we want to have the sub directories because to disambiguate that I Actually, you know when I did smack way back in the dark ages when dinosaurs roamed the earth I Made a serious mistake by reusing proc adder current Rather than having proc adder smack It was a mistake. I made it. I admit to it. I misled the app armor people to do the same thing Yeah, but I got it into the kernel first Yeah, it made sense Yeah Yeah, and I Guess that's one of the important things here is that things have changed since we did the original since we did app armor and se linux and smack Security models are way different. It's like we didn't have no JS. We didn't have containers Virtualization was something that you used if you were one of the cool kids, but but in general people didn't do it So it's a different environment here Yeah The biggest reason to do stacking is to encourage and get new models in and new security paradigms moving forward To eventually replace the Bell and Lepodula derivatives that we're using now Anyone questions? This is maybe a really dumb question and saying I don't I Really haven't thought about it too much It's like it's the idea that the stack in the stack each security module each LSM needs to be unique You can't build a stack like for example say app armor then on top of it as a Linux and then another app armor And then another as a Linux that wouldn't Fit the current design But if you called it something other than app armor You could do it And Now the the possibility of of app armor name spacing for example is still one where we're As as a community we're kind of kind of still non on that one because How do you? Maintain a security blob for two instances of app armor. Sure. Yeah, how do you maintain? The a coherency where you've got one policy for the base system and a different policy for the things within the container Do you do both you do one? Do you do the intersect? The mind boggles with the possibilities but It is conceivably possible Thanks Oh, here comes the hard one I More of a comment there's an If the mount API stuff goes in there'll be a new system called FS info Which allows us to get more information out along the lines of status from files and file systems We should make look at making that able to return all the labels attached to a file or a superblock and List the LSM's that those labels belong to Okay, works for me Questions Thank you One question the stacking is it handled by the kernel at the kernel level or at the user level? Sorry the stacking of the modules. Is it handled at the kernel level or the user level? Current car. Yeah, kernel level. So in this case have you thought be at the kernel level? Yeah, so when you boot the system it registers the security modules. It's going to use now And that's for the entire system now. Could you do it at like a? Hierarchical level level where at some point you could say oh and from here on down. I want to use this security module as well It's conceivable it's possible It has ads implications Like the infrastructure has to know that the blob size might change In this case, would you be able for instance to create a new security module that will in fact call the other security modules? Yes You well you can do anything in a security module. They're magical that way but one of the possibilities for Supporting the the namespacing is you have a security module that actually does dynamic loading of security modules I Don't know that that's the best way to go about it That was actually one of the the original design possibilities for the module stacking was to have a security module that does nothing That stacks security modules But that had other It's a it's a sophisticated system to do that Questions not let's thank you. Thank you talk