 Hey, everybody. All right. As James said, state of SCLinux, my name's Paul Moore. I'm the SCLinux maintainer. Just talk about the things since we talked about this last year. So first slide is a container slide, because I was under the impression that you couldn't come to this conference and give a talk if you didn't have at least one slide about containers. So put this at the front of the deck. Big thing this year is that we've added SCLinux support both to Rocket and to RunC. And this joins our existing support that we've had for a while for Docker. So I think we've got at least all the big heavy hitters for container engines. I'm sure we're probably missing some, but we're getting there. And a note on Docker, some of you may or may not be familiar with this, especially if you don't play in the container space. The newer Docker versions actually do leverage RunC support so they can make use of the support we added there. In a sense, we've actually added SCLinux support to Docker twice and had it accepted. So take that, SystemD. You take your wins when you can get them, right? We've also just recently, and I say just recently, but this is an effort that's taken quite some time. I don't think Vivek's here in the audience. No, OK. Vivek and Dan Walsh and Steven Smalley worked really hard over the past six, seven months to get SCLinux and overlay FS working in the same manner, which was tricky. But the nice part about is this is something that the container guys really, really wanted for a long time. And we now have same SCLinux labeling for all the different layers in the stacked file system. And we've got all the SCLinux enforcement that you know and love working at the different layers. So it's really cool. It's in the SCLinux Next branch now, assuming nothing horrible happens in the next few weeks that will go into 4.9 fingers crossed. We've also added separate capability checks for the initial and non-initial username spaces. So this is interesting for containers, but the thing that was really tripping us up was Chrome. I would say like to run with their own username space. So now they have a different capability check. So the nice part is you can grant capabilities in a username space without granting it in the host namespace. So yeah, you can run Chrome again. We've also made some improvements to our implementation of type bounding. For those of you who have followed SCLinux and no new pros for some time, you know that's been kind of a little tricky. But I'm happy to say after a few years now, I think we've actually kind of got it right, finally. Basically it allows you to have your nice SCLinux bounded type hierarchy work when you've got no new pros enabled. So this will be useful for, you know, sandboxing applications. Like yesterday we heard about MiniJail. MiniJail, other applications similar to MiniJail will work much better now if they use SCLinux bounded types. Another big area this year for us has been file systems. We've introduced file label revalidation. This is a big deal for distributed file systems where you've got multiple clients that can all be working on the same files and same file systems. This allows one file to make an update that would need to basically invalidate the SCLinux label on all the other different clients. So we go ahead, we invalidate all those labels and those clients have had the label invalidated. The next time you actually make an access on that iNode, we'll go ahead, we'll revalidate that SCLinux label, generate the new correct label from the policy and everything and keep going, you'll never even notice it. And the first implementation is actually GFS and that support's been in since four or five. Nobody's complained, so we're assuming it's all working well at this point. We've also added user space access to validate trans policy constraints via, you know, the SCLinux FS. This is important for file systems that are built up in user space, all your fused file systems, as well as any out of tree file systems that don't necessarily use all of the VFS hooks that are there. It's kind of esoteric. If you don't really understand what this is, don't worry about it, but if you do, hey, we've got it. But I don't think this really affects anyone in the room. And of course, I already mentioned the overlay FS support that's in the SCLinux next branch now and cross your fingers goes to four and nine. I knew it was too good to be true. All right, let's try this again here. There we go, we're back. All right, so that's file systems. Labeled networking, this is a slide near and dear to my heart, although I think it's something that probably only about two people in the room are gonna appreciate myself being one of them. Quick show of hands, other than if you've talked to me and I've told you about it, does anybody actually know what Calypso is? Okay, Casey. All right, three. We're up to four people in the room to actually care about this. That's two times what I thought it would be. I'm just pouring the... So anyway, I mean, this is something I've wanted to get into Linux for ages. And actually when I left my former employer, I had this about halfway done, but had to Dropix. I hadn't gotten it cleared and then sat in that time. But Hugh Davies from Code Weavers actually, and once again, I don't think he's here today. Are you here, Hugh? No. He worked long and hard on this and got this going. He even worked with some users to do some interoperability testing with Solaris TX. So this is in, and in line is this tree right now. It should be in Linux 4.8. You'll need to get a new version of NetLabel Tools. It's currently in the main branch. As soon as 4.8 is out in golden, I'll do a final test with it, make sure it's happy, and then I'll have a new version of NetLabel Tools. And I'll probably put a post up on my blog about how to use it. But anyway, basically it's labeled networking for IPv6 that's standard-based. So that's kind of the summary version of it. There's everything else that I couldn't really categorize into a container slide, basically. We've got new access controls for loading kernel modules. We heard Mimi talk about the kernel read file hooks. We leveraged that to do access controls based on the calling domain as well as the label of the kernel module that you're actually trying to load in. Very similar, if you're familiar with the load pin stuff that case did, very similar capabilities and functionality just with the SC Linux policy that you know and love. We've also expanded the exec stack controls to all the individual thread stacks instead of just the main process stack. Nice thing to have. User space. We had a new SC Linux user space release earlier this year. Version 2.5. Last year you heard me talk that we had just added a finer grained iOctyl access controls and see, raise your hand, you were here earlier today. Okay, you must have stepped out. Anyway, the Google guys worked hard to give us finer grained iOctyl controls. That's both finally now trickled into the user space, so you can go ahead and white list individual iOctyls which is good because iOctyls are fun. We have better sill support. You can actually generate sill via policy.conf now and better documentation and not to mention the usual list of bug fixes and various other small improvements. And SC Android, this is something maybe that not everyone follows all that closely but while I myself don't do a whole lot of work in it, it still leverages the kernel work we do, it still leverages the user space that we do and the numbers are kinda cool. Last year there was a lot of talks by Steven Smalley explaining SC Android and how it works and whatnot and KitKat basically introduced SC Linux and forcing mode test to Android. Now, if you were there for the talk, he explained how it wasn't everything on the system but it was a lot of important pieces. It wasn't until Lollipop came out that we had SC Linux policies for everything on the system and everything ran in enforcing mode. Last year we also saw that 60% of all the Android devices ran at least KitKat so you had pretty good odd of having an SC Linux system in your pocket. Now we're up to 80% and I don't remember, I think Kase was saying it was like what, 1.4 billion devices back in 2015. So I think it's pretty safe to say that we have bare minimum a billion SC Linux devices out there in the wild and the best part about it is they just work. So I don't wanna hear anything about how SC Linux is hard to use, guys, come on. So anyway, and Lollipop, this is once again, this is SC Linux on every part of the system. We're at 50% of the Android devices this year so the uptake is pretty good. It'll be interesting to see where we're at next year. We might be pretty darn close to having SC Linux on pretty much all the Android devices. Yes, because 130% is so much better than 100%, come on. So wait, how do you get 100%? Oh no, because it's 80% of KitKat and above, right? So 80% includes the 50% of the Lollipop, see. What is it, lies, damn lies and statistics, you know? So anyway, so two of the big functional improvements. Decompose the media server based on least privilege and wrote SC Linux policy for each of the pieces. I'll let you figure out why that work happened. Also, leverage the iOctl work that was done that we talked about last year to tighten the restrictions on that. So nice improvements. There's all the other things. There was no way these related to containers whatsoever, but Google announced Brillo this year, which is the IOTOS and that comes with SC Linux enabled and in enforcing mode. The open embedded folks have shipped the updated SC Linux user space, so go nuts there if you're an open embedded developer. There's also the OpenXT project, which we talk a lot about KVM and containers, because those are the hot new things, but Zen still has a lot of interesting security properties if your tinfoil hat is very thick. And so the OpenXT project is working basically a hardened virtualization client and they're leveraging the Zen security modules, Flask and SC Linux to help build that. So that's kind of interesting. I think it's OpenXT.org, am I right, James? Okay, Google will find it, I'm sure. So anyway, and last, can I answer any questions you might have? And I'm pretty sure you've all seen these links before, but just in case here they are. There's the kernel repository, the user space and the kernel test that we use are up on GitHub, link to the reference policy on GitHub, the mailing list where we do all our development. And then if push comes to shove, you can always email me. But if you have any questions, I would really encourage you to ask it on the list. That way everybody can benefit from the answer. It's archived, it's much better that way. You'll also probably get a quicker answer and if I'm honest, probably a better answer because 37 people will reply with all good comments other than me, just kind of shrugging like, well, you could try this. So anyway, any questions? No, so what'll happen is when you've got, say, client A and client B, right? Client A does, and they both have the file, they've got an inode, right? So file A does something to cause that label to get invalidated on file B. The next access check that SCLinux performs, all right, when we look at that inode, we'll see that, oh, hey, this file's been, the file label has been invalidated, we need to revalidate the file label. So it's gonna happen transparently to you. User space will never know, we just go ahead, we look it back up through policy, we regenerate the new SCLinux label and perform the access control. So if you do something weird, you load a new policy in, I mean, there's theoretically a case where you can go ahead and something would change, but once again, that's something that you've initiated to happen, you know? I mean, it's not gonna happen magically, you would have to create a new policy. Revocation is really hard, she could always open a file and map it and, you know, game over. It shouldn't block, in fact, there were some interesting issues when we were first doing this, when it was in development, making sure that we didn't accidentally block any place where we shouldn't, because that would be bad. You can look at the code, I mean, we've got 20 minutes here and I'm kind of pretty much out of time, but you can look at the patches and see. We also, strangely enough, an offshoot to this, when we were fixing some issues related to that, we actually sped up some stuff in the very beginning, like an early boot before you load policy. So theoretically, if your SCLinux system is booting, you know, like half a nanosecond faster now, you're welcome. So anyway, any other questions? All right, thanks a lot guys. Thank you. Thank you.