• 1

Re: Comments

Our goal is to give administrators choices of how they want to run their system, without forcing them to write policies.

This works only for basic applications and environments. It obviously does not provide room for much customization. That said, I think Selinux is great once administrators can write their own policies. As has been said before this leads back to the discussion on documentation and tutorials; the Selinux project simply needs more of it. Or at the very least a visual tool which allows you to see appropriate context of changes made or programs added to policy and how they affect other packages. Or maybe using a macro for something would be bad in some form or combination etc etc.

Interestingly enough I came across this thread, while trying to figure out if Selinux was included in RHEL v3. I came across apparmor yesterday which from what I can tell is just Immunix. The main difference between the two? Documentation. The guide for lets say RHEL V4 and AppArmor are worlds apart.

You get to Chapter 8 in the RHEL V4 guide and what?

Presenting a comprehensive guide to writing policy is not within the scope for this book. For more information on writing policy, refer to the resources in Chapter 9 References.

You click on the HOWTO on writing Policy, learn about attributes, users, te's, etc etc and then you think you're gonna get some good answers you get:

We'll now get in to the fun part of actually editing SE Linux policy. This takes a fair bit of practise. The best thing to do is just play around with it all. It can be quite a challenge to get started with as a lot of stuff isn't documented and you'll most likely take the trial-and-error approach. Make sure you look at other policies already written in /etc/selinux/domains/program/ and the corresponding file_contexts file in /etc/selinux/file_contexts/program/

Considering that a major part of Selinux is enforcing policy. You can't expect someone to place all their security in the fact that others have written policy for programs. Not only that but what about ones own program which Redhat hasn't written policy for? Also, considering that Selinux the actual project is being built on a Fedora machine with core system packages being patched and modified, acquiring the patches for fedora first become a pain. Binding lets say Novell to Fedora, there is much involved in that alone. I say after going through it all myself, its a steep hill and alot of time involved in even setting it up. Then understanding how to write policy? Thats even more time, since there really is no documentation its just all trial and error.

This is why I suspect most distros provide Selinux support in the kernel/userland and just stop there. It ships, selinux=0.

Redhat just needs to provide proper documentation on writing policy. Otherwise the lazies will indeed choose AppArmor. I can't speak on the technical merits of it mind you but it does look like the easy way out. I suspect the reason everyone does Selinux=0 is because no one understands it and no one understands it because there is no good howto, no good documentation and seemingly no one wants to write any.

Anyway, yeah.. rhelv3.. no selinux.. so now my selinux skills go back in the closet.

Christopher Warner

Re: Comments

Your concerns are legit, but there is quite a bit of work in progress to deal with them, including the reference policy (serefpolicy.sourceforge.net), a policy IDE (should be released soon, being presented at the SELinux Symposium), and a book on policy writing that is in progress.

  • 1

Log in