Difference between revisions of "BigChanges"
From SELinux Wiki
| Line 16: | Line 16: | ||
*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. | *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). | *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 | + | *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 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). | *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== | ==Policy Language Changes== | ||
| + | *merged object classes and permissions | ||
| + | *unification of types and attributes | ||
*Type Classes | *Type Classes | ||
| − | * | + | *simplified labeling statements |
| − | * | + | *file contexts language statements |
| + | *type_transition using file name information | ||
| + | *RBAC changes? | ||
| + | |||
| + | ==Toolchain Changes== | ||
| + | *text files instead of modules | ||
| + | *sepolgen based pre-processor | ||
| + | *local changes location | ||
| + | |||
| + | ==Kernel Changes== | ||
| + | *type_transition using file name information | ||
| + | *merged object classes and permissions | ||
| + | *genfscon for network filesystems | ||
| + | *avc / error message review | ||
Revision as of 14:21, 24 October 2007
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
- merged object classes and permissions
- unification of types and attributes
- Type Classes
- simplified labeling statements
- file contexts language statements
- type_transition using file name information
- RBAC changes?
Toolchain Changes
- text files instead of modules
- sepolgen based pre-processor
- local changes location
Kernel Changes
- type_transition using file name information
- merged object classes and permissions
- genfscon for network filesystems
- avc / error message review
