SELinux Reference Policy
- Interface Reference
Projects hosted on oss.tresys.com
- CDS Framework IDE
- Certifiable Linux Integration Platform (CLIP)
- Policy Management Server
- Reference Policy
- SELinux Policy IDE (SLIDE)
- SETools Policy Analysis Suite
- The SELinux Project
Projects hosted on other sites
- SELinux Userspace
Other projects we help with in the security community
- SELinux Project
- SELinux Policy Server
Reference Policy Style Guide
All modules in Reference Policy should follow the following style guidelines.
The TE rule files should be have the following organization:
- Local policy rules
- Unconfined access rules
This section has all of the declarations for the module. This section has the following subsections:
- Boolean declarations
- Tunable declarations
- Attribute declarations
- Type declarations (including calls to templates that create types)
- Each of these subsections should be alphabetically sorted by symbol name.
- A domain and its entrypoint file type (if declared in this module) should be grouped.
- Transform interface calls, such as domain_type() and file_type() should be grouped with the corresponding type declaration.
Local policy rules
Each domain should have its own subsection. For each domain the rules should be organized in the following matter:
- self rules, starting with capability and process object classes
- rules whose object is owned by this module (raw allow rules and policy pattern), sorted by object type
- calls to kernel layer modules, sorted in alphabetical order (exception: kernel module is first)
- calls to system layer modules, sorted in alphabetical order
- calls to all other modules, sorted in alphabetical order
- blocks, whose contents are sorted as above,
- build option blocks, sorted by build option name (e.g., distro_redhat)
- conditional policy blocks, sorted by Boolean name
- tunable policy blocks, sorted by tunable name
- optional policy blocks, sorted by the name of the module being called
Note: A module can call its own interfaces. Its preferred that an interface not be created for internal-only use unless its a complicated concept that is being abstracted.
Unconfined access rules
These rules following the same rules as the local policy rules.
The interfaces should follow the InterfaceNaming guidelines. The interface files should be organized in the following manner:
- Transform interfaces
- Access interfaces
- Admin interfaces
- Unconfined interface
These are the interfaces that add a meaning to a type, such as init_daemon_domain() and file_type(). They should be sorted in the following manner:
- alphabetically by primary object type or attribute
- alphabetically by primary object type or attribute, then
- increasing in access (getattr, then setattr, read, append, write, rw, create, rename, delete, manage, relabelto, relabelfrom, relabel), then
- if an allow and dontaudit interface exist for a particular access (e.g., modulename_read_foo() and modulename_dontaudit_read_foo()), the allow interface is before the dontaudit interface.
- If there are multiple admin interfaces (e.g. modulename_admin_foo() and modulename_admin_bar()), such as for administrating a component of a module, the subcomponent admin interfaces should be sorted by component name.
- If there is an admin interface to administrate everything (e.g. modulename_admin()), it should be the last interface in this section.
If there is an interface which provides unconfined access to a module's resource, it should be the last interface in the file.
The file context entries should be sorted in the following manner:
- alphabetically by path, then
- by increasing depth, then
- entries with metacharacters (.*, ?, [a-z], etc.) first and exact matches last