 examples of attacks and how AC Linux can help mitigate some of the attacks. If you just hang around I'll just go through these slides it will take about 10 minutes and you have some flavor of what you can do with the AC Linux once you have it on your system. I'm going to use this the paradigm of patterns to go through the attack and defense mechanisms. A pattern is a general purpose solution, a general purpose example of how things can be done. It is not specific to any particular system or example so let's see I'm going the wrong way. All right phase one attacks let's let's look at the buffer overflow attack. The name of the exploit is buffer overflow. The goal is to inject malicious code on the stack or in a server application so that something running with privileges does stuff that you want to do. So the constraints on you are you've got to actually discover a buffer overflow in some kind whatever you're trying to exploit and then you've got to actually deliver the user input that will cause the buffer overflow. The solution steps are you know fairly straightforward. How do you protect against this? Well if you're an application writer you compile with certain things you make you as a sysadmin you can make the stack non executable you can have the no exact patch in the Linux kernel but you can also help out with security policy where you can contain a buffer overflow attack even if the stack is still executable and you haven't gone over to the no exact patch. What you do is you set private file types for your application. So you've got log files the files that application uses configuration files the executables are all put in a different security domain. By default nobody is allowed to execute your application. So and your application cannot access any of the rest of the system because now your application lives in a security domain by itself. Then you add in rules that allow your application to you know run and access its own log files right to its own log files. You don't allow it to modify the log files. You can say that your application can create a new log file it can append to a log file. It can only read from a configuration file. So you're limiting your application's access to its own files. You provide a macro and interface so that other people can be allowed to run your executable. If you don't do that then you're well there's no point in having this on the system because nobody will be able to run it. If you do this if your application is compromised nothing else can be affected because your application does not have any rights to access any other file on the system. It can read its configuration files but it can't write to them so it cannot even you know affect itself on the next time it runs. If it can only append to log files the hacker the person who's broken in cannot erase all logs of the intrusion and nobody else will be able to run your application unless you have given them explicit permissions. So if somebody some other application is compromised they won't be able to fire off your application and access the resources. Okay let me I think I've got that. Let me answer this and if I have missed something that you needed to ask I'll come back. The question being asked was what does it take does it only have to be done once for an application say take Apache what does it take to write a policy for Apache configuration files log files etc. Well the first thing you do is somebody who is writing policy you put Apache the executable in its own domain you try to run it in permissive mode and a Selenax will spit out all kinds of warnings that hey Apache try to access that config file you look at it if it feels right you write down that policy policy role. You can there are mechanisms in place which might help automate part of this look at what kind of error messages emitted apply heuristics there's a little bit of an AI kind of thing thrown in and outcomes a lookup Paul Jen apt get show Paul Jen P-O-L-G-E-N and no not Paul Jen P-O-L-G-E-N without the Y so and that gives you a hint of how you can get right Paul there is a guy a researcher at IBM who is doing static scanning of scores code goes and looks through this finds out where thing you might have security events occurring like writing to a log file and then puts in little hooks there where you can where it will check for policy and check to see whether people are authorized or not so if it all works out you just run that scanner against the source code it's emit something and you massage that into a security policy but once you have written it every upgrade it should not it has not in my experience I've written Apache security policy and new versions of Apache don't require changes most upstream right now are not really into a salinex because it's not deployed widely enough for them to be able to want to spend that kind of time so for the near term pushing policy upstream while it is desirable is not likely to be realistic however you don't really need that fine-grained knowledge about the internals of the application because you just let the application run see what they see the next doesn't like about it and then you can you have at least something to go on you still need to go and look and see if the application needs to be doing that but at least now you know what you should be looking for okay I wasn't aware that we were recording but I will listen now this is the next little thing I found this a really interesting exploit there are people who were this is actually a two-level exploit somebody found a vulnerability in internet information server they infected that and they set it up so that when internet explorer came to it it was given a JavaScript snippet to run the java snippet JavaScript snippet caused Internet Explorer to go to a and their website and download something from there and execute it the second website of course was the hackers website what was downloaded was a key logger and everything that was typed in into Internet Explorer from that point on was logged and sent over to the cracker this of course won't be possible if we are they were using a Selenix because a web browser wouldn't be able to run it downloaded key logger because it's not authorized to the deny by default helps us here the web browser would most likely not be able to even send data to a site like that because the information flow path would be prohibited the information is not coming from the users keyboard is coming from the key logger and going across that which is not permitted so the policy that we will create would to create is sandbox not just for the web server but for the web browser restrict access to local files for example my Firefox should not be able to read my GPG keys it should not be able to execute any random binary and outgoing network connection should only be possible say if the key they modify the key logger to send the data directly it shouldn't be allowed to talk to the network because outgoing network connection should also be restricted so what if instead of running a key logger the browser gets piggyback with an above all flow so it's the same binary talking back to the network a security policy can't protect you against everything so yes if the if there was a two-level exploit in which first they exploited the web server and then they came back and found exploit in the browser that you are using then anything that the browser has access to could be disclosed to unknown locations my tip for that is don't run internet explorer you can't do everything in a security policy it just makes harder to crack your box or the log file once it's a cracker is in one of the things that they need to do is erase all evidence that they were there especially if they want to keep control of your box over extended periods of time so this involves things like wiping out all audit fails and logs must be erased and traces of the eraser itself must be erased which generally means you look at etc syslog.conf and find out where the log files are and then you edit all the relevant files and then you edit U TMP W TMP last log to show erase all evidence that you ever logged in and then finally go in and you edit the shell history files to erase all evidence that you did this with a salinx what you do is every you set up a general this is a pattern that every application which has log files should follow this is kind of a best practices thing we need to protect the log files but we also need to allow backups to be made of the log files so every application provides the interface to read and delete log files in the security policy the application can create an append to the log file but the application itself cannot delete or change a log file log event that is already in the file so even if the application has been taken over you can't go back and say edit and refurbish the log files there's some application that can read the log file but they won't be able to write to it a special role a special user is required who can modify and delete log files if you've got if no application can ever be in that special domain where they're allowed to read and modify and delete log files then no automated attack can compromise the log files you need a human to come in take a role and run vi as themselves in order for log files to be changed log rotation is split up into two parts the first part is the last particular log file in a sequence is deleted then normal log rotate runs and now it finds that the last file is not there so say log dot six was deleted by the special application log dot five can now be moved to log dot six etc etc so log rotate can still continue to work as long as it runs after the log scrubbing utility there are examples of log scrubbing it's a simple script you just run it before log rotate it reads the files finds out which ones are going to be rotated and make sure that the oldest one is deleted or better you make sure that the oldest one is moved to a separate directory there that a and only deleted from that other directory say once a month if you're moving the last file you can you know put it in a new file in sub directory based on date so there are ways to allow you to do this and still allow log rotation to work complicated yes but then security is not easy which is I spent so much time trying to scare the living daylights out of all of you about how bad the situation is out there and it is bad any questions comments at the hack lab I can I can pull up a example I can write up a little a silly next policy for say module foo that and explain what I'm doing in that policy so that people can have a idea of what's a silly next policy writing feels like okay thank you guys for staying for this part