 On the schedule, it shows each one of these updates that scheduled for 10 minutes, but really, this is just meant to be an hour where people who are maintaining subsystems get up, give a brief overview so some can be shorter, some will be a bit longer. The current scheduling software doesn't really allow us to do that. And interestingly, I think the early Linux security summits, the subsystem updates were much more prominent and longer part of the conference because these subsystems, the core security subsystems were still being actively developed. So I think now that's changed and most of these are fairly mature. So they can be typically briefer. So, and we now have a lot of people building on top of those subsystems and doing presentations of systems they're building at higher layers. So with that, I'll introduce Paul Moore, who is the SELinux kernel maintainer and audit maintainer. Hi, everybody. Sorry you've got to stare at me again. They promised me if I got up here four times, I'd get a free sticker. So you can imagine how disappointed I was when I actually got here and they were going away for free. So it was a big let down, but anyway. See, and here's my payment. So yeah, we're all set. You'll notice he didn't give it to me earlier. I had to actually wait till I got up here the fourth time. So anyway, state of SELinux, everything I'm gonna talk about here is basically from the time of LSS last year when I gave this talk. So we're looking at the past year in the life of SELinux. And I'm gonna have to go kind of quickly. So start off with kernel. Probably the big highlights and especially the biggest ones that you're most likely to see from user space is that now whenever there's a file operation that gets denied because of an invalid file label, we'll actually print that invalid file label using the T-Rocon field in the audit record. So that can be a nice debugging and diagnostics tool. We also have proper C Group 2 labeling, which is built on top of Kern FS, which presents some interesting challenges. But that's done and working now. We also allow file system submounts before these were part of the SELinux access controls with policy for that. But that was causing problems. And honestly, we were the only ones in the kernel that seemed to care. All the DAC checks just allowed it. And if you're familiar with kind of how submount works, it kind of made sense just to allow those. So we made that change. There's also a number of internal improvements. I would say the majority of the time that's where most of the SELinux changes are these days. But one in particular I wanted to call out is that we had a number of changes to our internal mapping tables, what we call the SID tab, just to really improve that. So that was a nice change, a nice improvement. We also modernized the make dummy policy or the MDP tool. If you looked at the kernel sources, Scripps, SELinux, you've seen the MDP tool in there. Probably never run it, probably don't care. But this kind of serves as a nice little demonstrator of SELinux policy. What would be the smallest SELinux policy for a given kernel build? So it's kind of an interesting little tool. I would still at some point in time like to add still support to that. Where'd he go? There he is. So yeah, you wanna do it. Anyway, so that's there. And then of course the usual bug fixes. We had a number of changes to the LSM framework. As you probably heard with stacking, there were some changes for the mounting API. So that of course has follow on changes in SELinux, but not really all that interesting. And also a few years ago, I started kind of just taking tabs and writing some statistics about who's contributed. And so these are the top 10 contributors by lines changed over the past year. So normally when we had more time, I would ask you to all stand up and we'd give you a round of applause, but I've got 10 minutes, so I can't do that now. But anyway, consider this a thank you from me and basically everybody else that works and relies on SELinux. This really is a community project and without people like this, SELinux wouldn't be the tool that it is today. So thank you. All right, on to user space. So the big thing is we had a new release through the past year, version 2.9. Probably one of the more substantial things, I think, is that Python 3 is the new default now. Reportedly, you can still use Python 2, but it's not by default. There's been improvements to Audit to Allow, Audit to Why, Set Files, SEManage, SEPolicy. We had InfiniBand support. The Kernel support was there, they just SEManage needed the necessary user space and understanding of that. So yeah, the usual, and of course, bug fixes and under the hood improvements and all that good stuff. So just like before, these are the top 10 contributors. Once again, if you're here in the room, if you're watching the video, thank you very much. It really wouldn't be the same without you guys. So thank you. SC Tools, SC Tools, if you're not aware of what they are, they're not part of the main SC Linux user space, but they're a great little thing for doing analysis and other various things with the policy. Had multiple new releases. The 4.2 was the big release and they were follow on updates.1.2. This is kind of leading the way. Now you actually have to have Python 3 to build SC Tools, so however, that change is also coming to SC Linux user space pretty soon because what January or February, Python 2 dies. I forget the exact date. So SC Tools, they've moved over to a Scython-based policy representation. Added support for SCTP. Policy names are available as attributes now in the language, which the big thing for that is that you no longer need a static build of LibSC poll, so that was nice. And now of course the usual updates for the permission mapping, object classes and whatnot. So once again, contributors. And it's worth noting, Chris is actually here. So this is noteworthy, Chris hasn't been here in like, I don't know, forever. So this is why I'm making it a big deal. Chris is also the person responsible for maintaining reference policy for all these years, which if you use SC Linux, you know how important the policy is. So if you see Chris in the hallway, tell him thanks, he definitely deserves it. Which leads well into the SC Linux reference policy highlights. This is kind of short, but we did have new releases in February and June. Added support for new modules, as well as system D improvements to the policy. And here's the top 10 contributors by line changed. And you can kind of see why it's a big deal that you thank, Chris, because you can see it's right up there near the top. So that's that. This is kind of a quick slide for work in progress and this is not necessarily always going to be everything that's going on. These are things that I'm aware of that are going on or that we've got queued up. A lot of times people might have something in their private repo and they just haven't posted it yet, but perhaps maybe the biggest thing on here is that one on top reviving the SC Linux namespace work. A few years back there was some initial patches that Steven posted and I think James posted one or two patches as well. Those are obviously don't really apply anymore because it's been a year or two. I'm in the process of forward porting those patches and I'm going to make a note to the SC Linux mailing list pretty soon. Once I get those forward ported forward ported to the current kernel I'll put those in kind of a working branch off the main SC Linux repo much like there's a next in all the stable branches will have like a working namespaces branch, something like that. And I'll keep that current as we have current as the kernel progresses. So my goal is we can use that as a base for doing namespace development. So if you're interested in contributing to this work keep your eye out on the SC Linux mailing list that'll be a place to kind of focus your efforts. We also have file system notification controls. This is like FA notify and all of its friends gonna add those controls into SC Linux. You may have already seen the patches on the mailing list. The SC Linux user space, I kind of mentioned this already they're gonna drop Python to support because you kind of have to at this point it'd be irresponsible not to. Various improvements to the policy tool chain more than I can mention in the, well I'm already over time I guess. Code quality improvements and more. So anyway, that's it. This is a little bit of a eye chart and I apologize but the slides are in the schedule so you can pull this up. And I'm guessing if you were to type get hub SC Linux into your favorite search engine I'm sure you would find these links pretty quickly. So anyway, with the minute or two that I don't have does anybody have any questions? I would say almost all of our development happens over the mailing list or like any good open source project that started off with kernel development subscribe to the mailing list. We have an archive up there you can search through and if you're interested in getting involved I would encourage you to start there. If you go onto the get hub you'll notice some of the projects like the kernel we have a number of open issues. I believe user space does as well but definitely feel free to come and talk to me. I'm here for the rest of the day. There's a number of other SC Linux people here as well. We can help you out if it's after the fact hit the mailing list. We're always happy to have people involved. All right, thanks everybody.