On Wednesday 07 December 2005 12:43, Revant Nandgaonkar wrote:
Can anyone give simpler explaination of working of SELinux, What is SELinux? It should be simpler than Official SELinux FAQ.
Revant.
I haven't read the official FAQ, but what I'll say here will serve as a minimalistic introduction to SELinux. For details of course, you should refer to other documentation.
We have the basic concept of permissions in Linux. We have the rwxrwxrwx permissions along with the setuid, setgid and sticky bit concepts. These are called minimal Access Control Lists (ACL). These are supported by all file systems. Now, some file systems like ext3 also support Extended ACLs. Refer this link for a nice introduction: http://www-uxsup.csx.cam.ac.uk/pub/doc/suse/suse9.3/suselinux-adminguide_en/...
Now, this kernel in-built ACL system (including minimal and extended ACLs) is called Mandatory Access Control (MAC). What SELinux basically provides is an extension to the MAC. This is called Discretionary Access Control (DAC).
The difference, one can say, between MAC and DAC is that MAC is always applied. Not so with DAC (Atleast not for every user and/or program. This depends on the policy. But I think the names 'mandatory' and 'discretionary' are clear enough). Basically, MAC defines which user and/or group can do what with a file on the filesystem. In the case of SELinux, we define what a program and/or a user can do for a file. This would be called sandboxing as we limit the program's access to various files.
So when SELinux is implemented, it relabels the entire file system according to the policy the administrator selects. Policy would be a database where SELinux keeps information for each and every file (this could vary according to which programs the policy applies to). For every program or user, that is covered by the SELinux policy, there's an entry in the database that describes what to do for a certain situation. The kernel makes decisions based on this policy (SELinux support has to be compiled in the kernel). A filesystem /selinux of the type selinuxfs is also mounted (Most probably, I've got those names wrong, but you get the point, I hope).
For any action (by a program or a user), MAC is first called. If the criterion is matched, the kernel then looks at DAC. The action is allowed only if DAC allows permission too.
For example, suppose apache wants to write a log entry in a file. First the MAC is called in to check if this is allowed. Once MAC says that it is allowed, DAC kicks in. It checks the uid with which apache is started. It checks if that uid is allowed write access to the file. Then it checks whether apache itself is allowed to write to the file.
This of course, is a minimalistic explanation, as stated above.
So how does SELinux help secure one's system? Let's take an example.
Suppose we have apache running. Suppose there's a zero day vulnerability in apache that hasn't been patched yet (Duh, because there's no fix to a zero day vulnerability, it is called so! So it is imperative that it hasn't been patched yet). Now, a cracker gains access to this system, exploits the vulnerability and gains control of apache. Now this vulnerability is such that the cracker could gain control of the entire system, once he controls apache. But if the system is secured with SELinux, this won't happen. Why? Because our apache is running in a sandbox. It is not allowed access to anything else outside some certain files. This way, even if apache is compromised, it is just that one process which is compromised, nothing else.
I hope this email will serve its purpose. I suggest a book by O'Reilly called SELinux for studying SELinux. It's very good.
Cheers, Mrugesh