 All right, as you guys know, I was totally not ready to give this talk today. You saw me running make to actually prepare my slides out here on the podium. I miscounted. I am going to talk about the current state of SELINX as released in H. I'm going to talk about the different SELINX policies that there are. And I was going to stop there, but we released H in better shape than I had hoped for when I first gave this abstract for the talk. And there's very little for me to say here. So I'm going to change the scope of the talk and talk about what we ought to be doing for Leni and beyond. Okay, let's see if I've got this thing compiled right, in which case. We shipped H with SELINX installed by default in the base, but not enabled. So if somebody wanted to take a base H machine and convert it into a force thing mode SELINX box, it is very easy to do so. In fact, Russell Coker gave a talk about SELINX on edge in five minutes or less, and he demonstrated on the podium how easy it was to do so. I am not daring enough to try that. There is a wiki page, and somewhere in the next few slides, I think, I've got the URL. It's wiki.win.org slash SELINX setup, which leads you through the steps required to turn on SELINX H installed. Okay, before I go on, I don't think this is the way it is supposed to work. Okay, so the first thing that I'm going to talk about is what are the types of SELINX policies? In the beginning, they were just the example policy. This is what the NSA supplied us. It was supposed to be just an example that the rest of us were supposed to modify and enhance and bring to the distributions. But as is usual in the case of free software projects, everybody just kind of fed back patches and nobody took up the task of forking the SELINX policy and taking it away from the NSA. The policy, however, was strict in the sense that NSA shipped a stuff that said everything is denied by default. You don't provide a policy. The machine doesn't even boot up because in it is not authorized to do the kinds of things that in it tries to do when you invoke it. Red Hat when they tried to ship SELINX found that their customers, the most frequently asked question to date for Fedora is how does one turn off SELINX? So they started off and said that okay, we are going to have a policy that doesn't try to control everything but only controls targeted servers. What are the most vulnerable points on any machine? It's the software that faces the internet. Any software that faces the internet or has to get input from untrusted users in order to operate. So they said that okay, we will constrain those targeted servers and let everything else go free. So we got targeted policy. The NSA was not very happy with this because everything was still based on the example policy and they have better things to do than to participate in the flame wars that are part and parcel of any free software project. Hey, just look at us or look at policy or private in the last few months and you'll know what I mean. So the next thing that came up was and what we are working on now is reference policy. This again comes in the strict and targeted flavors, but it is totally different from the NSA policy and it was designed to be the testing grounds of innovation and changes in which security policies implemented. The first thing that people did for reference policy was make it modular. Think of it like as a Linux policy somewhat like the Linux kernel. There is a core set of operations that you need to control and then there are optional modules that you may or may not want to plug in depending on what your machine does. The reason you don't want to have one giant policy that you load all the time is well, first of all, it's not that flexible. It's not easy to replace parts of policy with something you have written locally. And secondly, it takes up a lot of kernel memory. I mean, the SELinux policy essentially creates a bunch of two-dimensional tables and the more instructions that, the more rules you have in the policy, the larger the size of in-memory kernel tables. And well, now that we've got modular policy, more or less where we want it to be as far as features that is concerned. It's not complete in coverage. They basically, I think, we only cover well the packages that you get with Red Hat Enterprise Linux, which is a far cry short of the 10,000 or so source packages that we ship now. I haven't been keeping up. It was 9,000 or so about a year ago. Anyone know what it is now? The source packages that we have in Lening? Hey, come on, guys. There should just be one quick Google or app cache search. Well, while we are waiting for people to come up with the answer, if you have two different policies and only one of which is being used, inevitably there's going to be drift. So the policy that is used less, the strict policy, is liable to fall into disrepair. And actually, that is the policy that we want to push in the long term. I'm not going to go into this talk why we should be running strict policy. I talked about it last year and I'll be happy to convince anybody who dares come up with me at offline about why this shouldn't be running a wide open machine. Why is there so little audience participation right now? Oh, I forgot. Lunch. Ah, yes. We don't want the policies to diverge. So what the current move is to create one policy, which will effectively be the strict policy, and create one loadable module called unconstrained, which goes back and changes the strict policy into targeted policy. So anybody who feels like running just the targeted policy requires to load one extra module and conversely just unload that module to go back to running strict. Given that, I would like to move us in learning closer to being able to go to a salient by default. So what is it that constrains users who want to run a salient next? There are a few prerequisites. RazorFS, for example, doesn't fully support atomic rights of attributes, which means we cannot run a salient next on a machine that's using RazorFS because we can't label the objects on the file system. Nobody that runs a salient next that I know about runs XM as well. Me, I still run Sendmail. I learned Sendmail.cf back in the 80s. I spent a lot of blood, sweat, and tears learning Sendmail.cf. I'm not going to give it up anytime soon. Hey, I still know 8086 assembly. None of the new fangled ones yet. So if you want to use XM, you would either have to find somebody who knows SELinux policies and writes one for you, or you need to figure it out yourself, or go post-fix. Limont is out here in the audience. I'm sure he'll be happy to help any site transition to post-fix. So I mentioned that there are some tweaks that are required to enable SELinux. And those fall into three major segments. One is authentication. Sure, SELinux is available and installed and ready to go, but it's still got to tell things like login and SSH and XDM and WDM and so on, that when somebody logs in a new session is started, that session gets the proper security ID that will be used by SELinux from that point on. The way SELinux policies are constructed is like there is a subject, which is usually a process, and gets a security domain based on who the person is, who is logged in, or in special targeted cases like Apache. Apache always starts running in the Apache security domain. And then there is an object, which is usually some kind of structure like a file directly socket. And then there are actions that you can do. Subject can do stuff to object. In order for the subject to be properly classified, you need to tell it who you are when you're logged in. There are a bunch of cron jobs that do things that are not exactly security conscious. For example, we back up shadow and gshadow, which means cron needs to be able to read and write shadow files, which is not really what I want to do. So we can handle this by putting the backup job in its own security domain and giving the read security files, shadow files, capability only to that one executable. Nobody has done that yet, so the advice is to just not back it up or back it up manually or live dangerously and not worry about shadow files. There is also locate, which runs fine all over the fine file system, which means the locate binary needs to be able to read every single file on your system, which gives security people the nightmares. Again, that is a suggestive to disable that. There are other miscellaneous things like slash ETC, MOTD is regenerated at boot up. I guess we could write a special binary and security policy to allow you to do that. Frankly, I don't really have that much new going on every time I boot up, so I just replace it with a static file, which can be labeled. Devs.static is a nightmare again because nobody has written policy for it and you need to recreate everything for slash dev in there. Then there are also, I'm sorry, I'm getting lots of mail while static PTYs. If your PTY remains persistently, it changes ownership, so it has to be labeled every time it does so, which is a pain, and Debian has supported dynamic PTY since Lord knows when. So your advice to remove all the static PTYs so the system doesn't use it by mistake. The URL at the bottom is a pointer to a shell script that uses a dev bootstrap to create a local file system for you and makes all the changes that are mentioned on the Wiki page. So if you just wanted to create a new file system for a new Zen or UML virtual machine or for a Chirrut jail running a Selenax, you can just use that script and all the five minutes of TDM hacking around configuration files using VI. This is, once you've made those changes, I'm not going to re-throw all of this. This is on the Wiki. This is the sequence of steps you need to do to get Selenax running. After installing the packages, you re-label your file system so it has the proper security labels. You edit grub.conf. I just added an other option so I have, for every kernel I install, I have three lines in grub. One is the normal, one is recovery, and the third is the Selenax option that allows me to boot in Selenax mode. Re-labeling is one of the most expensive parts, and this is what takes up most of your five minutes trying to get Selenax running. Are there any questions or should I just gallop through this so that we can get out to lunch as fast as we can? Okay. All this that we have been doing has been targeted policy because it was too difficult, still it's too difficult to get things running in strict policy because, really, apart from a few Selenax developers, I don't think anybody anywhere ever runs strict policy so far. Even the red hat stuff is just targeted. The good news is, after you make a few mods about Cron trying to back up shadow and stuff which will be disallowed even by targeted policy, target with policy essentially runs out the box with Edge. There have been lots of reports about people running servers on Edge with targeted policy in forcing mode and I really see no reason why anybody should be running any server and not run at least the targeted policy. It doesn't cost you... It might cost you 2% to 3% slowdown as compared to something which is not running Selenax but the kind of security, the kind of... The ability to sleep at night is probably what the 3% hit. If you are really that close to your performance requirements, I strongly suggest you update the hardware because by now every six months you get more than what a Selenax hit is going to be. Okay, so if you want to run strict policy you should run with auditing turn on. Recently some kind of soul packaged and uploaded the audit package into SID which saved me the trouble of having to go out and package it and I've been meaning to do so for a couple of years now. And then the minute we start running strict policy you boot up, you'll get a gazillion error messages and essentially you just run something called audit to allow which grabs all the error messages that you have been getting and spits out a local module, a policy module that you can load into your running policy. It's usually a good idea to take a look at what it has spit out because some of those things that allow you really don't want to allow in that case you just tell it that don't allow it but stop yelling at me about why you are not allowing it. So just silently drop this request. And this is all it takes. There are essentially four command line commands that you have to run to take any Selenax system run it on strict policy, grab all the error messages that has generated and make them go away one way or the other. So at this point I think I'm done with the original premise for the talk. So how much time do I have left? I'm sorry my eyes aren't what they used to be. Oh my, I've got lots of time. Okay, so future plans. What do we need to do to support stable? I have acquired a login on the back port service machine and I intend to back port the current tool chain for Selenax and the reference policies back to edge. And I also am committing to do all the security updates as required for the Selenax packages. I'm hoping that I will inspire loads and loads of you to immediately jump out and go and grab a Selenax and start running it but I can see about five people in the audience who are fast asleep so maybe I'm not getting the message across as well as I thought I would. We do need help with people running the strict policy even if they don't run it in enforcing mode if you send me back the errors for your configuration I'll be able to create policy patches that will make a Selenax strict work on your machines. So as long as people tell me send me all the AVC denied messages out of war log messages or wherever I promise to put in the work to make a Selenax work on your box. Is that incentive or what? Now this is where I am going to run into a bit of pushback probably from the installer and the release teams. I'm trying to make it a personal release goal a personal release goal to have a Selenax better integrated into learning to make it possible for somebody to start from the get go tell the installer that I want a Selenax box and have it happen. As I said the most expensive part of getting a Selenax run on your box is really labeling the entire file system so that every single file has the proper security labels. The reason is that right now the installer does not label your file system as it is being installed. So you have got to go through that expensive step. If however we can make minute changes to the installer without compromising the ability to install Debian on any machine then it would be far easier to just have people optionally start off the Selenax machine in either targeted or sick policy in enforcing mode. What do we need to do for that? First of all from the Selenax side we need to be able to update a machine's security policy somewhat similar to how we already update the software packages. Something which is aware of the mapping between Debian package names and a Selenax policy module name. Something which is aware of not only the software package dependencies but also about policy dependencies. For the most part you don't have to worry about it because the policy dependencies more or less follow the package dependencies but there are a couple of exceptions and we need to make sure that when you say update my Selenax policy it should be able to look at the packages you installed figure out what policy modules you need in order to have those packages actually work figure out what the dependent policy modules are and then go out and load those policy modules into your running policy. We currently do this only during the post-inst of the Selenax policies. Next we need to have the policy for a particular package say Apache. You want to have the policy for Apache loaded before you tell the package to install the package because when the package is being unpacked the system needs to know what the security label, the initial security label of that file has to be. Ian Jackson has created a whole bunch of triggers for the package. He specifically left out the pre-inst trigger which is exactly what you would need for this to happen. So I guess one of the things that has to be done is after Ian's trigger code gets into the package somebody has to go in and hack the package to add the pre-inst trigger if for nothing else for the security policy to do. Yes. A pre-inst trigger in the way that Manoj is suggesting is fundamentally incompatible with the point of triggers which is to delay processing. So I think maybe Manoj and I should talk about this outside the session. Right. Technically and conceptually there is no reason why we can't have pre-inst triggers. Yes, there is. All right, maybe we should take this off but it might be incompatible with the way that the triggers have currently been coded so maybe I should call it something else. All I need is the deep package consult a list of something or the other that says that before this package is loaded you've got to run that one particular load policy for the package command. And the reason I say that this is not impossible is because I do have a hack deep package that does that for me. So faced with a running example of a deep package it's kind of hard for me to stomach the claim that what I'm doing is not possible to do. My way is hackish. I would like to improve the way it is done but there shouldn't be any technical obstacles to this. One of the reasons to do this is right now all SLNX policy is one package even though we don't install all the policy modules into the running kernel we don't load all the modules we do ship them along with the reference policy package and I think this is the way it should be at this point because both SLNX and the reference policy are rapidly moving. For example we have just included the ability to label network nodes and to have end-to-end security so not only can you say that I want my application to only talk to clients coming from such and such a security domain so I can say that my server on this machine should only talk to clients coming from nodes that have been labelled or company confidential high nodes that means they are not... I'm not talking to the internet and on those nodes I should only be talking to a process that is in the accounting domain so you then set up your company so that your finance service oriented architecture is only accessible for people in the accounting department running on their official machines and from nowhere else. These kind of changes coming so fast and furious it is not reasonable to expect every maintainer out there to keep track of what the policy syntax du jour is so it still makes sense to have one common policy package but post-LENI I'm hoping that SLNX would stabilize to the point where all these well everybody would be running SLNX by then of course you would be shipping SLNX by default post-LENI and therefore it would be reasonable I see France giving me the dirty look and it would be reasonable to ship policy off to the maintainers themselves too so you have a new... you change the behaviour of the package you modify the SLNX policy that ships with it and somehow we manage to get deep packets to install the policy before the package is installed hey I've got three years to think about that I'm sure I'll come up with something next I would like to have the WN installer label the base file system so this isn't really very expensive but you should be able to do this without compromising the rest of the WN installer and it would save a lot of effort on the part of people trying to run a SLNX system along with that if you can add an optional question early in the install process asking... I'm hoping before task cell asking whether you want a SLNX machine or not and based on that you load the policy before you load any other packages we ship the policy anyway if the file system is labeled loading the SLNX reference policy will be fast and finally we modify the grub configuration file to add a SLNX option like I showed in a few slides back and I think I'm ready and waiting for the audience participation now nobody wants to talk about it could you grab the mic please you said yourself that in Fedora most of the desktop users switch SLNX off because they have also lots of problems do you think it makes sense for Debian to enable it also for desktop computers or only for servers? Do you think the targeted policy is suitable for a desktop? They are Fedora, we are Debian we do things better and yes? I mean the problem is if the users the not so knowledgeable users have all sorts of subtle problems that don't know where they come from most people will trim it off Debian should never ship in a form that ordinary users have problems running the released software so no I don't think we are going to be shipping Debian in a form that users have to ask how to shut SLNX off again I said we are not Fedora so you think it can be made fool I absolutely think it is feasible to run a targeted policy on a desktop system we are not there yet but Lenny is two years off and if I can get enough of you guys to help me with just sending me what doesn't work on your desktop machine it doesn't take much to fix the policy so things don't blow up in your face I think we can do it So I have rather a dissenting view as Manoj already knows and probably now there isn't really there is enough time to go into this but I've worked in the computer security field for probably a couple of decades now and I'm very much unconvinced that SLNX is the proper solution to any real security problem the main difficulty with it as has been demonstrated by Manoj's presentation is that it is extremely complex and complexity is pretty much always the enemy of security and the effort that we're putting into making SLNX work properly and not break might very well be better spent in some other way almost any other way so I just wanted to make that point I'm sure Manoj and I can discuss this in the bar later I would like to remind people that way back when even before my time back in the 1920s electric motors were up front and in your face there were all kinds of there were torque equations there was number of coils and you took a squirrel cage motor and you had four or five knobs you tweaked in order to get your electric motor running at the optimal torque load levels now you turn on the microwave there are three electric motors in there and you don't even know how many there are or how they work until now running SLNX has been like tweaking the five or six knobs in order to get the motor going right what I'm looking for is in the next two years we take the electric motor from a squirrel cage motor with six knobs to that motor in the back of your SLNX of your Debian box and you never even think about until it tells you that somebody tried to hack into your system and it was prevented I didn't mean to shut off the conversation I think I can probably speak for a lot of us we're pretty ignorant about SLNX we hear these terms policy and we don't know exactly what it means when you say a policy on a file does that mean an executable file and the policy says that it can do what? okay firstly I think I've got two minutes left and there are people who are hungry I don't think I can go into this right now secondly I'm out of time secondly is there any talk after this? I think we're breaking for lunch so even though the video feed might be shut off I'm willing to stand around for questions the next thing is I gave a little talk on SLNX and tried to cover what SLNX is and the policies and what it does I'll be happy to regurgitate this over lunch or well that's probably not a good choice of words I am here through the week so just grab me anytime and maybe we can grab an empty box time frame and I'll be happy to talk about SLNX what it means how much effort it would be for the Joe's sys admin to run on their machine Steve? yeah my question was you mentioned that you wanted to have the SLNX policy installed prior to doing any of the package configuration and I was wondering why that's a speed advantage in terms of why it's preferable to do that before the package is there a speed advantage to doing that before the packages are installed or is it a security issue where you want to make sure your full installation is done under the SLNX context? there's a security issue and that has to do with labeling the file system the reason we need to label the file system as I said there is a subject that does stuff to object what the subject is the security domain of the subject depends on two things either the person who is running the process or the security label attached to the process for example if you run an HTTP server we don't want it to be running under the security domain of the sys admin we want it to be running at the HTTP server domain in order to apply the security domain to user bin Apache 2 deep package has to know that user bin Apache 2 needs to get a security label that says it is an HTTP domain that is there mentioned there in the Apache policy module deep package knows already how to read the policy in order to label the files correctly as it is being unpacked but if it is a policy that is not in the running policy deep package won't know how to label it so that's why we want to have the policy installed before we unpack we could even I could hack around this by having a run say in aptitude or whatever the front end is you look at the packages that are going to be installed you run this one script giving it all the package name that is going to be installed it will do the policy load even before deep package starts loading anything which is one way of implementing my PLEANS trigger which doesn't even touch deep package code so there is a amazing amount of really interesting things that package post install scripts in particular and package maintainer scripts in general do and well the answer to most of that to like 80% of that is well don't do that a lot of it is there for weird reasons and that my understanding is that's posed a bit of an issue for figuring out how to write policies for letting packages get installed because the post in proceeds to go off and do various things that the policy may not expect it to be even looking at I know it's a very vague question but I've heard that as a rumor floating around so maybe you can either debunk that or address that alright two things firstly when you're installing packages we are running in our own security domain we are running in apt underscore T or deep package underscore T domains so the kinds of things that these domains already do is extensive so if somebody has managed to corrupt or replace your aptitude or deep package by a Trojan you are in a boatload of trouble anyway I think that so far I haven't encountered anything which is fundamentally unsurmountable there are some packages which do stuff for which I have to write more security policy but if these are things that we decide the package needs to do the security policy is what needs to be changed not the package itself if we find that this is stuff that the package shouldn't be doing whether or not you're running a C Linux then that's the security hole and which is presumably a release critical bug so I don't think that a C Linux introduces anything new or different in that domain I hope nobody is susceptible to epilepsy in here anything else alright I guess we break for food