 All right, so Heck it doesn't want to stay there. So I'm John Johansson. I work on the canonical security team and I'm also the Kernel maintainer for the app armor module So this last year the app armor project moved hosting to get lab Which has helped with a we used to be on launch pad which get labs really helped Pick up and integrate with some of the other projects to get other people involved We picked up a new logo this last year as well Great fun Well, you got to see scary penguin right talk toxy We also picked up the CII best practices badge This is a little plug for them So it's a good thing for projects if you've got a project to try to pick this up. It's not that hard to do It's mostly a lot of Crossing your eyes dotting your teeth crossing your t's dotting your eyes basically You need to get your HTTPS and version control and stuff sit and document what you're doing there Doing get lab or get hub or something like that's really gonna get you most of the way there And then it's you know making sure you have security policies What to do with your project and stuff like that and it's just a checklist that you run down And then you know it it let and lets other people know that you're doing things, right? And it also helps you make sure that you're doing it, right? So What's app armor besides a security module? We've heard several times before a lot of people know Something about it. Anyways, I'll often you hear a path name based App armor is actually a modified DTE Not just files Files is one of the properties. It's the the primary one right now that we're using for files But and the labeling if you know anything about DTE Would be implied from the files or the typing But you can have Exceptions to that where you're using a label on the disc or something So you saw Matthew talking about them using the security app armor Exeter So they're running a little bit ahead of us on our support on that right now But the very little bases in there that they're using It's very much still a work in progress we are not done with our model or getting to where we need to be And yes as some people have said before DTE is the kitchen sink Yeah, it is Semantics, yeah, whatever right. It's the goal is really make it work for people make it easy The other thing being here is this goes back to the original paper that Crispin presented in 2000 Use Knicks. There is actually some capability system in here. So The most of that hasn't actually landed yet, there's just a little piece of that that's in there right now The important takeaway from this is that, you know, yes, we're a Mac Policy DTE domain type enforcement. It's from the domains point of view or largely And there's some dynamic components to it There are some design goals around app armor it starts with a targeted policy. That's So that that's where we started from instead of say SE Linux starting from the strict policy and saying What can we just do to improve security on the system? We want to make it easy to confine applications. We want more than just confining applications So it's not just applications despite its name It's controlled sharing an awful lot and you can build sandboxes and stuff on top of it Users are really the biggest problem in security We have real problems and we you know when you're starting out you have real problems and with Administrators or users just saying yeah get get security out of the way and we want to avoid that as much as possible We want to make it easy to selectively enable or disable things and easy for a user to understand what's going on So with starting with targeted policy, that doesn't mean we got everything in place and we still don't Goal being you know, we want to work towards it one of the things we do to get out of the way is we have an unconfined mode It's similar to SE Linux unconfined T It's used all over the place special cases and so what do we look like so the base unit of an app armor Mediation policy whatever is a profile profiles. Just this text blob Got a little bit of language. It's very similar to what a user would expect to see It was originally some of the syntax comes a lot from you know 20 years ago. You're talking C programs or stuff. So you're seeing include and stuff like that as part of the syntax If there's different rule types, they're very natural to each one's supposed to be towards The the class that it is so files. You're looking at a path name Read write permissions stuff like that D bus Is example here it has its own set of you know Idiom is or whatever you want to call it of how are you express what's going to happen with it? So the top bit there, that's what we'd call the preamble. That's just a way of sharing some stuff and setting some things up The profile name This is the domain label sort of Sometimes And it's it was what shows up in ps-c Domain label also you could think of that as subject type This is an attachment. There's different attachment specifications. So this one's a path based one Matthew earlier talked about Adding the X adder one for EVM There are some other ones coming as well. There's just some flags to modify profiles. This is the complaint flag is basically Equivalent to audit to allow except for you can do it on individual profiles in the system instead of applying it to the whole system Then you get a rule block They include section that that's just another way of saying these are just regular rules in here It's just they're abstracted out so you can share them, right? and then you have some We've got some rules here like for File for D bus the syntax is declarative. So order doesn't matter Like I said, we've got different classes or rules. This is all whitelisting. So the allow is actually Optional you almost never see allow in the syntax or actual policy files You do see denied sometimes denied is not necessary But it's nice to annotate certain things that you know, you want that it's going to be denied And then there's some rules that each profile gets to control domain transitions that are happening Would we go back? Here the the attachment that is used by Unconfined so like we said we get out of the way as much as we can Unconfined needs some way to know whether it's going to attach to Applications that use it runs And put them into an a confined context These domain rules Here The profile can choose to use the attachment, but it can choose to do something else So this one's saying I'm going to allow running Firefox to run base name, but it's going to inherit my confinement It's it doesn't it's we're not transitioning And then policy is just composed of a whole bunch of different, you know profile files Profile files text files aren't useful for actual enforcement of the kernel So what we do is we take and we compile those down and we build a state machine It's kind of a bit like going to BPF The state machine has guarantees about completion and control of memory usage and it's verifiable We have some other requirements So it's not it's not BPF. It's it's more restricted It has certain properties that we need to do some policy composition So it follows some rules around set and regular language properties It's also architectural independent As much as we can make it anyways, it is right now There are some things that may land eventually that would break that sometimes So the basic overview of how it works, I mean, it's not very different from other security modules Your text pile policy goes into a compiler that loads it into the kernel. So you have some active policy Unconfined Does you know look at the active policy at times like I said using the attachment conditionals But it's mostly getting out of the way at special case all over the place And a confined application. It has a context that references into the the policy and it's enforcing it the kernels doing a bunch of work and We put labels and we carry some context information on objects And then we we also have a user space trusted helpers or you can call them other things as well that Selectively enforce bits of policy. So things like we saw the D bus rule earlier earlier so if you D bus is enabled to support it will actually look at app armor policy and Look at communication coming across the D bus and enforce that part of the policy for us We have Xase pro Xase prototypes that have never gone anywhere because Xase is so much fun There's a few other places where that's been used the trusted helpers are Limited you can actually confine them themselves. And so they're just applying to that They're a little corner of what they're doing and of course we're auditing Messages to the audit subsystem and letting it deal with the rest of it So that's the basic overview of the app armor system. That's where most people would see it App armor has policy namespaces. So We've been front running this a little bit compared to some of the other LSMs This comes into a lot of how we want to do things and do things in app armor and help policy is set up so they're They're separate from a system namespaces So policy namespaces, they you know, they let you run load policy of different You know same names Different policy stats, right They they show up as a in the domain name kind of like, you know, we've got an NS kind of SSH style or we've got more the URL style You'll do either the kernels short and use the shorter form They're hierarchical Each one's obviously getting his own set of profiles They also get their own unconfined states so tasks we track which one they're in by the unconfined state of your in unconfined You could be in NS5's unconfined They also define a view of policy. So what's visible? Tasks at the system level could look down if if they have the privilege and they could see the other namespace policies So they could see NS3 or NS5 and they also control what can be loaded. So if you got a task that's being confined by policy or as Capmack admin whatever at the system level it's going to be able to load policy into the system namespace But if you have a task it say confined in NS3 it it was only seeing what's in the NS3 and down namespace and it's It can't you can only load policy to NS3. You're not going to be able to load system policy And similar we could do that for another one down Right now it's a complete separation on the the view and the the policy load It's not very useful for a lot of situations when you're looking at like this There is a use case will cover that where it's kind of being used So if you just had namespaces it for themselves, you know It's it's an either or situation and we had this for quite a long time and for us That isn't a very useful situation. So you'd be either in the system namespace or you'd be in the say NS5 and the confinement they didn't communicate properly shall we say So to make this useful into it to work towards our policy with where we want things to be we have and this is getting also into the Capability stuff a little bit. So we have policy stacking that can happen at runtime Theoretically that we're not doing it right now. Some of this can actually be done at compile time And so the cost of doing these stacks that we're going to talk about can be mitigated a lot It just depends on what you're trying to do Stacking is specifically an intersection of permissions. So it's a way to reduce Privilege Or insured privileges within certain bounds of two intersected policies So let's say we have a task in the system namespace I don't care what it's doing. It's it's just confined by it and then You know that it can do whatever right? Let's put a task in the system namespace and namespace three So what what's happening here is the task is being confined by both namespaces and the policy of both are going to be applied So This is a way of allowing you to set up policy for one thing Some some basic restrictions that you would want and then having something else set up some other policy, right? Where can where is this useful? Well containers, right? so what we have is we can set up some course policy at the System level some things we we can say that we don't want the container to be able to do the system some mount rules or something like So we can restrict what it's mounting inside the container and be sure about that And then the container itself can load policy have its own policy So LXD right now on in Buntu will you can use? An in Buntu container that has its own policy while the system Has its own separate policy and is enforcing things on the container There is some horrible hacks in here to make this work at the moment Due to interactions with system namespaces that have not been resolved We are working on proper solutions to that but It is what it is and theoretically we could do three-level deep nesting or more But again, this is currently Restricted and broken because of the horrible hacks and system namespaces So the oh, I said, you know before we said that the namespaces define a view a scope The scope is just the view is what you can see the scope is where it applies and the administration So right now all of those are tied We have some work coming to split that out and so a name-face could inherit its parents view And or it's current parents scope and this is this just as a way to make them more flexible And bring in the other you some of the other use cases. We actually have so the first use case We enabled was containers where you wanted the kind of isolation Where we want to actually go with these beyond that is a Much more complicated rich policy so your system can have a policy you could define some global stuff you could set up a policy for some users to have different roles and You can also then with the scope and view work enable users to define their own policy So maybe instead of having so right now often you'll have like the system to find a Firefox profile Which is kind of crazy because the user is running it The user could define his own how he wants to confine his application that he's running and the application itself Can actually define sandboxes with it and and load policy and use it. This isn't enabled yet It's still work in progress And all of those get combined together and enforced Stacking doesn't need to be across namespaces and this plays back into delegation So the delegation of authority other capabilities that we talked I just mentioned briefly before So when delegation lands There's going to be policy rules around it, but there's also going to be an API that allows user space to Load policy Now we don't trust user space Yeah, the user space is gonna have to compile the policy and it's gonna get loaded It's gonna be a state machine that we can verify But we still don't trust user space because they can stick anything in there, right? So you could have something that's confined and I got a profile on it with some set of rules and The user space is trying to abuse it and delegate its authority But it doesn't have authority to delegate the rules that it's trying to throw So in this case, let's allow you to read or write every file in the system so we can use stacking to dynamically limit that and Then what happens is the intersection of those two the actual policy that the system of that Application has and the delegation set is actually what you're going to be able to delegate Now this obviously has a runtime cost because you're doing some extra computation For now, we're just gonna be Allowing this to be handled dynamically. It doesn't actually have to just be handled dynamically though We don't want to stick the compiler portion of building these state machines into the kernel But we can certainly, you know Do an up-call and that user space compile this and from a trusted point of view a trusted Compiler back in and bring that back in and and that new trusted one can Be passed back in and replace the dynamic one so Temporarily you're in a dynamic situation that high as a higher cost and then once you get user space giving you a trusted verified intersection Then you can apply that instead And so back to the domain label So you start seeing weird things like this that you know, maybe I have some intersection that doesn't make any sense at all But it doesn't matter, you know, we have we have a profile Firefox and we have a profile events Normally, I said those could be the domain label when we start talking stacking You get them together and that's at the actual domain name domain label or type So that's you know, the basics of the app armor policy. So what what have we been doing recently? We've been doing a lot of work behind the scenes and a bit of upstreaming We're maybe a lot you Ubuntu used to carry a large Delta for app armor and We finally landed everything upstream except for the AF UNIX patches those are seeing some review and some work around Our on support for improving network. So Our network mediation is a work in progress. So we've landed support for SEC ID is finally upstream And this is in preparation for supporting network mediation It's also allowed us to land support for audit rule filtering. So we certainly log to audit but now audit can You can do audit rules based on the app armor task label Or the domain label We landed socket media mediation. So this is the coarse-grain control of sockets for things that you know You're not doing a you know fine-grain IPv4, you know, I want this address or anything this but you know Well, no, I don't want to allow maybe I Don't know maybe I don't want to allow IPv6 or I don't want to allow AF packet sockets that kind of level It It's better than nothing, but it's not what we're where we're gonna be. We're we're working on the fine-grain stuff right now Profile attachments. You saw the start of integration that Matthew's done with the EVM AIMA There are some other conditionals that are coming There's improvements on Overlapping execs that that happened as part of this so Those attachment conditionals there's possibilities for overlaps and there's there's ways to check and figure out what's working and Originally, we had a much coarser check That was a heuristic saying we know this is good. We don't have to do extra work Now we're doing extra work to make sure, you know, we can get those areas that were somewhat sketchy on the heuristic And get the best match. We have Some work on the no new privs improvements So our no new privs there is stuff that has landed here. So no new privs is something that came around with sec comp and when it first landed it it was It blocked LSMs from being able to do transitions We have some stuff in app armor now that allows us to do subset transitions and track that So like in the stacking situations say for containers Maybe no new privs is applied when you're setting up your container. So at the system level Your system container policy is not changing but within that container It can actually transition the policies underneath in the the the lower part of the stack There is some other work for an override of no new privs as well, but that has not landed yet We had a problem where policy didn't carry ABI info You we did have a way to specify ABI and we basically it was either or so either you didn't specify the ABI at the system level And it basically said use what the kernels ABI is or You you could specify hey, I'm gonna pin my policy to this ABI right so For development using the kernel ABI is great for policy It's not so great for distros, but guess how many distros actually configured it that way So if you were changing your kernel frequently or being a kernel developer You could break people and we did have some problems with that. So We landed an ABI We're landing an ABI feature here so that you can just specify an ABI in policy and that's what's going to get used The old stuff still works that doesn't have the ABI specified. It's just Pin to earlier ABI's it can't use new features Cache was still a problem as well when we start talking about kernel and so we used to have a single cache So like I said, we build policy would make a state machine. So if you switched your kernel, then we had to recompile and That was problematic for kernel development as well. So now we've gone to a Per kernel cache that can be pre-compiled It handles collisions so like here if there's there's some hashing involved on the ABI and if there's a collision You just you get a little subscript on it and it's checked We also at the same time as we were doing this work We added Overlay support for policy and cache so that you could ship a read-only image and Still have local changes if you wanted to allow that We landed pretty much everything there I mean, I did say that there's the no-new-proof stuff that didn't quite land But we also have well part of the no-new-proof And didn't have as much land as we wanted. There's a whole bunch of work that's in progress right now There's some internal improvements and clean-ups that are happening We're reworking the early policy load To better integrate with system D and have it happen naturally natively And even a little bit of support for doing it in the net ram avis You can do that now, but there's no Skeleton at all for that you have to go do it all manually yourself We're not really advocating doing that, but we do have some people who would like that support The fine-grained network mediation is still a work in progress There's needs to be a whole bunch of improvements on the mount mediation we have some out mediation It's pretty rudimentary at the moment There's some actual work on key rings and I octals going on right now There's a whole bunch of improvements coming on the audit side of things. So we right now our audit structures are on the stack We're gonna pull those off the stack Do some caching of them? There's also so we can do some elimination and speed things up there Our complain learning mode features so how we do policy development are seeing some improvements as well So if anybody's followed the SEC comp notify work that Tyco is doing We've been borrowing from that and we're gonna actually have some interactive ability there for profile development That will actually make things a lot nicer There's some further further attachment conditional work coming on Improvements to the conditionals and permissions within the structures more policy namespace work The delegation is a continual work in progress. I Something we really need to land improvements to Pam app armor system namespace integration and documentation at the perennial Thorn in our side So any questions Questions anyone? Thank you. Thank you. Let's thank you