 Welcome back. So is anybody here know what a Linux security module is? Okay well great. Linux security modules are really very fascinating little aspect of the kernel that we've got. It allows you to apply additional restrictions to the existing traditional Linux security policies. In general the mechanisms reflect the existing policies the hood bits that you see on files for example. In a few cases they actually are used for other things security concerns that aren't necessarily what you would normally consider a security policy issue. These are things like binding to sockets. That isn't really something where you've got a subject or an object involved but it's a security thing you know it's something that people think is a security issue. So we've got mechanisms for for controlling that. Today well today we've got a mechanism called module stacking where you can have registered more than one security module. Back in the old days you could only have one. Yama came in and we had to manually stacked in it was hard coded in. That didn't really sit very well so we fixed that so we now have just lists of modules. But we have some issues with that. The problem really came down to the fact that the way we manage data we call them security blobs which we associate with the various things that are managed within the kernel. But you only had one pointer off of each of these things. You could really only have one module at a time. We've changed that a little bit. So now we actually have LSM types. We've got legacy major which are the old kind of major modules the SC Linux to Moyo app armors. And we also have what we call in some of the modules are marked as exclusive. So what does exclusive mean? An exclusive module you can only have one of them. So if you have you know SC Linux is marked exclusive, app armor is that marked exclusive that means you can't use them both at the same time. That's bad. Now for a long time you know people kind of threw up their hands and said well why would anybody ever want to do that? That was before the days of containers. Now in the container world we've got people who are running Ubuntu on their data center. They want to run Android in their containers. Well nobody ever wanted to do anything crazy like that before. So now we've got these exclusive modules we can't use them together. So the goal of the project we're working on these days is to get rid of the notion of the exclusive module to mark as many modules as we possibly can as to be not exclusive. But why do we have to have them exclusive and why can't we just load them all up? It's because of the security blobs. So as of the 5.3 kernel we have a set of blobs that are instead of being managed by the security modules themselves, they're managed by the infrastructure. So when you load SC Linux, SC Linux tells the infrastructure how much space it wants in the credential on the file and on the inode blobs. And the infrastructure takes care of allocating it and freeing it and then the security modules can use it to their heart's content. What this means is that if you have a security module that uses just these blobs, doesn't use any other blobs, you don't have to mark it as exclusive and you can run it at the same time you're running SC Linux. And so you don't have to turn off SC Linux. Your IT people are really happy because hey, you've got the standard thing with SC Linux, you're still using that everybody's fine. But you've also got this other security module that you've built that can go in and use those interfaces to do whatever it wants. So you don't have to eschew SC Linux just because you've got this new cool thing implementing some policy of your choice. And that's great. So right now, we've got a number of minor modules coming in. We've got Cera, Whitey, Rit, Landlock, several others that I've heard of today that I had not heard of before that are coming in that you can put in with SC Linux or App Armor or SMAC or Timoio and they just run flawlessly. They don't interfere with each other very much and everybody's happy. But not everybody's happy because we still have some limitations. So that brings us around to what's coming next. So the plan is, and no, we're not there yet, we don't know for absolute sure we've got to get enough sign-offs and tested buys and acts buys in order to make sure we can get this. But we've got the code actually to a point where it's pretty close to solid, I hope. And so the goal for our next major release on this, and we're targeting 5.5, is to remove the exclusive from App Armor. Why is App Armor our next target? App Armor is different from SMAC. It's different from SC Linux in that it is path name-based-ish. Less so now than it used to be. But it has a different fundamental security model than either SMAC or SC Linux. SMAC and SC Linux are based on subjects and objects where the objects are things like the inode, whereas App Armor is much more oriented toward path names. The profiles are different, the use cases are different, so it does in some cases make sense to have SC Linux and App Armor if you want to get the kinds of values you get from both of those. Or to use SMAC and App Armor if you want to do certain configurations. So it does make sense to actually target App Armor as the next thing that we want to get the exclusive tag off of. That requires a couple of, we do a couple of things. First off, we need to add the SOC security blob to those that are managed by the infrastructure. That's actually a relatively straightforward thing. We know how to do that. We've actually done it with these other blobs. So it's just a matter of take that code, change a few names in it, and everybody's happy, everything moves smoothly. That's not the only problem we've got. That's the easy part. Yeah, I love fixing the easy part because that doesn't take very long. And nobody complains about it. It's when you get to the hard part that people start to do things like bike shed. And the favorite one on that one, if you've got App Armor and SC Linux running at the same time, you have to deal with the fact that both of these LSMs want to look at PROC PID at our current to find out what the security attributes of the process are. Now, since both of them want to do that same thing, you can't do that because you don't know who it is. So we're introducing a couple of new interfaces here. PROC PID at our context, which is like current, except that it has all of the information about all of the security modules that are affecting the process at the same time. And it's done in a very simple format. It's the name of the LSM, a null, the value, a null, name of the next LSM, a null, the value, and so forth. So if you have, for example, if you have smack and App Armor on a system, you'll get the smack label, the word smack, and then the value for the smack label, the word App Armor, and then the value for that context. We're also introducing a SO pure context, which is like SO pure sec. It's the same set of information, but it's what comes across a socket. Again, we have to have a different interface because you can't be backward compatible if you change the format. And we proposed at least about a half a dozen different formats for this, comma separated lists in a known order or smack equals value comma App Armor equals value, but we finally did the intelligent thing, which is to ask the user community, and particularly the guys from D-Bus, to ask them, OK, well, what do you want to see? And they said, well, just give us an all separated list. We don't know how long it is, so we'll read the first one and we'll say, oh, that's not all of it. Keep going until we've gotten it all. So that's kind of a lesson if you're doing current development and you have an issue like this. Don't just debate it amongst yourselves. You'll never come up with the right answer. Ask somebody who's going to use it, and then they'll tell you what they want, and then you can say, OK, I don't have to worry about it anymore. I'm going to go with what they want. But that still doesn't solve all the problems because, of course, we've got legacy programs. How many of you have changed system demons recently? OK, nobody. Excellent. How many have changed the kernel recently? OK, a whole lot more. OK, what does this tell us? It tells us that people are changing the kernel. They're not changing the system services. People don't want to touch those things. I mean, they've been working for 10 years. Yeah, they got some CVEs, but somebody else will take care of that, and it's like, no, it's a system service. I'm not going to change that. Nobody's changing these things. So we need mechanisms that will allow us to run these things in the way they're accustomed without breaking. And so we have to come up with a mechanism whereby we can say, under these circumstances, you should use the SE Linux information. Under these circumstances, you should use smack information and so forth. So we're introducing another process attribute, which we're calling the display. So you write self-adder display, and you write the name of the LSM you want to get the information for. This is especially useful if, for example, like the app armor people are doing, where you're using SE Linux in a container on top of your app armor system, or the other way around. So you can say, when you start up the container, you can set the display to SE Linux. And so the things that are running in the container will think they're using SE Linux. They'll get the information about SE Linux. That's what they're expecting. Everybody's happy. The base system can use app armor, get the information they want. Everybody's happy. And you haven't had to change any of those pesky system services. Because again, nobody wants to change them. They just work. Now, there was a big, long debate here about how you decide whether or not it would be OK to change the display. My original take on it was, why not? And it's like, it's system information. Why should anybody care what the display is? Well, Steven Smalley had some really good reasons why you wouldn't want to do that. You might be able to, for example, trick a program into writing a context that another LSM wouldn't be able to use in the right time. It was all very messy. So my first take on it was, well, fine. We'll put it under CAPMAC admin, because that's the right thing to do. That's the capability used to control changes to the mandatory access control environment. Well, SE Linux people didn't like that either. Turns out that they don't like using capabilities. They want to do all the privilege control themselves. OK, fine. So what did they want? Well, what they wanted is every LSM to pipe in and say, yes or no. No, I don't like that. Yes, I do like that. And since the default on that was going to be yes or go ahead, then you'll find everybody's got each of the LSMs that uses the PROC interface now has to have to say how it's going to vote on using the display. And so SE Linux has actually added an element to the policy, which is whether or not you can modify the display. AppArmor has done essentially the same thing. And SMAC goes, yeah, sure, go ahead, because that's the right thing. The other thing that came up is Binder. Any of you are familiar with Binder? Oh, OK, great. Yes, OK. So Binder is something that Android uses. It's an application access control mechanism that came from somewhere else. OK, somebody's laughing. That's good. Yeah, it has its own intrinsic issues. But one of the things that it does do is it uses the internal mechanisms for displaying the security context to pass information from one side of the bind to the other. And so we had to make sure that when you run the binder that the sender and the receiver are talking about the same LSM when they pass the information. It doesn't matter which one it is just so long as it's the same one. So it doesn't send an SC Linux context to a process that thinks it's going to be looking for App Armor, because App Armor and SC Linux would get very confused. Now, SMAC is pretty good about this. SMAC will take anything as a valid context. But that's just kind of an implementation detail of that. The next thing that we had to do is do some enhancement to the audit data. Because what do you do when you have two subject labels, one from SC Linux, one from App Armor, one from SMAC, one from App Armor? You can't just put that in a compound context because the audit records, the audit parsers aren't going to be able to deal with that from a compatibility standpoint. So we're adding additional information, additional fields into the audit record when you've got more than one LSM that has subject information. So in this example here, we have SC Linux is the first LSM, and App Armor is the second. So it's going to say the subject is A colon B colon C colon D, which is the SC Linux context. But then we're also going to say, and then the subject for SC Linux is going to be A colon B colon C colon D. And the subject for App Armor is going to be Z or whatever it happens to be. Yeah, this is a little verbose. Yeah, there's a little bit of duplication of information in there. But for backward compalability, backward compatabilité, you need to have the subs equals because everything that reads audit records is going to be looking for that. And the new tools, you're going to need to know which LSM is responsible for which data. And without some indication that says, oh, by the way, the subject is going to be the SC Linux subject, you need to actually have that as well. So you can't drop the subject equal, even though it's redundant in this case. And because App Armor doesn't currently have object labels on anything, we don't need to do it for objects. But we are going to have to do it at some point in the future. So when we need to do that, we're going to do the same thing there. So the audit records are going to get bigger. And they have to because there's more information involved. So that's actually what we need to do for App Armor. It's not actually very complex. It doesn't look very complex on the outside. There's a significant amount of data structure changes within the kernel that nobody outside the kernel sees in order to deal with the compound contexts. One of the issues is that when you allocate one of these text strings, you then have to free it at some point. But in order to do that, you need to know which LSM allocated it because they have different policies for how you should go about freeing it. So there's a little bit of complication there. But it actually makes some of the internal interfaces a little bit cleaner. So I consider that a win. So that's what we need to do to take the exclusive tag off of App Armor. So when we've got that in, then there's the next phase here, which is coming before all that long. And that's the next step. And the next step set of goals is really simple. And that is to remove the exclusive completely. And that would be from SE Linux and from SMAC so that you could use any of the security modules together all at once and singing in three-part harmony. And it'll all be beautiful. That's a little bit more challenging. And the reason why it's a little bit more challenging is that SMAC and SE Linux do a lot of the same things. In particular, they both use networking extensively. So we have to add a few more infrastructure managed blobs. So along with the SOC, we have to have the key and the super block, super black block partly because both SE Linux and SMAC use mount options. Mount options are a really challenging set of interfaces as David Howells will tell you at length, if you let him. Al Viro will concur because he's been working with David on restructuring the mount interfaces. That's one of the things that we have to do. So instead of just saying, well, I'm going to send it to the LSM to do the mount options, you have to send it to all the LSMs that do mount options. And oh, by the way, if you give a mount option that you don't recognize, you have to not pay attention to it because somebody else might be paying attention to it. But then in the end, you still have to say, wait a second, nobody paid attention to this. So it adds a little bit of complication there. But it's not actually as bad as it sounds. Well, actually it is. But then we have to get onto the networking stuff. Networking stuff has a wonderful set of challenges. The first of them is the net label interface. The net label interface is very convenient, very powerful. It allows you to generically do packet labeling using the SIPSO and Calypso network protocols. But if you have two LSMs that want to put labels on packets, you have to decide what to do about this because you can't put two labels on the packet. You can only put one. So thereafter, a lot of crying and gnashing of teeth on how we could possibly make this work finally agreed that the right thing to do is to say, if you can get all the LSMs to agree on the labeling, then you can do it. And if you can't, you have to fail it. Well, that's a little bit harsh, but yeah, it kind of makes sense. If you're going to put a label on a packet and if you can't get people to agree on what it should be, then you probably shouldn't send it. Actual deployment indicates that this is going to happen very rarely because the granularity that the LSMs use is going to be very different. But there are circumstances you can use where this will actually come out. Part of the problem with it is that you set the net label interface. At the beginning, when you create the socket, you say, this is how I want this to be labeled. Well, what that would mean is that if you don't agree when you're creating the socket, the socket creation is going to fail and you're going to fall over. And that means nobody's ever going to create a socket because nobody's going to agree at that point. You don't really care about it, too. You actually want to send it. So there's some slight change to the net label interface that has to happen in order to make that actually work properly. Some change in SC Linux, but more change in SMAC because SMAC doesn't use net label the same way. SC Linux uses net label. And that makes things complicated. So SMAC has opportunities for improvement, so those do have to go in. So that's for packet labeling. That's a bit of a project. But once you can actually get it so that you can request the label you want, and then when you're actually going to send the packet, that's when you decide whether or not you agree on what it should be labeled. Then you can actually have a system that functions at least marginally in some cases. The next issue would be sec marks. So if you're using NF tables or IP tables, you've got this opportunity to put 32 bits into the packet into the SKBuff to pass it around and recommend what the labeling should be. Unfortunately, 32 bits is not enough to represent two LSMs, or three LSMs, or six LSMs. So we have to do something, not clear exactly what we're going to do, a hash table to come up with a mapping, possibility, exclusive use. This is the easiest way to do it. You just say, well, yeah, SMAC is going to say, hey, SC Linux wants to use it. Sure, go ahead. I won't bother. Or vice versa. That's another way to do it. That's kind of a cop out, though. Not everybody likes that one. On SKB extension, yeah, maybe we're a little bit wary on that. The networking people haven't always been especially accommodating when we've made requests like that. So we're not exactly sure how that's going to work yet. But we'll come up with something, or not, one of the two. OK, so. And then there's labeled NFS4. This is a really interesting conundrum here, because labeled NFS was defined. And the definition included information about how the data that's being passed back and forth between the client and the server is formatted, which Linux very carefully ignores. Doesn't put it in, doesn't read it, just assumes that the information that came in is the format that whoever is going to read it wants to use. That's going to require some enhancement so that we can actually tell who's going which way. The NFS developers are looking at that, looking at how they might go about doing that. We'll see how that goes. So that's where we are. That's where we're headed. Hopefully we'll have the next round in 5.5-ish. Hopefully we'll have all the rest of the problems solved and a path for them not too long after that. And that's where we are. Questions? Go in once. In the audit records, you showed that the various LSM contacts will be displayed parallel alongside the legacy sub-equal one. Is the same thing going to be there in ProcFS as well? Yes. So what we'll do in ProcFS, you will get the value. If you use the existing interfaces, for example, ProcSelfAdderCurrent, you will get the first LSM that provides one unless you've set the display, in which case you're going to get the value that you've set it for. We have to do new interfaces for the compound format because otherwise you're not going to get information that you're going to be able to read. If you get the compound format, if you're running smack, the first, the label you would get would always be smack. And that's not what you want. You want the value of smack, not the name of smack. So backward compatibility, it would be really nice if we could just put it in one place. We know we can't. Is that the question? OK. Our questions. You're going to send me some man pages patches for those Proc changes? Sorry. You're going to send me some man page patches for those Proc changes? Of course. Thank you. Our questions. If not, let's thank you for the talk. Thank you.