 or any organization with a high cost associated with compromised data, organizations faced with regulatory compliance, yeah, yeah, whatever. I like to say that app armor is an appropriate technology if you are hosting something on Linux and you care. So what it's doing is it's creating a firewall of sorts around each application to say what it's allowed to access. And if you can control what the application can access, then you can prevent the exploitation of vulnerabilities because the attacker, they might be able to pop the program but once they've done it, the program only has access to what the program is supposed to have access to and they can't do fun things like, for instance, spawn a root shell. And another important feature of this is that because we're controlling what the application should do instead of what the attacker can do, we don't rely on signatures. So it doesn't become out of date tomorrow afternoon. So the benefits of this kind of thing is that IT has enhanced productivity. And that enhanced productivity, that's an odd effect and it's because if you're constantly scrambling for security patches, in the middle of a night or in the middle of a payroll run is a terrible time to have to apply a security patch. It's very expensive. And if you have App Armor in place or something like it, then you can say, well, okay, we have this security advisory but we don't really care because it can't really be exploited. So we're gonna wait until the end of the month when we're scheduling an update before we apply this security patch. Oh, and bonus, someone else will have tested the patch for us because they deployed it and complained to the vendor. It enhances your software reliability because it is much easier to specify what a program should be doing than it is to make sure that you wrote the code correctly and that's only what it does. And it grants peace of mind. It makes me nervous to deploy something in the field and not know whether it's safe. So developers and IT can sleep at night that their machines are that much safer. So that's the marketing fluff. Getting into the details. This is the box of arrows diagram of App Armor. Down at the bottom, the foundation of it all is Linux 2.6 and the 2.6 is important because that introduced a new feature called LSM, the Linux security modules interface. LSM is an API where you can plug modules into your kernel and you've been able to have modules forever in the Linux kernel but now you can have security modules that have enough power to be able to control access on the entire machine. So plugged into this modular interface is App Armor and above that is the user level software for managing it and over here would be your programs and each one of them has a security policy wrapped around it which we call an application profile because it profiles the behavior of the program. So if you're gonna put yourself in the business of saying no to everything, it's really important that you do a decent job of it. One very important issue is complete mediation. Complete mediation means that every possible path of access has been blocked so that the security system is actually controlling whether someone can go through it or not. So for instance, if you were to build a fence halfway around your house, your dog will still run away. So it's important that you can completely mediate. And in the case of Linux security or application security really, complete mediation is only achievable if you do it in the kernel. If you try and do it at the application layer or the library layer, then the attackers can sneak around you, they just won't call your library, they'll call the kernel directly. So this kind of technology must be in the kernel. On the other hand, security people have different ideas than kernel people about some things. And so it's kind of a problem if the security people say, well, we wanna be in charge of this kernel now. Well, some other people might have some disagreement with that. And so LSM deets things, so the security people can write a module the way they want to. And the operating system people, well, they don't have to worry about it because it's just a plug-in. The other critical issue is to make the model not annoying. There's two ways of modeling access control. The common one that people in Windows Land are accustomed to is misuse prevention. And that's where you come up with a blacklist of things you can't do. Anti-virus software does this. You can't do this or this or this or this or this or this or this. 70,000 virus signatures later. They're still listing because there's always a new way to write another virus. The opposite of this, the dual, is anomaly prevention. And that means you come up with a white list of things that you can do and everything else is blocked. That's much more secure because the fact that the attacker thought of something new has no effect. You blocked everything except what the application needs. So great, it's secure. But you have to have a complete white list because if it's incomplete, you're going to stumble over your own shoelaces when the security system stops the application from working. And that's what AppArmor is particularly good at. That's what we do is we use white list approach, but we provide a bunch of technology to do a really good job of rapidly and precisely generating the white list. So zooming in a bit, this is an AppArmor policy and application profile for NTPD. So people who are familiar with configuration security, the sort of things that Bastille Linux does know that you should close off all the network ports possible and be very careful about root privilege demons run it with open network ports. Well, NTPD, the network time protocol demon is such a demon, it needs root privilege because it's gonna change your system time. It needs an open network port because it has to talk to the network time server. And you can't turn either one of those things off or it stops being NTPD. Oh, great. So now if there's a vulnerability anywhere in NTPD, then someone can pop my machine and get a root shell. And NTP is not the only thing. I was all kinds of this stuff and can figure it away all of the open ports. Well, yeah, but that limits your functionality and that's why you had a computer in the first place. So what this AppArmor policy does, the profile says that whenever NTPD runs, instead of having all 27 of the POSIX.1e capabilities, it can only have these five for things like sys time. It needs to set the time, so we'll give it that. And it can only access these files where this is an absolute path name. This one here has a star in it. So at Etsy NTP slash drift star, so wildcard, it can access a bunch of files. And the access modes are read, write, and execute. So as a result, if someone pops NTPD, they can't get a root shell. There's no bash here at all. They can't go and steal my password file. It doesn't have access to the password file. They can't really do very much of anything except change the system time. So that's one program. How do you secure your system? The server analyzer that comes with App Armor scans your box, finds all the open network ports, finds the programs listening to those open network ports, and then tells you what App Armor profile, if any, is wrapped around that program. So if you can get your system to the state where all of the open network ports lead to App Armor profiles, then it's the case that those App Armor profiles now completely define anything that a network attacker could do to your machine. Yeah, at this point, you're a long, long way from having written policy for every program on your machine. And you're also at the point where the attack surface, the exposure of what an attacker could do to you is hugely down from what it used to be of every time you pop a root program, you get a root shell and you can own the box. Having picked a program to profile, you then have a template generator. This is a static analyzer that reads your program and emits a halfway done profile. Because of that little theorem by Alan Turing, it cannot do a complete job. So it does its little best, does a halfway job, and then you have to go watch the program actually run. You put it into automatic learning mode. The policy for that program is set to be complaint mode where rules are not really enforced, but violations are logged. So you run your program through its paces and every time it does something new, it logs it. And then you show this big log file full of events to the interactive optimizer, which looks at the log file and goes, oh, it accessed this file, should I allow that? Or better yet, how about I allow that with some wild cards in it so that it captures a whole bunch of other files too. And in this way, the interactive optimizer can turn a log file with tens of thousands of events into dozens of questions, producing very short policy files. And finally, there's a visual editor mode. There's a sample, which is a VI syntax mode that highlights different sets of the policy with different colors to show you what's important. And in particular here, file rules that permit right access are highlighted in yellow. So if you wanted to look at your machine from the point of view of what files could a hacker corrupt, you look at all your profiles and you look for the yellow lines. So that's a whole lot easier than wondering what an attacker could do to your machine based on all the software you've got on it. Some important properties of this policy file to consider. First is that it's not a new paradigm, it's an overlay on top of existing discretionary access controls. So the files that your program or you can access remain the same according to Chimad and Chone and those mode bits and read, write, execute, all that stuff has to pass first before App Armor even sees the question. And then it goes through the App Armor policy and decides whether, well, okay, the discretionary access said it was okay and the policy says it's okay, now you can access it. The other thing to notice is that there's no new jargon. All of the language is familiar. So path names are absolute path names using shell wild card characters just exactly the way you would use them in the shell. So the squiggly brackets, they mean what you think they mean. Same with the square brackets. Star means what you think it means, so this will match any file that starts with LD- and has a .so in the middle. That happens to be any of the dynamic loaders that happen to be in the lib directory. Home star.plan would give you everybody's plan file. Double star. That's not exactly shell syntax. That's the rsync syntax. And that means an arbitrary number of path elements, so including the slashes. So this rule gives access to the entire public HTML directory tree. And you can even stick suffixes on there so you can write star star .html if you wanted to give access to all the HTML files, but perhaps not all the purl source. We provide a collection of foundation classes, building blocks, and the way that works is App Armor lets you write a pound include into a policy, so you can go pound include that stuff over there. And stuff over there is components of common elements of software. So for instance, the name service package is all the rules you would need to have proper interaction with PAM so that the program can do authentication of users. Console is all the rules for dev TTY things so that say a console program like Bash can talk to the keyboard and such like. App Armor includes a special feature called sub process confinement. Most access control systems think that the smallest granularity of access is a process because that's the smallest thing that the kernel tends to consider. But we can get below processes and this is important, especially for web servers where the classic way of running a CGI script on a web server was that Apache would fork and exec a Perl interpreter and then run the program which is really cute but Perl is like a five megabyte executable and that works once but if you wanna have hundreds or thousands of transactions per second it ain't gonna happen. So they came up with mod Perl, puts a Perl interpreter inside the Apache process and now when you wanna run a Perl script it just opens the 100 line Perl script sucks it in and interprets it and it can do that much faster than you could if you had to do a fork and exec. So that's great for performance and terrible for security because now you're running all of your web applications in not just in the same security domain but in the same address space. And all of that is also true of PHP but more so because there isn't even an option for running your PHP scripts externally. So app armor adds a module to Apache and we call mod change hat. So this reflects that Apache is going through different software roles, Fireman's hat, Policeman's hat, Mayor's hat. So the mod change hat in Apache calls app armor and says hey I'm changing my security context of this thing over here and in that way you can actually run individual PHP pages inside their own security domain. This is unique it's the only way I know of to defend against bad PHP code. We also use this same feature for a privilege separation in SSHD so that if there was a bug in SSHD it would be confined to the profile that is everything needed to do authentication of users and nothing else. Only after it passes authentication does it pop out into a more general profile where you can do things like exec shells. Performance overhead is very small. When we measure it at the application layer it tends to be in the zero to 2% range biased mostly towards the zero end. To get it to show up as 2% you have to be running very very small Perl scripts so that the overhead of just saying hi I'm with app armor starts to become a significant fraction of the total run time. So for the most part it's performance neutral. We include a set of standard profiles for Linux services. Apache, PostFix, Send Mail. The usuals that you turn on to have open network ports. And the app armor tools are there to help you customize them to your environment. App armor's integrated into the SUSE YAST interface. There's a button that says hi I'm app armor. Configurable reporting and alerting. And a command line interface for those of us who are a little bit allergic to mice. So this is a demo. What I'm gonna do is demonstrate attacking a vulnerable piece of web application code on the web server running on my laptop and then go back and fix it. And then we're gonna build an app armor profile for Apache while we're at it. So here's our local website. And digital airlines is running this web application. And it's just a cute little web app that looks up people. This is a genuine vulnerability. It's ancient but it's genuine, I didn't create it. The hack attack is to put some shell commands on the URL line and the program is dumb enough to actually execute them. That, well it has unfortunate consequences. So I'm gonna put this back using the same vulnerability because that's the fastest publishing method I could find. Now let's go build a profile for Apache and for this web application. This is FOSDEM so I'm gonna use the command line. So you say build me a profile for whatever program and that happens to be the path to Apache on SUSE Linux. It's already done the static analyzer and now it says okay run your program and I'll watch. So let's get another shell here. I do a restart on Apache and you see a whole bunch of traffic running down here in Syslog. This is tail running on Syslog and those are learning events going past as App Armor learns what happens when Apache does a start. We're gonna go visit the homepage and this is the stuff for serving a webpage and we run the web application and it learns what it takes to run the web application. Don't run the hack attack. Don't smoke in front of your children. Just generally don't teach bad things. So let's do another restart on Apache so that App Armor can see what happens when it stops. So now we have this log file full of bunches and bunches of events and you could get a clever geek to go turn that into a policy but that would be tedious and that's what happens with security is if it's tedious people just don't do it. So instead we're gonna ask the App Armor software to generate policy for us. So we hit scan, scans the log. The first thing App Armor wants to know is it saw Apache launch this PHP child process and it wants to know whether, excuse me, PHF, whether it should be part of Apache's policy or to have its own profile externally and I'm gonna choose P for external because that's more secure. Then it has a bunch of POSIX capabilities that Apache asked for so we're just gonna give it all of them. Apache wants to read into the Apache configuration directory. Well that seems perfectly sane. It wants to read deep into the Apache configuration directory and it occurs to me that that's a big furry tree. I don't know what all is down there and I certainly haven't accessed it all so if I just give this rule explicitly then my profile will break later when my Apache does something a little different. So I hit the glob key a couple of times and now the suggestion candidate three says okay Apache gets to read everything in Apache 2 Star Star, the whole sub-tree of the configuration tree and it's read mode and it's Apache so why not? So we'll allow that. It wants some MIME types, NSS, name service and App Armor notice that this event is satisfied by the pound include name service package and so if we choose that then all the other name service things that are about to come up and hit us they go away. It doesn't bother to ask us about those things. Some PHP things, some group things, DA login blue arrow dot gif okay that's somewhere in the web docs tree and I don't wanna specify all those pages so I'm just gonna let Apache serve all the web pages, seems reasonable. This one is interesting. No actually I can't, oh I can move the, yeah there we go. Yeah sorry video hacking. So here App Armor notice Apache accessing libice.so.6.3 and the first suggestion is why don't we wildcard the 6.3 so that when we upgrade that to 6.4 it still works. The second suggestion is you're probably gonna access a lot of libraries in there so why don't we just wildcard the word ice and give you all the libraries. So you can choose anyone you want. Security minded admins 10 towards number four because they're going oh but if I allowed access to a whole bunch of other libraries that would be dangerous. Well yeah kinda but not very and this is a whole heck of a lot tighter than anything you've ever used before. So going with number five is still actually quite secure and much more flexible so it hassles you less about well what about some other libraries. So I tend to recommend a liberal use of the glob key. Here's another interesting case where it's accessing modcgi.so and if you hit glob with extension it wildcards the modcgi part and leaves the .so alone allowing you to grant access to all of the files of this type very quickly. Here's another one and another one. Some other stuff, some logging things, some mime stuff, some SNMP stuff and I globbed it up because I don't know what it's doing in SNMP and I don't wanna find out I'm just gonna give it read access to all that SNMP stuff. Little more logging and the PID file and we're done. That's how long it takes to build a policy for a major service. This is the colorized syntax view. Those color choices work better if you have a black terminal but it's highlighting in yellow the couple of rules that have write access. The black stuff is boring ordinary read access. The purple stuff is wildcards and green means someone else's profile so you should go look at that too. Notice that I didn't restart Apache. It just overlaid the policy on top of Apache as it is. So now we can visit the home page, we can run the web app and you can try to run the hack attack but your home page is intact because app armor blocked the access where PHF the first thing it tried to do was run bash. Had it been a bash script it would have had to have execute permissions on bash but it would still be confined by the profile for PHF and so among other things wouldn't have had access to write over index.html. So that's the security impact of app armor. You can create profiles in minutes for major services that block attacks. Not my mailbox, my presentation. So in a similar way you could build a profile for a client program like game. I use game for my instant messaging. It's great. It talks to IRC for my developer friends. It talks to Novell group wise for the suits that I have to interact with. It talks to Yahoo instant messenger for talking to my wife and my mom but it's been known to have a vulnerability or two. All sorts of vulnerability issues where if some nasty IM person tried to send you a message they can own your IM client and then own you. And so I like to run game with a profile wrapped around my game client so that if someone tries to hack my game client because I'm chatting with strangers they find themselves in a cute little profile that can only basically run game. They don't get right permission on anything interesting. They don't get execute permission on anything interesting. And the same thing applies to your mail client in case there's a buffer overflow and handling the headers of some obscure format of RFC 822 which has been known to happen. Or your web browser in case there was oh say a bug in the WMF handling. The major alternative to App Armor in the open source space is SE Linux. So this is the biased competitive view of App Armor versus SE Linux. The first case is that the full power of SE Linux appears only if you relink your application with LibSE Linux. And that's cool for open source stuff like MySQL. It's something of an issue for proprietary software, Oracle and SAP. They don't have much of a sense of humor about requests to recompile their software. This is a network computing review of Red Hat Enterprise 4 which includes SE Linux and it says yes, these security policies, they're very nice. They work on the configuration out of the box. They don't work if you change the configuration and it's incredibly difficult to change the SE Linux policies yourself. This is why. This is a summary of the seven page manual on Red Hat about how to create an SE Linux policy for an application. And this is the corresponding App Armor procedure where steps two, three and four correspond to this stuff over here. In steps one and five, the server analyzer in the visual editor mode don't exist in the SE Linux version. So there are 16 steps to our three steps. That would be a cheap shot if our steps were huge and their steps were tiny, but they're not. Our steps are run the programs and answer the questions and their steps are edit this configuration file and debug that other thing. Here's equivalent policies for the Woo FTP daemon. The first thing to notice is that the SE Linux policy is four times larger, simplicity as the sole of security. And then you go and blow it up and look at it. This is a fragment of the SE Linux policy and you discover that it's a new programming language. It has ifs and elses and stuff and brackets and there's a book on this from O'Reilly. You can probably get it out front. It's about this thick. The App Armor policy is those absolute path names with the read write execute and the shell wildcard. So if you know how to use Bash and Chimad, you're pretty much trained on App Armor. To deploy it, you generate your security policy using the gen-prof command that I demoed. You just deploy your security policies onto the production systems and configure your reporting and alerting. And hooray, we're safe. You wanna do an update on software. This is an issue, version 2.1 of that thing you're using might access some new files. So you wanna put it back into learning mode for a while to catch those cases. If you QA your software on a test machine, then you'd go do that on your test machine. As you're QAing the software, you'd put it in learning mode and it would learn stuff. And if you don't, you're daring, you just stick it straight into production. Then you just put your production machine into learning mode. Oh, that's dangerous. Yeah, you're as dangerous as you were before you had App Armor. Except you have this intrusion detection system running that's saying, ah, someone did something surprising. And if you don't do any of these things, you just upgrade the software and leave it in enforce mode. App Armor will block the funny new access. But it will also log it in such a way that if you just run the learning tool to say scan the log, it'll go, oh, hey, there was this new event. I think it was an intrusion, but you can do what you want and just say allow and it updates your policy. So App Armor is now included in SUSE Linux. It shipped with SLEZ9 SP3. It shipped with SUSE Linux. It will ship with SLEZ10. It shipped with SUSE Linux 10.0 and it will be in SUSE Linux 10.1. And App Armor is now open source. That happened in January. So you go to opensuse.org slash app armor is the home page for the project. Open SUSE is an open source project for building productive useful distros. And so the app armor stuff that's on open SUSE tends to be the stable releases of App Armor. Follow the links from there over to Novell Forge and you find the development releases of App Armor where we encourage people to come help us develop this, add new features and do stuff. So on this open SUSE page, you find binary packages, source packages and the mailing lists. If you just wanna put it in production, get the announced mailing list. And if you wanna help develop the dev list, you're familiar with this routine. Stuff we need. Application profiles is the most important thing. App Armor is very easy to use to build profiles for applications but only if you know how to use the application. And as I saw in some presentation this morning, there's like seven packages in a typical distro and we certainly don't know how to use all of them. So if you have an application that you wish was more secure and you like to use it, please come help us generate a profile for it. Go get the free App Armor, put it around your application and build a profile for it and send it back to the mailing list, please. Distribution porting. We want App Armor to be ported onto other distros. It's nice that it's an advantage for SUSE but it's also nice if other people, if the open source community enriches App Armor. So there's a port to Slackware underway. I'm not sure how complete that is. I've been talking to the Hardened Ubuntu project. They seem very interested in our building packages and I'm explicitly interested in porters. I don't have any yet for Debian, Gen2, and Fedora. If you wanna port App Armor to those platforms, please see me after the talk. Near term stuff coming with SUSE Linux 10.1. There will be a tunable file for setting local configuration things. You're gonna add variables so that instead of having to write slash home on your policy, you'd be able to write at home so that that can expand to a bunch of strings for wherever you NFS mounted your home dears. There will be booleans so that you can set a variable or a boolean value to turn on or off features that you may or may not want in your users. Longer term, we wanna add network access controls. The goal is to have syntax similar to IP table so that you can specify all the usual firewall things but per application. And the issue there, why we've been working on it forever and haven't done it is that there's kernel semantics issues that make it hard to get it right, especially for inbound packets because you have an inbound packet coming in. It's in an interrupt context where the packet was just shoved into the kernel and it's about to be delivered to a process but you're not sure which one. So that makes it rather challenging to decide what policy to apply. Deny profiles. App Armor uses the whitelist approach that I was advocating so firmly. We're gonna add a blacklist so that you can have a combination where you can say, well, yes, we allow everything in slash var, dub, dub, dub, htdocs, star, star. Oh, but not key files, so you write another rule that says that stuff but no key files if you wanted to keep your key secret for some reason. You had them in the web docs tree. A default profile. App Armor uses a blacklist approach for which programs should be profiled only the ones you said and everything else runs unconfined and that is good for configuring the network threat model that I described earlier where you've confined every open network port that leads to an app armor policy and great now network attackers can't get you but what if you have local users and you don't trust them? So things like the default profile would allow you to set a policy that says, well, if I haven't bothered to set an app armor profile, this is what it can't do. So you could, for instance, easily write a default profile that says, well, nobody can access Etsy Shadow unless they are running inside a profile that says that they can. So that allows you to enhance security for particularly sensitive spots in your file system. We have a better static analyzer that's in the pipe. The static analyzer I mentioned before is really just LDD. It figures out what libraries the program is gonna access. The new one does full decompilation on x86 executables, fishes out the open system calls and then tries to backtrace from there what the argument to open was and if it's a static string, we'll put that in your profile. Smarter learning mode, right now the learning mode isn't very bright, it just logs everything and that creates some bandwidth issues for syslog and we're gonna put some more logic into the kernel module so that it will go, oh, no, I've already mentioned that, so I won't, and that will reduce a lot, the bandwidth going into syslog. Smarter data structures. Some of this kernel code has pretty linear data structures that aren't the fastest and so app armor performance is great until you have 10,000 profiles. I've never seen a sane reason to have 10,000 profiles, but we did it anyway just to see what it did. So there's some work to be done here. If you're like a senior computer science student and the professors have just been teaching all about keen log structure, data structures and hash tables and things, then there's some work here to do. And that is the presentation. I am the architect, I'm Crispinette Novell. These are sales guys, Clive and Frank. Frank is the product manager, Clive's the marketing guy and this is the commercial product homepage, novell.com slash app armor. The open source one is opensusai.org slash app armor and we have about 10 minutes left and I'd like to take questions. Yes, sir. Yes, there is. Well, your own and someone else's suggests that there's some identity going on and really they're all being served by the user ID, HTTPD, right? So the notion that this is mine and that is yours on a virtual domain server doesn't exist. What you could do is app armor reacts to the path name that was being executed. So if you had a dedicated Apache process or program dedicated to each virtual website, so it wasn't called Apache, it was called apachebob.com or apachevoo. No, you can't really do that. No? It doesn't really scale very well. Okay, well then I guess you can't. But that's the approach that app armor uses is if you create a hard link to a program then you can apply a different policy to that same program. Yes, sir. The question is can you put an armor around a shell script or a pearl script and yes you can. App armor knows when it sees a file that has hash bang, whatever your favorite scripting language is at the top of the file, it puts the profile around the script and not the interpreter. So just out of the box, generating profiles for bash scripts and pro scripts is automatic. If by some mistake you happen to try and create a profile for bash, that would be very uncomfortable because then you couldn't use your machine anymore. So app armor will actually stop you and say no, no, no, you shouldn't be creating profiles for bash, that's bad. On the other hand, you can use the hard link approach I was mentioning in answer to his question. So if you wanted to have say a role for a log analyst and log analysts is like junior sysadmin, you just hired him, he's an intern. And you trust him enough to be doing the log analysis but you don't want him to be resetting the Oracle database because that really annoys the CEO. So you create a hard link from log analysts to bash and then you make skippy's default login shell be log bash and then you create an app armor profile for log bash that says oh, can run, you know, rep on var log messages but can't run shutdown or mess with Oracle. And so you can give someone fully root privilege. Oh yes, and you have to make his UID zero. So you can give someone full root privilege and yet have a restricted shell that confines them as tight as you wanna be to what they can do. The policy controls whether they're allowed to do that. And in fact, it even lets you allow them to execute bash but it's still running under the log bash profile. So yeah, you can execute whatever shell you want as long as we said you could but you still can't mess with Oracle. Yes sir. That's what it does now. It has to pass user mode policies and the app armor policies. We are contemplating adding user oriented security so that a different policy would apply if some user was running the application. I'm very cautious about adding language features because a lot of the power of app armor is its simplicity. It's fast and easy to generate these profiles because the language is so simple. And so whenever we add a feature, I'm very, very careful to make sure that we preserve the property that the profiles are understandable and they're easy to generate. The question is can a user create a policy for their own application? If I think I understand what you're referring to, there might be a policy for game that is system wide and a user might think that the policy is too loose and want to have a tighter one. So that's a feature that we're thinking about adding. I'm not sure how well motivated it is because I don't know very many multi-user systems that someone runs game on. This is my laptop and my wife might have an account on it but she doesn't really use it. That's an interesting application. I think it could be done without adding new features especially if it's the case that it is your computer and you have root on it anyway that you could set up a special account that using the log bash hack is capable of compiling software but only in restricted trees. Yes, sir. The question is is there a logging mode where the log records are generated for access is what even when they're allowed. And I actually can't remember whether that's in the product or will be in the product. But it tends to be very noisy. Logging at that level produces a lot of bandwidth. You may like it, you may want it but I'm not sure you'll like it. Yes, sir. The question is I want to be able to log whenever someone accesses a certain file and that is a feature of the default profile that we would add. If we add the logging feature and the default profile feature you put them together then you can write a rule that says yes, log it every time somebody reads Etsy shadow. Yes, sir. Oh, sorry. Down here. The question is about shared memory. We do not have any access controls on shared memory. I tend to disbelieve that this is a useful construct because programs that share memory really are the same application. They just have multiple processes and trying to write a reasonable policy that expresses what memory you can share and what memory you can't. I don't know how to do that such that it's this clean. So I'm happy you're just having a policy wrapped around those programs. Oh, resources. We thought about adding abstractions for U-limits to app armor policies. We haven't done it yet, again for the simplicity argument and when we went to look at it it turns out that U-limits actually works. It's relatively obscure because people mostly don't care but Linux has a feature for that. Very patient gentleman in the back. The question was about an append-only access mode. No, we don't have that and yes, we want it. If you'd like to come implement it, that would be terrific. The question is about app armor's reliance on path names. And app armor, let's see. Linux resolves sim links before they get to app armor. But hard links are after app armor. So that allows you this nice hack where you can have different policies for different programs of different names just because they're hard linked. Other namespace schemes like plan nine style namespaces basically are competitive with app armor. The plan nine namespace notion is another way of achieving a lot of this value. And exactly how to resolve all that I'm not sure. I've not really seen very much use of elaborate namespaces in the Linux space. If it happens, we'll have to deal with it. The, oh, there we go. No, I didn't run the change hat demo. The way it works is the change hat API, there's two levels to understand. One is the API and the other is the Apache module. The API says that there are two security levels. There's the outer profile and then there are hats. So you can only change to hats that were defined for your profile. And when you change into a hat, you provide a token, a secret key. And you don't actually share it with anybody because you just have to match it on your way back out of that hat. So you can just get it, read it from dev random if you want to. And then to come back out, you have to match that secret key. And if you don't, we kill the process because there's no sane reason to have the wrong key. There's a special case that if you provide a secret key of zero, then there's no way out. So that gives you a one-way transition into a policy. The Apache module basically takes the URI request, the essentially the URL of what you're asking for, and goes and looks for a hat of that name. This is specific to Apache, yes. Other programs need to have a similar kind of module, yes. And we have a such number, PAM, that does essentially role-based access control so that you can have a per-user policy that your shell gets different permissions from his shell. Is that it? Thank you very much.