 So welcome to our next talk about app ammo. So please give a warm applause to Christian Bolz. So welcome everybody. I'm Christian Bolz. I'm working on App-Amoire upstream mostly on the tools. And I'm also the package maintainer in open source. So what does App-Amoire do? The answer is quite simple. It allows applications to do only what we are supposed to do and denies everything else. But it isn't that easy because first it must know what is allowed. So why should you use App-Amoire? Well in a perfect world you have bug-free and secure software but you probably know that you won't find that software out there because programmers can perform magic. And so you better keep an eye on what we are doing. And App-Amoire will monitor the applications on the kernel level. So let's continue with my infamous bank robbery slide. Hands up please. Who is using App-Amoire? Okay, that are quite some people. Who of you already created or updated the profile with the AA something tools? Okay, that are less hands. Who edited the profile with VI or another editor? Oh, even more. Okay. And cross check who did not use App-Amoire yet? Okay. So let's start as usual. Hello world. You never can avoid that. So that's a little bash script and I'll create a profile for it. So to create a profile, you first need to run an agent proof name of the script. That's the first thing you do. Then run the script. So you see it brings hello world, not surprising. And then back to the agent proof. So you press S for scan the log. And now it shows execute cat. So you have different options how to execute it. In this case, I'll use inherit. So press I. And the same for M. Then it obviously needs to print out hello world. So you could enter a low PTS five, but that's dependent on the console. You use it. So instead, you choose the console abstraction, which allows the PTS everything and the TTI and so on. So everything around printing on consoles. Press R to allow it. Then of course it needs right access to its temp file. Also a low. And when done, you can just save the changes by pressing S. And finally F for finish. So how does the profile look now? It's quite simple. So the first one is you enables global that are some variables that you need in basically every profile. So it's always there. Then the base abstractions. It uses bash. So there's an abstraction for files related to bash. The console abstraction we added. So it of course needs to run bash. It reads the script itself. Reads and writes the temp file and executes cat and M. Okay. So far so good. So we have our profile. Back to the slides. We have a little problem if there's a hacker around because that script has a security bug. Does anyone know what the bug is? Okay. I think just shout it out. I'll repeat it. Ah, okay. Good. It's possible to rewrite hello.txt before it's cat. No. That's not a main problem. No, but you can create a sim link. Yes, exactly. So let's go back and just play hacker. So I'll show you the script I'm using to avoid typing. It's just creating a sim link. So yes, you see it's meant to replace a file. You probably still need. Okay. Let's create the sim link. You see, here's it. And then run the script again. Permission denied. So let me just repeat as good. And what I guess the script delete the sim link. So I have to recreate it. So first recreate a sim link and then run again. Exactly. So you see permission denied. And then cat says that file doesn't exist because actually I don't have other. He's for route. But you get the point. So in other words, up a more just prevented your first exploit. So what does up a more do? It monitors and restricts file access. Network capabilities like change on. And you can get a full list in main seven capabilities. You can set a limit. Okay. You limit and in general restrict permissions. Counter question. What does up a more not do? It doesn't replace the traditional fine permissions. So please do not change mode seven seven seven everything. It also doesn't replace user permissions. So you shouldn't run everything as route. And when it comes to web surface, then you should do the usual stuff like having a MySQL user for each hosting and task, validate user input, escape input. You might also want to use the Suo scene extension for PHP or avoid PHP applications at all. Maybe. Some of them. My general rule of thumb. Google for application name and exploit. And if you have more than 100,000 hits, you should avoid it. So that leads to the question. Is the server secure now? Well, it depends. Security is always like a puzzle with lots of small parts. And Obama protects you from lots of things, but not everything. So the server is more secure. But you can't say it's perfectly secure now. Except if you make your profiles very strict and then it's limited to overriding things that it can write anyway. But at least it gives you additional security and makes sure it only destroys its own things if it destroys something. So let's come to the up a more tools. There's AA status, which shows you an overview of loaded profiles and which running programs use them. AA unconfined is something similar. It gives an overview of applications that are protected or confined. So confined means protected by an Obama profile. And it also shows things that are not confined. AA notify can give you desktop notifications or can be used to create log summaries. Then we have the set of tools to switch profile flags. That means AA complain switches profiles to complain mode. That is a learning mode which allows everything and logs what would be denied. AA enforce is the opposite. That means the profiles denies everything that is not allowed. And look what is denied. We have AA disabled to completely disable a profile. And we have AA audit, which means to set or remove the audit flag on a profile. So everything is locked even if the profile allows it. So the next set of tools are those to create and update profiles. AA log proof is used to update profiles. AA chain proof creates a new profile. We've already seen it for the Hello World. AA auto-dip is a tool to create a very basic profile, but usually you want to use AA chain proof instead. That's easier than reading the log and doing everything else manually. And AA EC proof is a template-based system which I think Ubuntu uses it. Then we have some more tools like AA merger proof. So if you have three surfers and want to have the profile updated everywhere, you can use AA merger proof to make one profile out of two slightly different ones. AA clean proof makes the profile more readable and removes superfluous rules because, let's say, we are covered by an abstraction. Then if you read the log, you might hit a case where you see instead of a file name just a long cryptic string. That's when you need AA decode, because that translates those encoded file names to something readable. And we have AA exec if you want to execute a binary with a different profile. So let's have a look at AA unconfined. That's its output. And you see the first three are in enforced mode, so everything like it should be. AMA with D is in complain mode. That means it has a profile. It writes to the log, but it doesn't deny anything yet. It's still in learning mode. And finally, we have the, we as FTB demon, you see, not confined. And it's time to fix this because a general rule is everything that is listening on the internet should have a profile. So let's just create one profile. Then, okay, so it's started. And let's scan the logs. And you see it obviously needs network access. So allow it. Then it needs network access. You see in its extreme. Oh, sorry, wait, wrong window probably. Yes. So here we are. Okay. So it needs access to the network. So the question is now, do we allow just network and it's extreme? Or do we also include the name service abstraction, which includes it? So now let's use the more strict variant. It needs to read its own config file surprise. So, so far, just save the changes, but don't finish yet. And now we'll go back and just do like that. Okay. I think it can't read the input file, but let's ignore that one now. And just see what the profile misses. That's quite something. So it needs to write to the audit log. It's a log in. So you want that. Allow it. And then it obviously needs said kid and said you ID capabilities so that it works as the user and not as good. So also allow it. FTP demons to change road. So next one, you want the abstraction here for the identification. Then also allow it. FTP users. And now you see it needs an a switch con. So it's probably a good idea to allow the whole name service deck. And that's it. Save the profile. Finish. And let's have a look at it. Here we are. See the abstractions we added. The capabilities. You can also see in vi audit right is in red because it's a more dangerous capability. And also you see. Yeah. A bit of color. So for vi there's a file that supports the file highlight. Highlighting. Okay. Back to the presentation. So. Short. What I did is to when you create a profile, you need two x terms in the first one. Start. And in the second one, just use your application. And the general techniques is first when you profile a demon, just start and stop it. That will already give you lots of log events. Create a profile with them as a start. That keeps the log small. And then use the application and then update the profile again. And when you are finished, you might want to use a complain to keep the profile in learning mode for some time. Because. I mean. FTP demons are quite easy, but for more complex applications, you will not get everything in 10 minutes. It's a better idea to have complain mode instead of being annoyed every two minutes because well, there's one rule missing again. So you can just do one a a look for fun. An hour later or so. So there are different file permissions read write obviously. There's a different permission for append, which you should use for look files. L is for link permissions. K for file looks. M for M app for loading libraries or so. And there are various execute modes. Those are the I X for inherit, which I already showed. That means the program will run with the same profile. That's useful for helper applications and shells like cat, crab, I am boy has whatever. And you can also use it for role based access file confinement. So you can say you can find the shell of a user and he's allowed a specific set of programs, but all in inherit mode and therefore can limit him. Then does the child execute. That's useful for when one program calls another one. But you don't want to have a standalone profile so that if who called is called by bar. You don't want to have a profile that is used if you call full standalone. That's useful for help us that need more or less permissions than the main application. So in theory, I could have used a child execute for my hello world example for cat, I am. Another option is to create a separate profile. That means it is used when the other program is called. Doesn't matter if it's called by the first one or not. And that's not a good idea for being bash. And actually the tools will not even allow you to create a profile for the bash as standalone profile because you will have a unusable system afterwards. And finally, there's the option to execute something without about protection. So unconfined or UX in the rules. And for example, you can use that to protect your SSH statement and remove the restrictions after successful logins. So the demon is restricted, but the users can still work without limits. And we also have fallback options so that you can say if a profile doesn't exist, then use inherit or if that's the peaks. Or if a profile doesn't exist, then run the other program unconfined. Yeah, you shouldn't do that. Same for child executes with the inherit and unconfined fallback. So you always have some examples in the bottom right. And what you can also do is to name the execute target. So you can use a help up for some binaries without having to duplicate it. And the syntax is the binary you want to execute the execute mode PX and use the profile P. And you can also use wildcard. So like user bin everything should use the child profile help us. Then a HN proof and a log proof will always ask you if you want to clean up the environment variables. In general, yes, you do not want to have things like LDP reload in your environment when executing something else. And if you have a really good reason, then you can say no, but please think twice about that. So far about the file rules, which are the most important ones. So let me just give a quick overview what other rules we support. There are link rules with some which somehow overlap with the file rules. Then we have set a limit so you can restrict how much CPU memory whatever process can use. We have capability rules. We have network rules, but those require a patch test is not in Debian yet and the other new rule types are also not in Debian yet. And for details, I can recommend reading the ABAMOID five man page. So short overview for the audit log. I know we are nearly out of time. Yes, I think the most interesting thing is translating the timestamp. That's the date minus the add long number. And you have denied for blocked events allowed for complain mode and audit for those. Okay, so the question is, I think afterwards does the break and we take some more minutes or not? Okay, nobody complains. I hope that's okay. So we have more ABAMOID for a patcher. Usually you put in your global configuration to a default headname just to evaluate that ABAMOID proposes a head for each file. Then you can set up a head for each virtual host and also for a specific directory. So if you have a customer which uses CMS in the forum, you can split the permissions for both. What is a hat? Hats are like sub profiles and an application can switch between them. And the typical use case is a patcher and the head for each virtual host. You have time. You have plenty of time. Don't worry. Okay, good. It's 45 minutes talk. Okay. Then you see the syntax is also like a hat. Then how do you configure that? Number one, you want an abstraction with the usual permissions so that you don't need to do a look for the very basic things. And you want to create that file with a script. So that allows like all the HTTP docs files reading writing to the access look and so on. Then there are some interesting things in what ABAMOID as I said, you should create those abstractions for each file host automatically to avoid that you have to do it every time. Then there's a special head handling and trusted input which is used when our purchase idling around. But unfortunately, it does a bit more than it should. So it usually needs right access to the looks of all virtual hosts. And it's also relevant how strict your profile is real world example. One of my customers had a web forum which allowed to upload our top pictures, you know, something like my photo dot PHP. So you don't want that. So ideally you just deny read and write PHP files with the owner flag. That means if Apache wants to read or write a file that is owned by the Apache user then it's blocked. That's good. Again, new exploits but the problem with it is if you have a content management system which wants to download extensions or something like that. That's also blocked. So it's not too easy to use that rule. So there's also some creative usage of ABAMOID. I'm using it as an inventory list so I can see which virtual host uses a script in my shared directory or which host is calling send mail and so sending mail. It can also used as a debugging tool so which files does the application read or write. And it's easier to use AHN proof to create such a summary than using strays and filtering everything out that you need. An important thing you need to know is the PS uppercase set because that includes the profile name used by the processes. And that's especially useful if you see oops I have 100 Apache processes running and it's blocking everything. Who do I need to blame? And another interesting example is read only root access for doing backups. That's a two component solution. First you need your SSH key of course. And the important part here is the restriction with command root bin as in shell. And in that script I'm just logging the SSH original command. Verify that it starts with as in minus minus server minus minus sender. And if it's okay then I execute it. And of course you need a profile for it. That's how it looks like. You see some abstractions nothing surprising. The capability take override and take read search means that root is also allowed to read files who are not readable for root based on the file permissions. So if you have a file user readable only and it's not owned by root, Abamua would deny it. And with those two capabilities you are back to the normal behavior like root can read everything. So yes some execute rules of course and the rules to allow read access to the things you want to backup. And the most important is inherit as in. So as in runs with exactly this profile. So far to the part about Abamua in general. The next question is, is there any relation between Debian and open source? Well, depends on how you turn it. And now I'd like to have Ulrich here to explain some Debian specific stuff. Yes, I think so. Hi, yeah, I'm Ulrich. I'm here on behalf of the PKG app armor team in Debian. So what's the relationship between open source and Debian now I'm supposed to explain that. Thank you. So actually now Christian explained how to create Abamua profiles, but there are already a lot of Abamua profiles which are maintained upstream, which are used in Ubuntu, for example, and an open source and in Debian. In Debian, we try to contribute to the upstream Abamua profiles so that we would all share them. There are some specifics. Basically Ubuntu has Abamua enabled by default on their distribution and they tend to ship the profiles for packages in the packages themselves, which would also be the goal to do in Debian. However, today that's not yet the case, only for some packages. In Debian, if you install Abamua and you enable it on your machine, you will get some profiles, but if you want more profiles, you either need to install the Abamua profile extra package, which will give them to you, except for some packages which I don't know by heart I have to admit, but maybe Intrigui knows them. For example, in JC, we have quite a bunch of packages. Stand up, please. In JC, we have a bunch of packages that ship profiles confine themselves. At the top of my head, I can mention Tor, Caps, Libert, Bind, MySQL and a bunch of others. Package maintainer and you want to ship an Abamua profile, which already exists, probably now it would be in Abamua profiles extra, or you will create it. In the latter case, you create this profile, you should contribute it upstream. If it's already in Abamua profiles extra, you can write an email to the PKG Abamua team list and take the profile out of the extra profile package, put it into your package and use the DAP Helper DH App Armor to copy the profile where it belongs to. All this is documented on the Debian Wiki under wiki.debian.org slash app armor. Also, on that wiki page, you will find instructions how to use Abamua. If you simply want to use it, it's actually quite easy. Much easier than what you heard until now. And after that talk, we want to have a little meeting about a repository where we would share all those profiles between different Linux distributions because for now there is an upstream repository on Launchpad under Bazaar. But we want to have a better collaboration between all the distributions and share all the profiles so that there wouldn't be so much delta in between. Yeah. Anything else? Somebody wants to say, oh, and yes, we are here. So now you've seen me and Trigery. Please go to the wiki page where you will also find instructions how to report bugs properly if you encounter them and they are probably related to Ab Armor. We've created some user tags for that. Yeah, that's pretty much it. Any questions to myself? Okay, so it doesn't seem to be the case. So I think I have one or two slides left. Okay. So if you need more information, there's the Abamua.demand page which explains the profile syntax. There are of course also main pages for all the tools and so on. There's a page in the open source wiki, probably not too interesting for you. The Debian wiki, the Abamua net upstream wiki is quite interesting and maybe you want to read the open source security guide because it's a quite good overview if you want to get started with Abamua. And for interactive support, you heard the Debian mailing list. The upstream mailing list is available and of course also the chat channel Abamua on OFTC. And if you want to see more geckos, then I would be happy to see you at the open source conference and birthday party in next spring, probably in Nuremberg in Germany. So any questions? What's your vision on this cross distro profile repository? I mean, why don't you just push these profiles into the upstream source packages they belong into? That's the theory, and probably I think the best answer I heard was I'd love to see the upstream developers care for Abamua as much as they care for SE linux and then I asked, what, well, nothing. So you see, it would be perfect, of course, but the problem is that most upstream developers of various packages just don't care, so we have to do it. And the point in the repo is also to collect all profiles in a distribution. So if they come from the Abamua team or if they come from upstream, maybe we want to have a place where you can look up all the profiles in a distribution, all the distributions. You explained how to create new profiles and to apply them, but how about the profiles which are in the distributions coming with the program and you have to change anything on it. I don't want to override these because they come with a package. I don't want to change them. Is there a way to do that? Well, there is. So the easy method is to use a look proof that works the same as a HN proof and it doesn't create a totally new profile, but it asks the same questions. So as I've shown, the problem with it is it will override the ship profiles. There is a way if you do it manually that always includes like include local profile name. So you can edit those local files and the distribution will not touch them. There are also plans to add support to the tools so that the tools write to those local files, but well, you know, I don't need you to tell you what to do with this. Any more questions? So if you're doing a cross distro repository, how are you going to handle distribution differences? So will this kind of be a pick if then else maybe include mess? No, it will be a good with branches. And the goal is to have most things in common, of course. And I didn't mention the tunable files. So you can say, for example, you have a tunable if you have different paths or maybe you even say, well, the path is different, but it doesn't hurt if we allow the other one to so we have a common profile. So one of them. So we have the option to include differences, but we want to avoid it because, you know, having lots of branches means a maintenance hell and you don't want it. But if you are interested, just stay here after the talk. More questions? It doesn't seem to be the case. So thank you for listening. Thank you and enjoy the conference dinner.