(Imported from MoinMoin)
m (→SELinux Key Components: Applications)
|(One intermediate revision by one user not shown)|
|Line 1:||Line 1:|
= SELinux Key
= SELinux Key : Applications =
== Kernel ==
== Kernel ==
Latest revision as of 13:03, 21 February 2010
 SELinux Key Components: Applications
When I usually give my SELinux talk, I have a section on Key components of SELinux and I usually start out talking about the kernel. But I find that most people understand that SELinux is integrated in the upstream kernel. The kernel has many access checks built into it, and the access checks call into the Linux Security Module (LSM). But I am not a SELinux Kernel Engineer, nor do I play one on TV. So I will leave it to the Stephen Smalley's and James Morris's of the world to explain the SELinux Kernel. Besides this is SELinux for dummies, and we know that no dummies work on the kernel. :^).
Most of the papers on SELinux talk about the Kernel, and how this integration happens.
The more interesting part in my opinion is how the rest of the Base Operating System uses SELinux. Of course that is what I work on ...
Most user applications and server applications unchanged SELinux aware applications. Of the hundreds/thousands of rpm packages in a Fedora only about 50 are compiled with SELinux awareness in them. This is one of the powerful features of SELinux in that applications do not need to be aware of SELinux.
The power of this is that it is fairly easy to write policy for a new daemon. You do not need to be a "C" programmer or fully understand the way the application works, but you can confine it with policy.
One problem with this, that you may have seen is that since an application is not aware if it is being blocked by Discretionary Access Control, or Mandatory Access Control. It just gets EPERM, Permission Denied. Administrators can become confused by this. For example an administrator sets up a web page, the permissions on the files and ownership of the file are set correctly, yet apache reports permission denied. The file context on the files are set incorrectly, but apache has no awareness of this. We are working on tools to make this more obvious to the Administrator, but for now they need to know to look in the /var/log/messages file or /var/log/audit/audit.log for AVC messages.
So which applications need to be SELinux aware?
- Applications used to view or manipulate security contexts (Core Utilities)
Examples of this are the ls for viewing file context, ps for viewing process context.
- Programs required to set user session security context
The login programs are the most obvious programs for this login, sshd, gdm ... Also cron
- The SELinux core programs.
These are used to control/manipulate security context. chcon, setfiles, restorecon Used to manipulate policy: load_policy, check_policy, check_module, semodule, semanage, setenforce, getenforce, setsebool, getsebool ...