Contents

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 handled 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

Some of these also require kernel changes - there is a corresponding section under kernel changes if that is required.

Merged object classes and permissions

The current object classes and permissions are deliberately as low-level and granular as possible. They map the actual kernel operations as closely as possible. This means that the number of object classes and permissions is very large and many of them are unfamiliar to unix administrators and developers.

We don't want to lose this granularity - for certain types of systems it is helpful - but for general-purpose policies shipped by distros there could be significant simplifications. The current practice of using M4 macros to group permission sets is not ideal because the avc messages still refer to the low-level permissions.

To accomplish both goals (preserving granularity and reducing complexity) a policy specified object class and permission map will be created. The kernel will receive this map so that avcs using the maps can be generated.