Matej Cepl wrote: And what I really recommend you is also Dan Walsh's LiveJournal about SELinux. There is a lot of useful information that can help you with understanding of SELinux. Look at http://danwalsh.livejournal.com/

On Sat, Jun 06, 2009 at 12:03:35PM -0700, Peter Joseph wrote: I do not have a computer science degree. Here it is as I understand it. I oversimplify where I can, its a big subject that requires knowing the internals of the kernel, if you really want to get down to the nitty gritty, all I can say is I am wrestling the bear, but do you really expect me to kick the crap out of an animal that outweighs me ten times over by myself? So it is nice to know that I am not the only one getting his ass kicked. Perhaps a coalition of the novices, with truncheons can prod the brains to spill their guts ;^) I hope this can get you headed in the right direction. I am of course happy to accept correction. I have made it only as brief as neccesity dictates. So since I don't know what you know I am going to assume less rather than more. SELinux is all about file labels. Basically the policy defines what label is allowed to access which other label and how it is allowed to access it i.e. read,append,write and on and on. Its a bit different from DAC(Discretionary Access Controls) but not much really, its really just a natural extension of DAC, or subdivision of DAC really. With regular DAC you have basically three permissions. I don't know how many SELinux has but its a lot more than three. So in DAC you have read, write, and execute bits. When you pull a directory listing you are shown the permissions that the owner, the group, and everyone_else has plus a label(from left to right). [m@vertex ~]$ ls -Z drwxr-xr-x m m unconfined_u:object_r:user_home_t:s0 Desktop drwxr-xr-x m m unconfined_u:object_r:user_home_t:s0 Documents drwxr-x--- m m unconfined_u:object_r:user_home_t:s0 Download drwxr-xr-x m m unconfined_u:object_r:user_home_t:s0 git drwxrwxr-x m m unconfined_u:object_r:user_home_t:s0 mail drwxrwxr-x m m unconfined_u:object_r:user_home_t:s0 Meshes drwxr-xr-x m m unconfined_u:object_r:user_home_t:s0 modules drwxr-xr-x m m unconfined_u:object_r:user_home_t:s0 Music drwxr-xr-x m m unconfined_u:object_r:user_home_t:s0 Pictures drwxrwxr-x m m unconfined_u:object_r:user_home_t:s0 Scripts drwxr-xr-x m m unconfined_u:object_r:user_home_t:s0 selinux drwxrwxr-x root root unconfined_u:object_r:user_home_t:s0 selinuxpp drwxr-xr-x m m unconfined_u:object_r:user_home_t:s0 Videos drwxr-xr-x m m unconfined_u:object_r:user_home_t:s0 Warped Contrails Ok so it shows they are all directories then the permissions of the respective owner, group, everyone_else. Then user and group and then SELinux info followed by the file name. DAC bits do not allow the granularity that SELinux labels do but it comes at the cost of complexity. Since the Linux kernel is both powerful and complex and any GNU/Linux distro is a melding of often disparate pieces, it, the SELinux policy, can become complex indeed. The complexity is born of neccesity. [m@vertex ~]$ chmod 700 * chmod: changing permissions of `selinuxpp': Operation not permitted [m@vertex ~]$ ls -Z drwx------ m m unconfined_u:object_r:user_home_t:s0 Desktop drwx------ m m unconfined_u:object_r:user_home_t:s0 Documents drwx------ m m unconfined_u:object_r:user_home_t:s0 Download drwx------ m m unconfined_u:object_r:user_home_t:s0 git drwx------ m m unconfined_u:object_r:user_home_t:s0 mail drwx------ m m unconfined_u:object_r:user_home_t:s0 Meshes drwx------ m m unconfined_u:object_r:user_home_t:s0 modules drwx------ m m unconfined_u:object_r:user_home_t:s0 Music drwx------ m m unconfined_u:object_r:user_home_t:s0 Pictures drwx------ m m unconfined_u:object_r:user_home_t:s0 Scripts drwx------ m m unconfined_u:object_r:user_home_t:s0 selinux drwxrwxr-x root root unconfined_u:object_r:user_home_t:s0 selinuxpp drwx------ m m unconfined_u:object_r:user_home_t:s0 Videos drwx------ m m unconfined_u:object_r:user_home_t:s0 Warped Contrails I am not root and not in roots group and/or I do not have the write permission so I cannot change the properties of the directory selinuxpp, that is simple DAC. However I have the read and execute bits so I can read all the files contained in it. [m@vertex ~]$ cd selinuxpp [m@vertex selinuxpp]$ pwd /home/m/selinuxpp [m@vertex selinuxpp]$ ls -Z -rw-rw-r-- root root unconfined_u:object_r:user_home_t:s0 nbs.fc -rw-rw-r-- root root unconfined_u:object_r:user_home_t:s0 nbs.if -rw-r--r-- root root unconfined_u:object_r:user_home_t:s0 nbs.pp -rwxr-x--- root root unconfined_u:object_r:user_home_t:s0 nbs.sh -rw-rw-r-- root root unconfined_u:object_r:user_home_t:s0 nbs.te drwxr-xr-x root root unconfined_u:object_r:user_home_t:s0 tmp I can get the attributes of the files as above and read them as below. [m@vertex selinuxpp]$ cat nbs.te policy_module(nbs,1.0.0) ######################################## # # Declarations # type nbs_t; type nbs_exec_t; application_domain(nbs_t, nbs_exec_t) role system_r types nbs_t; The policy was produced with the guitools and I never tested it so that is enough of that, maybe on some other day. It is enough that I can read a file I do not own, now the fun begins. [m@vertex ~]$ ls -Z drwx------ m m unconfined_u:object_r:user_home_t:s0 Desktop drwx------ m m unconfined_u:object_r:user_home_t:s0 Documents drwx------ m m unconfined_u:object_r:user_home_t:s0 Download drwx------ m m unconfined_u:object_r:user_home_t:s0 git drwx------ m m unconfined_u:object_r:user_home_t:s0 mail drwx------ m m unconfined_u:object_r:user_home_t:s0 Meshes drwx------ m m unconfined_u:object_r:user_home_t:s0 modules drwx------ m m unconfined_u:object_r:user_home_t:s0 Music drwx------ m m unconfined_u:object_r:user_home_t:s0 Pictures drwx------ m m unconfined_u:object_r:user_home_t:s0 Scripts drwx------ m m unconfined_u:object_r:user_home_t:s0 selinux drwxrwxr-x root root unconfined_u:object_r:user_home_t:s0 selinuxpp drwx------ m m unconfined_u:object_r:user_home_t:s0 Videos drwx------ m m unconfined_u:object_r:user_home_t:s0 Warped Contrails Take note that I can copy the directory. [m@vertex ~]$ cp selinuxpp selinuxpp_z cp: omitting directory `selinuxpp' Duh!! Which way did he go George? [m@vertex ~]$ cp -r selinuxpp selinuxpp_z `selinuxpp' -> `selinuxpp_z' `selinuxpp/nbs.sh' -> `selinuxpp_z/nbs.sh' cp: cannot open `selinuxpp/nbs.sh' for reading: Permission denied `selinuxpp/tmp' -> `selinuxpp_z/tmp' `selinuxpp/tmp/all_interfaces.conf' -> `selinuxpp_z/tmp/all_interfaces.conf' `selinuxpp/tmp/nbs.tmp' -> `selinuxpp_z/tmp/nbs.tmp' `selinuxpp/tmp/iferror.m4' -> `selinuxpp_z/tmp/iferror.m4' `selinuxpp/nbs.pp' -> `selinuxpp_z/nbs.pp' `selinuxpp/nbs.fc' -> `selinuxpp_z/nbs.fc' `selinuxpp/nbs.if' -> `selinuxpp_z/nbs.if' `selinuxpp/nbs.te' -> `selinuxpp_z/nbs.te' [m@vertex ~]$ ls -Z drwx------ m m unconfined_u:object_r:user_home_t:s0 Desktop drwx------ m m unconfined_u:object_r:user_home_t:s0 Documents drwx------ m m unconfined_u:object_r:user_home_t:s0 Download drwx------ m m unconfined_u:object_r:user_home_t:s0 git drwx------ m m unconfined_u:object_r:user_home_t:s0 mail drwx------ m m unconfined_u:object_r:user_home_t:s0 Meshes drwx------ m m unconfined_u:object_r:user_home_t:s0 modules drwx------ m m unconfined_u:object_r:user_home_t:s0 Music drwx------ m m unconfined_u:object_r:user_home_t:s0 Pictures drwx------ m m unconfined_u:object_r:user_home_t:s0 Scripts drwx------ m m unconfined_u:object_r:user_home_t:s0 selinux drwxrwxr-x root root unconfined_u:object_r:user_home_t:s0 selinuxpp drwxrwxr-x m m unconfined_u:object_r:user_home_t:s0 selinuxpp_z drwx------ m m unconfined_u:object_r:user_home_t:s0 Videos drwx------ m m unconfined_u:object_r:user_home_t:s0 Warped Contrails [m@vertex ~]$ ls -Z selinuxpp_z -rw-rw-r-- m m unconfined_u:object_r:user_home_t:s0 nbs.fc -rw-rw-r-- m m unconfined_u:object_r:user_home_t:s0 nbs.if -rw-r--r-- m m unconfined_u:object_r:user_home_t:s0 nbs.pp -rw-rw-r-- m m unconfined_u:object_r:user_home_t:s0 nbs.te drwxr-xr-x m m unconfined_u:object_r:user_home_t:s0 tmp [m@vertex ~]$ pwd /home/m [m@vertex ~]$ diff selinuxpp selinuxpp_z Only in selinuxpp: nbs.sh Common subdirectories: selinuxpp/tmp and selinuxpp_z/tmp Ok. well I did not get everything but even a partial copy could contain sensitive data. Here it hardly matters, much, unless I have a poorly written policy but depending on what gets compromised they may get all they need, because the type of one file has access to the other as defined in my policy. NBS stands for never before seen anamoly detector. It does not run as a daemon but for the sake of not going back to find another example let us pretend it does. It parses a log file and puts each entry into a database, keeping track of how many times it has seen a particular entry, so its easy to see never before seen stuff which might be of interest or maybe to find recurring patterns. Now i need to take care that my policy allows it to read log files but does not allow it to modify them in any way or a flaw in NBS could lead to someone being able to modify the logs, bottom line is we only want authorized files/persons reading log files, in all reality no one should be able to modify a log file. Well with SELinux this is easy (relatively) but with DAC much more difficult. If I can read the file then I can copy it, if I can write the file then I can erase or otherwise modify it. If this was a database of customer info then you can see what damage might be done by the unscrupulous. SELinux provides the mechanism for regulation of the system and its processes. To ensure that a program or process is only doing what it should be doing, if I exploit I flaw in apache then I can only affect the things that apache would normally need to run anyway. Caveat Emptor as they say, if what I am after is normally accessible by apache or whatever daemon I exploit then SELinux won't save me. SELinux is not a drop in replacement for all your security needs or considerations. Having said that, its been called the last line of defense but that only applies if the attack is from the outside, more often than not these days its a trojaned host that gets you. Each file has a user associated with it and then the permissions that user has are actually defined in policy. SELinux is default deny. It is very important that this be understood, simple as it sounds. There are no deny rules because the whole system is one big deny rule. You have to allow what you need and if you don't then its denied. Well, yeah not so easy a task when it has to be done for everything, consider all the different pieces of the typical distribution and all the calls they make, files they write, sockets opened, and on and on. So in DAC the permissions are defined read, write, execute. Assigned to the user, group, everyone_else. The key is too see the permissions inherent in each of the "three". Read, write, execute. Write is for instance a very broad premission. You could potentially erase the file completely if your not careful, but append is much more granular, so a service like apache can be allowed to append to its log file but never modify its previous contents. Note the SELinux label defines a user_u, a role_r, a type_t, and an MLS(Multi-Level-Security) field. Policy defines what other domains the unconfined_u is allowed to access, the object_r is a generic thing that you will see on almost every file, the type should be something intuitive. How is that determined? Well now we cross into the realm of the kernel. The SELinux policy is basically a mirror of the processes that could be going on in the kernel at any given moment. That is a big statement but I trust you'll take it with a grain of salt. If system security was a solved problem we'd be talking about something else. So each type is defined in policy and which other types it can access are explicitly defined in policy. Also which permissions for each other type to which access is allowed must be stated. The user_u is allowed access to certain domains, whose type is allowed access to domains x,y,z. So the _u, _r, _t are just conventions so we can distinguish them but basically to the kernel its all labels. The policy language is confusing at first but if you can start to see the permissions within the permissions then its useful indeed. The conventions are just there for you and me. Well its running long already, now what am I forgetting? http://www.nsa.gov/research/_files/selinux/papers/module-abs.shtml http://www.nsa.gov/research/selinux/docs.shtml http://docs.fedoraproject.org/selinux-user-guide/ http://danwalsh.livejournal.com/ http://securityblog.org/brindle/2007/05/28/secure-networking-with-selinux/ http://searchenterpriselinux.techtarget.com/news/article/0,289142,sid39_g...