 Thank you very much, and I don't know how long we'll keep this as an annual thing. Maybe we'll just kind of get it all done, and then we won't have to talk about it anymore. Thank you. I'm Casey Schaufler. I've been a Linux, well, a kernel developer starting on Unix in the 1970s, worked primarily on supercomputers in the 1990s, did the smack Linux security module, and I've been spending the past couple of years working on security module stacking. So what is a Linux security module, and why do we care? What a Linux security module consists of is a set of hooks that you can implement for various active, various places in the kernel to make additional access control decisions to go along with the normal access control decisions that the kernel is going to be making for traditional access controls. The reason why we have an infrastructure for this, rather than just an implementation, is that early on we managed to make Linux a little bit uncomfortable with the fact that we couldn't agree on what it was we wanted to do. After a point where he shouted out, you security people are insane, I don't want to hear about it anymore. Just give me an infrastructure, and that way I don't have to, you guys can do whatever you want. I don't have to worry about it. A security module stack is a collection of Linux security modules that makes it really easy. They get called in order, and we have what we call a bail on fail policy. So the first security module that says, I don't like this, don't do it, stops the execution, returns to the system, returns the error, and then access is denied, no further processing is done. That's important. We'll come back to that later. So we have two kinds of security modules today, and one is a minor module. Minor modules have the aspect, they don't maintain any state, so they make their decisions based on the information that's readily available at that time. They don't keep track of anything, they just make a minor change. For example, what's in a path name? Is this an iNode, or is this iNode a SIM link? Is it a directory? That kind of information. A major security module will actually maintain state about the system. It'll maintain its own attributes, attributes about, for example, I see Linux will contain, keep a file context on every file, a process context. In order to achieve this, we have a system whereby most of the major kernel data structures have a pointer to what we call a security blob, and each of the major modules can use these security blobs to contain their information. We also have a mechanism called NetLabel, which allows you to set SIFSO and Calypso security options on IP packets, and we have a thing called SecMarks, which are used in some of the other networking mechanisms to transfer security information attributes along with the packets as they're going along within the system. As of 4.18, we have a mechanism for stacking where we can go use all the minor modules we want, and then one of the major modules. We do that because we've got a problem where we've only got one pointer in each of these major security, one of these major data structures, and so we can only have one set of information because, of course, each of these modules wants to manage that information themselves. The first stumbling block here is our blob pointers. This is the thing that makes it so we have a security module stack that would fall down if we actually ran all the modules together. The security blob usage is actually pretty uniform. It turns out that SC Linux and SMAC use them all. Tamayo only uses the credential blob, and AppArmor uses the credential blob, the file blob, and the socket blob and the task blob. Now, AppArmor is unique in using the task blob for now, but we'll see that change as time goes on. With this set of blobs, obviously, if AppArmor and SMAC or AppArmor and SC Linux want to use the same blob, they can't because they're pointing to the same place. So the resolution to this is actually fairly simple. We should have thought of it years ago. That is that rather than having the individual security modules manage the blobs themselves, they just tell the security infrastructure how much space they want in each of the blobs, and the infrastructure keeps track of what everybody wants and tells them where within the blob they should find their information. So, very straightforward there. So if we go ahead and do this, this solves all the problems, right? Well, actually, if we do the infrastructure manage blobs, we can pull Tamayo out of the list of shared ones, but the rest of them, we still have more issues here. Well, what else could be the problem here, right? Well, the next assembly block are something called SECIDs. In the original security module architecture, there are a number of interfaces that use a 32-bit integer as a representation of the security information. That is very convenient. You can pass it around. It goes into a network packet and network information, and it just goes around. When it comes back to the security modules, the security module looks it up, goes to the newslet, but when you've got multiple security modules using it, you've got 32-bits, and if each of the security modules wants 32-bits to represent their security information, you've got a problem. You've got the 10 pounds of flour and a 5-pound bag. So what we have to do then is come up with a way to get more information available for all of the security modules. We have a set of interfaces that use the security modules. For example, if you're doing the audit system, it takes the security, the SECID, that it gets passed, and it uses that to look up, then, the text string that it wants to print when it creates the audit record. Well, again, if you've only got 32-bits and you've got more than that information from the security modules, you can't really use that. So what are you going to do? Well, the obvious thing you're going to do is you're going to replace this 32-bit entity with a bigger entity. I've called it a struct SECIDs. It could be called anything else. And you provide an entry in this structure for each of the security modules that actually uses it. If you're not going to use stacking, you don't really want to have that overhead. So instead of having a structure, you have a union. And in the union, so when it actually gets created, you actually still have a 32-bit quantity. And so you're back to where you were if you're not doing stacking. And that's kind of an important thing. We don't want to put excessive overhead in place where we don't have to. But when you do this, you're going to have to identify which of these entities in the structure of SECIDs you're going to want to use when you have a SECID. Well, if you're within the security module, that's easy. You just use your own. If you're in SE Linux, you use the point SE Linux. If you're in SMAC, you use the point SMAC. And everybody's happy. If you're in NetFilter, NetFilter actually has a mode setup so that you can identify which security module you're going to use. Currently, the only one that's defined is SE Linux and actually SMAC piggybacks on this in an inappropriate fashion. So we have to add an entry for SMAC so SMAC can do it as well. But at this point, you're going to... Yeah, because you've got the differentiation available in the structure, you can identify which one it's going to go to. And if you're not doing stacking, it'll all just go into the same one. And it won't matter because you're not stacking. If you're looking at the attributes on a process, for example, if you're using SO PeerSec, you're going to need some way to identify which one you want. Now, one of the early ideas was, well, we'll just take all of them and we'll make a big long string that's got all of the security module names in it and we'll differentiate it. We'll put them in a comma-separated list and we'll parse it and everybody will be happy. And that got really, really, really ugly and is 100% not backward compatible. So instead of working with the notion of I'm going to have what we call a display LSM, I'm going to set it on a per-process basis, and I'm going to say, this is the LSM I want you to tell me about. And if I don't set it, it's just going to use the first one, which is going to be SE Linux. So I can come in and I can say, when I want to use SO PeerSec, I'm going to see about SE Linux, or I'm going to see about SMAC, or I'm going to see about App Armor when App Armor gets there, or whatever security module you want to use, so long as you tell it which one it is, it'll give you that information. So if we introduce the struct SEC IDs then, we can actually pull App Armor out of our list as well. So then, the only thing you can't do is run SMAC and SE Linux at the same time. Well, why not? I was like, haven't we solved all the problems yet? Well, not quite. The first stumbling block we've got to work with here are mount options. Currently, the way the mount code is set up, it will call into the security code and say, if you find an option you don't know about, give me an error. Well, if you've got SMAC and SE Linux they both have mount options. So if you say mount-o SEC label and SMAC FS root equals star, SE Linux is going to say I don't know about this SMAC FS root option. I've got to return an error. So what we have to do is we have to untrain these security modules to report an error if they don't see an option. This does lead us to a problem whereby now if there's an option that neither of them recognizes they're not going to report an error. So we do have a little bit of an issue there with error reporting with the possibility of an invalid option getting passed. And we have to have separate mount-option structures for each of them because each of the security modules because again, they're maintaining information about the mount information, the mount state. The current mount infrastructure code is a little bit Baroque. But the good news is David Howells is working on a new scheme which is even more Baroque, but which solves all these problems. So we have one of those wonderful situations where we have to choose between Baroque and Baroque and Baroque. And that's not our last stumbling block. But hopefully that's the worst joke I tell today. So the next stumbling block is NetLabel. As I mentioned before, NetLabel is a mechanism whereby we can put an IP option into the IP header for packets to provide information about the security of the process that's sending the packet. And this is great. We get one SIPSO tag because that's the current implementation. We probably could convince Paul with a multiple tag. Okay, yeah. I won't be able to convince him then. We get one tag. Fine. What that means is that if you've got two security modules that want to use this, they're going to have to agree on what information can go in that packet. That might not be as simple as it sounds. For one thing, one of the things that's interesting about the NetLabel system, that's kind of different from the rest of the way the rest of the security infrastructure works, is that the security modules push their data for NetLabel, whereas all the other interfaces pull the information out of the security modules. So when you create a socket, you send the label information you want to the socket. Or when you change the attribute information on a process, you send that to the socket. As opposed to when the packet gets ready to be sent, you pull the information. So that's a bit different. The other thing that's a bit different here is that you're not putting an abstracted or module-specific information out onto the socket. You're putting what's going to go out onto the network into the socket. This is very efficient. This makes it a lot better, a lot faster when you're actually going to send the packet. But it makes it more difficult to do anything resembling a compromise or a computation or let's work this out amongst ourselves kind of situation. And in the end, you may not actually use the label that you actually pushed out to the socket. Why is that? I hear you cry. NetLabel allows you to configure individual networks, individual hosts to have specific characteristics about how the labeling is going to work on those networks or to particular hosts for that matter. SE Linux by default works with unlabeled networks. Typically, it uses policy to define how you're going to talk between processes that are coming from unlabeled networks. SMAC on the other hand wants to use labeled networks wherever possible because it wants to get the information about the process whenever possible so that it can actually make a decision. And it will specify specific SMAC labels as being the ones to use when you encounter an unlabeled packet or that will be sent out unlabeled. Is a very different philosophy. The other thing about SE Linux is SE Linux will do the labeling based solely on the MLS and MCS components. It won't use the roles or the other information that it has. Unless you use tag-type 6. No. Yeah. Okay, yeah, loopback. Paul has corrected me that loopback is a special case. Yeah. Hmm? Not there yet. Nope. IPsec is a different creature. Okay. Paul said it. The other thing you can do is if you specified labeling on a particular interface you're not going to actually resolve what label you're going to use until you actually put the packets together. And that's going to go through net filter. So the net label configuration can actually be relatively complicated. It can make it very difficult for you to determine what labeling you're going to want to use for any given packet. When any given process wants to send a packet it may depend on where it's going. The other issue that comes up fairly quickly is granularity. The granularity the smack label of a process and the SE Linux context of a process are not going to be in lockstep. If they were what are you doing running both of them? Pick one, because that's going to be really your major factors what label or context is the process running with at this time. That's what you're really going to be concerned about. The other thing is that we may be changing the label to be used on a socket. In the smack case at least. After the socket has been created. So SE Linux doesn't do that. SE Linux leaves the same label on the packet at all times. You don't have a mechanism to change it. So given these these factors here the chance that you're going to get the packets to be get the two security modules to agree on what the label should be at any given time is really pretty low. So the expectation that this would work for these two security modules in particular isn't very likely. But let's just say that you're okay with that. And so long as they do agree you're going to you'll go along with it. Well then where are we? Well then we're actually in a case in a situation where you can run all the minor security modules that we have today and all the major security modules we have today at the same time. You're not going to get a whole lot of performance on the network. You can there are configuration things you can do especially with smack configuration you can rather than using what smack would use by default for labeling processes based on for putting in the IP packet based on the label you can specify it so you could actually put your best guess of what SC Linux would do into the packet and you get some of them out of there. But okay so what does this leave us with what can still cause problems at this point? Well one of the things that can cause problems is redundant purpose and we've been saying this all along you don't want to use smack in SC Linux at the same time they really do too much of the similar thing if you can't figure out how to do what you want to do in smack in addition to what you want to do in SC Linux you're probably not thinking hard enough similarly the other direction if you want to use SC Linux to do just one specific thing that you think you can't do with smack you probably need to think a little harder you probably don't want to do this but you do want to use smack or SC Linux and app armor together because they do very different things if you want the path name based access control that you get from app armor for whatever reason at the same time that you want the subject object related oriented things you get from smack or SC Linux at the same time again for whatever reason you should be able to do that and we want that we really do want that to work networking again you don't want to to muck with systems that really have different ideas of how the network should be working together so use one network enabled module and again this is going to be true into the future as people introduce new modules that do new interesting things if they want to send the information across in the IP header you really want to use keep it down to one of them because they're not going to be able to agree very often now your user space I haven't talked about the user space at all and that's on purpose because it can be an early problem user space may get confused there are a few places where interfaces may not be able to determine which security module they want to use at once fortunately we do have a mechanism where you can call cat what's in cys kernel security lsm and it will tell you the list of lsm's that are available so if you're running smacking sclinx at the same time you can look at that and say oh geez I'm going to have a good time here or if you've got app armor and sclinx you can use that to determine make your determination about how your application might behave we're also going to need to do some real significant updates in basic commands id I am still unhappy that id if you do an ls-z and you don't have sclinx configured it will tell you that it can't do this because I've got you don't have sclinx involved like well but the smack informations you can just print that but it won't ls is another good one if you do an ls an ls-z it will tell you the sclinx context but it really might want to have it do a bunch of other stuff as well but again this is all just kind of stuff that if somebody wanted to spend a few minutes having a good time writing some patches they could whip that out pretty quickly here and make a big name for themselves and become famous and live the rockstar lifestyle like we do so let's let's say we're going to write let's say you're going to write a new security module who here wants to do that? the usual suspects and the guy back there ok so the biggest thing is networking if you're going to do networking make it optional make it make your module work so that if you don't have networking available this is good advice for iot devices if nothing else if you can't use the networking either because somebody else is going to be using it or because it's not available make it so it's optional so you don't have to have it read the net label code before you use it there is somebody in this room who didn't and has been having trouble for quite some time as a result not mentioning any names and defines same behavior whether your network is labeled or unlabeled whether you're in charge of the security attributes or whether somebody else is make sure that you've got same behavior defined process attributes we've had a big brouhaha over what happens with proc self at our current well that's that was my mistake it was my bad rather than creating my own interface I just said oh well SC Linux uses current I'll just use the same thing well that was a bad idea so it would be really nice if each LSM had a sub directory in their proc self adder for their own attributes I'm advocating that trying to get a patch through on that one as well and the other thing is that for SO pure sec you're probably going to want to have some user space wrapper that will so that you can be sure to make sure that you've set the display LSM to the one you want before you call that in the situation where you've got stacking involved and twice about using sec IDs yeah do you need it if you do if you have persistent data you're probably going to need these and there isn't really anything we can do about that that means that we make the sec ID structure bigger it's going to go out when you do temp fs it's going to get created out that way you're going to need to have the hook to go from a sec ID to a sec context and back but it's if you don't need it you probably want to avoid it temp fs the combination of the contexts in order to maintain the label state be careful with your state alright your module hook may not get called if somebody ahead of you in the list fails or detects a condition whereby they would say the system call should fail you're not going to get called so if you're trying to keep you've referenced something or the number of times you've made a check on something and somebody else ahead of you is failing you're not going to get there if you're counting on another call to free something and you never get called you're going to have to make sure that when you deallocate that particular security blob that you're going to free it appropriately just because you can't really count on your being the primary that you always get called and avoid hanging lists off the security blobs you can do that it's going to require that you be careful with it if you can just come out up front and say I need this many bites in the security blob you're going to have to take care of it you'll probably be ahead so to wrap it up here stacks of dissimilar modules are good we've already seen that with Landlock sorry well we've talked about it today about Landlock there are several other security modules in the pipeline here that will do new and interesting things that are not going to be conflicting with existing existing security modules and you don't want to try to put jammed it all into one kind of thing you certainly don't want to put Landlock EBPF into SC Linux I wouldn't think you would you certainly don't want to put it into SMAC you might put it in your app on but if stacks can have a lot of fighting over the network that would be a good thing one of the tasks that SMAC has on our big list is let's see if we can't do a little bit better job using that label in a way that's less likely to conflict and modules really need to color within the lines they shouldn't be off doing bizarre things that might have obscure side effects that might cause other modules damage and with that I'll ask for questions I've got one over here from Mr. Brindle who hasn't asked me a question in years and it's probably going to be the same one hi Casey so you've been working on this for a long time why isn't it done day job yes I did next question going once alright well thank you very much everybody go have a snack