SLIDE into SELinux policy development
Complaints about SELinux often center around its overall complexity and the difficulty in developing policies for applications that run on the system. The SELinux Policy IDE (SLIDE) is an Eclipse plug-in that provides a framework for developing and testing policies that should help reduce some of these problems.
SELinux is a security framework that uses the Linux Security Module (LSM) kernel interface to implement mandatory access control (MAC) mechanism. MAC controls the capabilities that a particular process can have based on the policies installed by the administrator. Those policies govern much more than traditional UNIX-style permissions and for that reason can be difficult to generate and especially to test. Readers of this page will remember an overview that covers a bit more detail about SELinux internals.
SLIDE is an effort to ease the process of developing policies with an eye towards applications and daemons that have policy support. To do that, it uses the popular Eclipse integrated development environment (IDE) as a way to organize and control policy development. It provides all of the expected capabilities within Eclipse: syntax highlighting, auto-completion, integrated searching, etc. One of the biggest hurdles that developers face is keeping track of the various interfaces, types, roles, and modules and how they interact; SLIDE organizes and indexes them, along with their comments, and makes that available in a nice GUI.
The testing features are particularly useful; one can set up a remote machine (or local virtual machine) that can accept policy updates from SLIDE. Once the updates have been accepted, various tests can be kicked off on the remote machine and the audit log can be monitored to determine whether the policies covered all of the required resources. If not, the policy can be modified in SLIDE, pushed out to the remote machine and tested again.
SLIDE is a project of Tresys Technology, which has released it under the GPL. It does not appear to have attracted much of a development community, at least yet and the SourceForge project page has not been updated in quite some time. The documentation and trac site provided by Tresys are excellent. Perhaps the SourceForge project was an attempt to enlist community aid which did not attract the level of interest that they might have hoped for. It is a fairly esoteric subject that does not cause too many open source developers to itch. Many of those developers, perhaps, simply turn SELinux off.
As with most complex tools, SLIDE will not be terribly helpful to those who know little about SELinux policies. It has a steep learning curve even if you have a bit of that background, but for experts it is probably quite intuitive. For those reasons, it probably will not help other projects to generate policies for their software. In order to foster more applications with SELinux policies, it is likely that experts in policy development will have to join forces with these other projects to produce and maintain the policies. Using SLIDE will likely speed up that process and it is a welcome addition to a fairly sparse toolkit.
Index entries for this article | |
---|---|
GuestArticles | Edge, Jake |
Posted Feb 8, 2007 1:54 UTC (Thu)
by jamesm (guest, #2273)
[Link] (1 responses)
Posted Feb 8, 2007 16:48 UTC (Thu)
by Method (guest, #26150)
[Link]
Posted Feb 10, 2007 21:21 UTC (Sat)
by skybrian (guest, #365)
[Link] (1 responses)
(This assumes a lot from static program analysis, but that's inherent in the problem since policies are static.)
Posted Mar 3, 2007 12:34 UTC (Sat)
by erich (guest, #7127)
[Link]
Then you don't know about the precision; one application might be accessing /home/user/.browser/cache/foobar, and another /etc/resolv.conf.
Also lots of applications have bugs, and access files that they do not need.
Futhermore, application behaviour can depend on various other modules. For example, when you use libpam-ldap, suddenly many applications will start connecting to LDAP servers. You'd need to learn each app in each configuration setting.
Automatic learning just won't work properly, sorry.
You're right that it won't be useful unless you already know about SELinux policies. SLIDE is intended as a tool for policy developers, such as distro developers, people working on custom security projects etc., and not for package developers or sysadmins. Other projects are being developed for these purposes as the underlying infrastructure matures.
An example of this is Madison, being developed by Karl MacMillan, which is intended to:
SLIDE into SELinux policy development
Provide tools suitable for Linux administrators who are not SELinux experts. The tools guide administrators throuch complex security decisions.
Madison is good development with potential to assist in policy development but it is still a work in progress, primarily a library and a replacement for audit2allow so it only helps when denials happen. There are also some potential plans to integrate Madison into SLIDE in the future.
SLIDE into SELinux policy development
<shameless product plug>
Brickwall, a product developed by the company I work for, helps write policy without knowledge of types and can confine network services to specific interfaces and networks.
</shameless product plug>
I'm sure folks who study this have thought of it already, but it seems like taking a different approach would work better: instead of manually writing policies, compiling and installing a program should automatically generate a policy that grants access to all the resources that the program could potentially need, and no more, with links back to the code that requires access. The jail's role is only to make sure that the program meets its own policy. Security would come from reviewing program policies for red flags and looking at any changes in new versions. Developers would then be able to improve security by rewriting their code to remove any dependencies that aren't strictly needed. Nobody would need to write policies.Why aren't policies automatically generated?
First of all, you'd need to have the application trigger all it's behaviour.Why aren't policies automatically generated?
If you just start up the browser and close it right away, it might not write files to its cache etc.; so a trained policy will also likely be incomplete.
How is a learning algorithm expected to know that in the first case it's supposed to be a wildward like $HOME/.browser/cache/* whereas in the second case it's an exact match only?
There is no "open all files in this directory" command, to the OS it's just a bunch of file accesses.
If you are using an abstraction layer, it's easy to find out which applications are using PAM or NSS, and then map them to accessing ldap, kerberos, winbind, mysql, whatever datasource.