BigChanges
From SELinux Wiki
Revision as of 13:57, 24 October 2007 by KarlMacMillan (Talk)
SELinux Proposed Changes
It is time to consider some more radical changes to SELinux - both the policy language and kernel mechanism - to address persistent usability problems. Hopefully these changes can be made in a compatible way, but incompatible changes will be considered.
Use Cases
These need to be filled in considerably - this is just a start.
- Restrict Apache to only talking on eth0 or only accepting connections from a set of IP addresses.
- Allow a user to only run a small set of applications.
- Remove access to a file type from unconfined and grant that to another domain - this is requested a lot and people normally say they want decent non-bypassibility but understand that it is not perfect.
- Security Admin and System Admin separation.
- Create a java_t that is the same as user_t but also includes execmem.
- Create a modified firefox domain that can't access the home directory.
General Goals
- Minimal abstraction and indirection: many of our abstractions leak (e.g., hiding types does not work) and often security goals must be expressed indirectly. There should be as close to a 1 to 1 correspondence between abstractions in the policy, security goals, and what the kernel enforces.
- Brevity: the policies need to be much shorter (ideally 1 page of text in an editor).
- DRY (Don't Repeat Yourself): you should not have to repeat the same information in multiple places (e.g., many interfaces are just redundant and could be handle via a single allow rule).
- Unix-like permissions: the object classes and permissions should more closely match concepts that a typical unix admin or developer would understand. Reducing granularity of permissions will help greatly here.
- Unix-like configuration: text files are good - stop using binary modules. Include a standard way of making local mods (e.g., /etc/selinux/targeted/local.d).
Policy Language Changes
- Type Classes
- File contexts in the language