SELinux Instructions
max
maximilianbianco at gmail.com
Tue Jun 9 21:24:01 UTC 2009
On Sat, Jun 06, 2009 at 12:03:35PM -0700, Peter Joseph wrote:
>
> For the past several weeks I have been trying to learn SELinux, and as so
> many before me, I find it extremely frustrating, ready to give up. Can
> someone tell me where to start? It looks to me that all of the stuff
> written about SELinux was written by Microsoft people in order to keep
> people from using Linux. Take for example the 'cat' command relating to
> /etc/pam.d/gdm - what in the world am I to get from this:
> #%PAM-1.0
> auth [success=done ignore=ignore default=bad] pam_selinux_permit.so
> auth required pam_succeed_if.so user != root quiet
> auth required pam_env.so
> auth substack system-auth
> auth optional pam_gnome_keyring.so
> account required pam_nologin.so
> account include system-auth
> password include system-auth
> session required pam_selinux.so close
> session required pam_loginuid.so
> session optional pam_console.so
> session required pam_selinux.so open
> session optional pam_keyinit.so force revoke
> session required pam_namespace.so
> session optional pam_gnome_keyring.so auto_start
> session include system-auth
> Where can I find information explaining the above? Is there a place where
> one could find some sort of a basic template file? A file showing the
> minimum initial settings that could be built upon?
> It seems to me that inclusion of SELinux in Fedora is counterproductive.
> Instead of providing users with a firewall they could manage after
> negotiating a reasonable learning curve, the users are presented with this
> monstrous security system understood only by full-blown programmers. Is
> there a way of learning SELinux without the computer science degree
> prerequisit?
>
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 at 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 at vertex ~]$ chmod 700 *
chmod: changing permissions of `selinuxpp': Operation not permitted
[m at 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 at vertex ~]$ cd selinuxpp
[m at vertex selinuxpp]$ pwd
/home/m/selinuxpp
[m at 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 at 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 at 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 at vertex ~]$ cp selinuxpp selinuxpp_z
cp: omitting directory `selinuxpp'
Duh!! Which way did he go George?
[m at 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 at 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 at 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 at vertex ~]$ pwd
/home/m
[m at 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_gci1323731,00.html
More information about the fedora-selinux-list
mailing list