 So everyone's here who's going to be here. I am Seth Arnold. I'm on the Ubuntu security team I am here to promote the app armor mandatory access control system Debian has considered adding Debian adding app armor to the default of the buster installation And I very much love this idea and I'd like to encourage it like to help in whatever way I can Intriguery has been the spearhead behind this campaign trying to bring the app armor mandatory control system to everybody And I absolutely love the way he's been working with everyone. It's been truly fun It's uh, you know, I've been using Debian since 97 or 98 give or take Apped was around you didn't have to use deselect, but most people still use deselect So it's fun to be able to give back to a community. I've used for 20 years something that I have worked on for almost 20 years. It's a truly fun Anyway, I am on the Ubuntu security team employed by canonical Unfortunately, my job is not full-time app armor, but I love my job as it is so First thing to realize is that app armor is a mandatory access control system and to understand the mandatory access control system It helps to contrast it against a discretionary access control system This is the standard permissions that everybody knows and loves read write execute user group on a file The DAC permissions are a property of the file The DAC permissions are set by the owner and the owner can make mistakes owners can give privileges to too many people we've all seen Chimad 777 as Scripts or program advice or stack overflow answers Chimad 777 will fix your problems and Users don't understand what this means furthermore It doesn't actually apply to the programs that the user runs Because the the programs run on behalf of the user the program can simply change permissions on files as they wish So there's no way to keep your Firefox from reading your tax information There's no way to keep your mail client from reading your SSH keys Everything can interact with your GPG keys no matter how well the GPG System tries to stuff that into a specific agent So the mandatory access controls are access controls that are set by the administrator and different mandatory access control systems have different ways of doing this in the app armor the policies are process oriented and You can see that using the Z flag to PS and we've got a nice handy wrapper a a Unconfined that will show you significantly less information That's a little more readable and you can see on my laptop a handful of programs that are confined are The crony daemon the age client cups d cups brows d and they're confined by these different profiles Linux systems have four major mac varieties. There's sce linux. It's also called sce android depending on where you're using it app armor smack and to mojo App armor started in 1997 It started out as a research project moved to a DARPA funded research project was commercialized through iris communications That was acquired by novell and integrated into seuss and novell for all their faults actually did something wonderful They open sourced all of it Of course the kernel module was always gpl version 2 But it had a compiler that was basically mandatory and the compiler was proprietary And this basically killed everybody's enthusiasm for the tool. No one really wanted to use a proprietary tool However, novell open sourced it once a novell open sourced it it was integrated into ubuntu seuss partis pld And a handful of other distributions some fairly niche, but you know, it was always nice to get an extra one Daemon is currently testing app armor to be an app armor on default for buster And it's going pretty well I have to say it's not been perfect, but everything has been a learning opportunity and Integraries done a fantastic job responding to bug requests from People pointing out problems faults requests for help requests for assistance request for features It's it's been truly a fun engagement with the community App armor se linux mac and tomoya work together to build the linux security module system LSM is shared infrastructure that all the security modules can use It does allow for a certain amount of plug-and-play You can decide to boot with app armor and the next boot you can decide to boot with se linux The setup times and efforts of the different security modules are different. They have different goals different methods So it's not necessarily convenient to flip from one to the other, but you certainly can And app armor on by default would be you know, relatively simple and straightforward It doesn't require relabeling your file systems. It just requires the profiles To confine whatever you wish to be confined And this is an interesting point where app armor is different from some of the other choices In app armor, you have confined processes and unconfined processes The unconfined processes are completely trusted. It doesn't matter who runs them If they run as root, they're trusted. If they run as a user, they're trusted If you don't trust it, you can find it And once the process is confined Then suddenly everything that that process wishes to do must be listed in the profile It is a white list So if it's going to use the capability, you have to list that capability If it's going to read a file, you have to list that you want that file to be read So you can actually have an idea of what I'm talking about Here's a profile that one of our users has contributed for the MTR program I don't know if you're familiar with MTR. It's a wonderful little trace route tool It's a thousand times better than the original tracer out tool I think that was Van Jacobsen. Apologies to Van Jacobsen, but MTR is just simply nicer We can see here, it's a fairly small profile. That's because MTR doesn't do much It does talk on the network and it is possible that if somebody finds Bugs in MTR that they could exploit it And because it has to run set you at root in order to do raw networking It would be a very tempting target to exploit So somebody could very well come up with a net filter module That if it spots an MTR in process across their network Exploit it and gain root privileges on your system So here's a simple profile for MTR That provides a handful of capabilities Capability net raw capability set good capability set you it Net raw is because it will do raw networking Set good and set you it or so that it can drop privileges on its own Network iNet raw is so that it can do the raw networking tasks it needs It has access to its executable And it has access to the term info It wants to know how to display stuff pretty in an incursive style interface That's it. It doesn't have right access to anything on your file system It doesn't have the ability to load the kernel modules doesn't have the ability to modify files Can't send signals to anything This is all it does networking and dropping privileges This is another profile I use it's extremely small, but I use it practically every week It allows reading everything on the operating system But it doesn't allow writing anything it doesn't allow any network access So I can use this to inspect zip files On the security team people send us zip files full of crazy stuff all the time And I would be a fairly tempting target for somebody So this is a tool that I use in order to inspect zip files This is a tool I used when I use object dump It can read whatever I want to feel feed to a program But it can't write anything it can't get data off the network It can't do any privileged operations It does nothing it can print output It's important to realize that app over profiles are written from the perspective of the process Not the system this is sometimes kind of hard for people who might be familiar with se linux It doesn't matter What a file is known as? Globally that doesn't really exist instead it based on what the process Thinks the name is Because the process namespaces can change it looks up names on the process namespace Capabilities are looked up as part of The username spaces so a program that's executing in a username space Will be able to use capsis admin and it's not the real capsis admin It's just the capsis admin that the process thinks it has When a process is confined it's pretty much stuck that way The only way the process can get out of the profile is to transition to another profile Either through an exec call or through an explicit call to do a transition Or if there is a specific Allowance in the policy for a program to be able to unconfine itself This actually exists. I've never seen it needed never seen it used but it does exist And a process becomes confined either when an unconfined process executes a program There's a attachment specification and with the mtr program. There's a nice typo The user sbin mtr up here Will catch any execution of user bin mtr or user sbin mtr and attach it into this mtr profile We use these ugly shell globs to describe The different path names across multiple distributions Susa has some files in some places debian has it in other places So This is one way to adapt and normally when we have to use an ugly name like this We will give it a pretty name like profile mtr So that when you use psz it will show up as just mtr In order to use that read all no net Profile that I showed earlier. You can use the AA exec tool It knows how to manipulate the sysa the procfs entries To say I want my next execution to be in this profile And you can see you try pinging and socket calls denied. You don't have the capability for it You don't have the network capability for it Another aspect that's that's commonly difficult for people to understand is that Users don't really exist processes exist And the process Executes on behalf of a user or a service So the process will have multiple user id they'll have file system id user id effective id saved id There's like seven of them and similar with group IDs It'll have capabilities and app armor now adds security domains All the processes are created from a parent process And all processes inherit the privileges of their parent The profile or the Authority the program has the permissions that it has can change across executive e-calls So set you would set get executables can change permissions Close on exec file descriptors are closed and in this case app armor now adds you may transition policy If the policy calls for it so you need to Approach profiling systems with a certain amount of Desire of what exactly it is you want to accomplish you have to know your threat model of what it is you're protecting against If you trust your local users and you want to confine your network You don't trust the network packets Then you might just confine the daemons themselves That way if the daemon is compromised it can't get beyond what it was already allowed to do If you don't trust the local users on the system, you may want to instead Focus on the shell scripts that start the services Shell scripts are very difficult to write correctly And they quite frequently assume that local users are completely trusted so it may make sense to move your policy writing a little earlier in the execution And if you have a goal of confining users say you Have staff that are allowed to do anything and students that are allowed to do nothing Well, you may want to confine your pam applications All users will enter the system through a pam aware application And once you have done that you can confine their shells or their user interfaces However, that works out. So here's a simple profile for I don't trust my users, but I want them to be able to do their own data They can execute anything that's in bin or user bin They're allowed to use libraries And they're allowed to do anything in their own home directories To data they own App armor doesn't actually have a way yet to say A user can only operate within its home directory because the kernel doesn't know what a home directory is But you can say the user has to own the data that they're going to operate on so they can't read each other's files They can't write each other's files. They can't link to each other's files They have to be able to own their they can only operate with data. They already own Now these text interfaces are friendly for people But they aren't very friendly for the computers and app armor's first Version when I started working with it in 2000 was indeed basically a plain text that the kernel Interpreted all the way through That doesn't work real well. It Has terrible execution performance and we have Since changed it to a compiled state machine. The state machine has a guaranteed execution time It will not take longer than Two steps per input character on a file name, for example The input is thus bounded and you can't actually use app armor as a way to create a denial of service attack Just by saying I want to access this specific file with a crazy file name over and over Red jacks engines are quite popular attack targets if you feed them something that's 18 characters long You can tie up the cpu for minutes and app armor has a different implementation That has restrictions and those restrictions allow us to have very predictable execution App armor 3.0 when it will release soon will have multiple caches We cache these policies as they are compiled and these multiple Caches will allow users to swap between kernels as kernels add new features Oh, that's fantastic. It's already in devian 2 with a app armor 2 13. That's fantastic So app armor can mediate files of directories capabilities p trace signals mount our limits Course grain networking This is something Ubuntu has had as a external patch for absolute ages And we are finally getting around to an upstream first policy And so this is something that has now been pushed into the mainstream kernel And unfortunately due to some difficulties It will require a slightly different user space to use but that is coming shortly Unfortunately, it is course grain networking controls. You can say this process is allowed to use inet inet v4 whatever address families you like, but you know, everybody cares about inet inet Inet v6 You can say whether it can use streams datagrams, whatever Debuss is another thing that ubuntu supports And it's partially in the upstream kernel To do it correctly also requires unix sockets to be mediated And that is also not yet upstream. It's coming soon I hope it's in the next 418, but it might be 419. We'll see how this goes Anyway, what we can do is already extremely useful Limiting access to files and directories was where app armor started Capabilities made app armor the easiest way to use linux capabilities for many years You could grant this process You know capsis admin and it wouldn't be able to do capsis net things Or you could grant capsis net and not capsis admin P trace prevents programs from using the debugging facilities of the kernel to escape their jails Signals means you can drastically increase the reliability of your system as programs can't just send signals to each other Signals are a very popular Attack boundary Signal handlers are normally pretty poorly written people don't understand signals well And if you can confine somebody from sending signals you can drastically increase the reliability of your system App armor is also the easiest way to set our limits on a process If a program doesn't already have this built in Typically you have to run to a shell command To a shell built in in order to do something similar But you may not always have a shell in a location where it's convenient to execute our limit commands or your limit commands So app armor can set these on runtime And there are other aspects of the system that we may Work with in the future There's no guarantee on any of these The ima aware policy. I don't know if you guys have heard of this either ima is an integrity measurement system And it's basically signed binary signed executable signed libraries signed everything And we have a contributor from google who wants this on their operating system for their own internal use And they've been kind enough to contribute this to upstream work And hopefully this will be available for everybody soon Uh everybody wants fine-grained networking. It's one thing to say My web server can do Inet but it's quite another to say my web server can do inet on port 80 import 443 So this is something that everybody has wanted for many years and the implementation is difficult and it's always just a second priority Hopefully it'll come soon Shared memory segments are currently completely unmediated not many things use them So it hasn't no one said hey, this is something I need for my use case But you know, it wouldn't be hard to add same with semaphores x11 ace If we were to implement this would allow us to give Basically compartment mode work stations Which is something that the department of defense spent billions on back in the 90s And nobody ever used because they were difficult, but we could do the same thing Uh zfs is just something that I thought would be fun to do. I've been a fan of zfs for years C groups overlay file system support policy for specific users and groups kernel key rings Charoo currently we can only confine whether or not a process can call charoo We don't have any ability to say you can charoo to this specific directory That's something that we would probably like to have And sipso is security labeled networking so that you can only interact with Specific tasks on other hosts within a network if you have a secured network you can say you know have A high security traffic and low security traffic and just outright label your traffic And say which processes can interact with which One compelling new feature that app armor has had and is uh finally getting some actual traction Is multiple namespaces You can create namespaces for your profiles So that you can have one global namespace for this main operating system And lxd can have their own profiles Libvert can have their own profiles snapd can have their own profiles docker can have their own profiles And this allows them to use The system profiles to protect the systems from the guests and allows the guests to then use Profiles as if they were a full normal system One that we would like to add in the future is for users to supply their own profiles This does expose more kernel Interfaces to user space So it needs to be done carefully and thoughtfully and hopefully with a bit of fuzzing Another recent development is app armor can stack profiles And this is what I mentioned with lxd or snapd being able to protect the host from the guest With one set of profiles and then the guest can then use profiles itself To keep applications separated to keep users separated whatever they need to do they can do as well Other options with stacking and uh, this is a little more I don't know how many people have actually used this in production But it's possible to apply a blanket profile to all your users Say you've got students and you don't trust your students Or you've got sysadmins and you do trust your sysadmins You can stack profiles so that they can you know, your users are stuck with absolutely no access to system controls They can't run sudo say Per application profiles can keep applications separated within a user so your firefox won't have access to your gpg keys You can also provide other Kind of simple profiles like my read all no net That have one purpose and that purpose is to prevent access to the network Or prevent access to capabilities prevent access to ptrace and these can be layered together and A matrix or lattice to come up with some fairly creative policies that are extremely simple to write And i'm sure there's a lot more interesting things that are possible here I think Yes, there's time remaining Let's do a small demo so here is The process listing on my host system just my life. Yes I have no idea how It is uh, yeah No, I do not X term hey, I have X term That large enough. I didn't even think of that Okay So here's a fairly unreadable psz output And you can see that i've got a bunch of lxd gunk over here A bunch of unconfined zfs processes Pulse audio is enforced. I don't trust pulse audio dh client enforced firefox enforced cups d enforced And this lxd gunk again And within my lxd instance that i've got called healthy fly The profile name is just user s been engine x That's in enforce mode. You can see i've got a confined It's just a standard profile applied and the Lxd instance has no idea that there is another app armor profile on the outside And the lxd profile on the outside is protecting the host system And the app armor profile on the inside is protecting the rest of the guest from engine x and In order for every access control to be allowed. It has to be allowed By both profiles in the stack and these stacks can be arbitrarily deep However, much best you want to make you're allowed to make So I I got a feeling that this is uh Game changer is such a stupid word But it really is uh exciting for me to see that we can have app armor Applying to have multiple security goals One within the container and one outside the container and they're working in conjunction with the same mechanism I this is something that truly excites me. I hope you see more of this in the future Leave that is it. Yes So at this point I like to open it up to questions Comments thoughts hate mail love mail I'll take that as love mail You mentioned applying stacked app armor profiles to users What is the preferred mechanism for doing that because I've been using pam to do it and it's not particularly fun No, it is not the pam app armor module is a pain in the butt because it requires using change hat And I believe if it were to allow just applying a profile without change hat, it would be far more pleasant Does that sound right? Yeah Okay, then I will I will work on that. Oh, thanks a lot. Yeah, it's I Unfortunately something that I have always felt would be better served with a different mechanism and You know so long as nobody seems to be using it. It's just you know I don't run shell server. So it's kind of hard for me to you know, it's a feature I feel passionate about but not enough to do for myself Yeah, so thank you. I appreciate that Well, thanks a lot for hopefully fixing it and anyway for working on app armor in general Hey, I think that's that. Thank you all appreciate it