126 lines
5.8 KiB
Plaintext
126 lines
5.8 KiB
Plaintext
The Makefile targets are:
|
|
policy - compile the policy configuration.
|
|
install - compile and install the policy configuration.
|
|
load - compile, install, and load the policy configuration.
|
|
relabel - relabel the filesystem.
|
|
check-all - check individual additional policy files in domains/program/unused.
|
|
checkunused/FILE.te - check individual file FILE from domains/program/unused.
|
|
|
|
If you have configured MLS into your module, then set MLS=y in the
|
|
Makefile prior to building the policy. Of course, you must have also
|
|
built checkpolicy with MLS enabled.
|
|
|
|
Three of the configuration files are independent of the particular
|
|
security policy:
|
|
1) flask/security_classes -
|
|
This file has a simple declaration for each security class.
|
|
The corresponding symbol definitions are in the automatically
|
|
generated header file <selinux/flask.h>.
|
|
|
|
2) flask/initial_sids -
|
|
This file has a simple declaration for each initial SID.
|
|
The corresponding symbol definitions are in the automatically
|
|
generated header file <selinux/flask.h>.
|
|
|
|
3) access_vectors -
|
|
This file defines the access vectors. Common prefixes for
|
|
access vectors may be defined at the beginning of the file.
|
|
After the common prefixes are defined, an access vector
|
|
may be defined for each security class.
|
|
The corresponding symbol definitions are in the automatically
|
|
generated header file <selinux/av_permissions.h>.
|
|
|
|
In addition to being read by the security server, these configuration
|
|
files are used during the kernel build to automatically generate
|
|
symbol definitions used by the kernel for security classes, initial
|
|
SIDs and permissions. Since the symbol definitions generated from
|
|
these files are used during the kernel build, the values of existing
|
|
security classes and permissions may not be modified by load_policy.
|
|
However, new classes may be appended to the list of classes and new
|
|
permissions may be appended to the list of permissions associated with
|
|
each access vector definition.
|
|
|
|
The policy-dependent configuration files are:
|
|
1) tmp/all.te -
|
|
This file defines the Type Enforcement (TE) configuration.
|
|
This file is automatically generated from a collection of files.
|
|
|
|
The macros subdirectory contains a collection of m4 macro definitions
|
|
used by the TE configuration. The global_macros.te file contains global
|
|
macros used throughout the configuration for common groupings of classes
|
|
and permissions and for common sets of rules. The user_macros.te file
|
|
contains macros used in defining user domains. The admin_macros.te file
|
|
contains macros used in defining admin domains. The macros/program
|
|
subdirectory contains macros that are used to instantiate derived domains
|
|
for certain programs that encode information about both the calling user
|
|
domain and the program, permitting the policy to maintain separation
|
|
between different instances of the program.
|
|
|
|
The types subdirectory contains several files with declarations for
|
|
general types (types not associated with a particular domain) and
|
|
some rules defining relationships among those types. Related types
|
|
are grouped together into each file in this directory, e.g. all
|
|
device type declarations are in the device.te file.
|
|
|
|
The domains subdirectory contains several files and directories
|
|
with declarations and rules for each domain. User domains are defined in
|
|
user.te. Administrator domains are defined in admin.te. Domains for
|
|
specific programs, including both system daemons and other programs, are
|
|
in the .te files within the domains/program subdirectory. The domains/misc
|
|
subdirectory is for miscellaneous domains such as the kernel domain and
|
|
the kernel module loader domain.
|
|
|
|
The assert.te file contains assertions that are checked after evaluating
|
|
the entire TE configuration.
|
|
|
|
2) rbac -
|
|
This file defines the Role-Based Access Control (RBAC) configuration.
|
|
|
|
3) mls -
|
|
This file defines the Multi-Level Security (MLS) configuration.
|
|
|
|
4) users -
|
|
This file defines the users recognized by the security policy.
|
|
|
|
5) constraints -
|
|
This file defines additional constraints on permissions
|
|
in the form of boolean expressions that must be satisfied in order
|
|
for specified permissions to be granted. These constraints
|
|
are used to further refine the type enforcement tables and
|
|
the role allow rules. Typically, these constraints are used
|
|
to restrict changes in user identity or role to certain domains.
|
|
|
|
6) initial_sid_contexts -
|
|
This file defines the security context for each initial SID.
|
|
A security context consists of a user identity, a role, a type and
|
|
optionally a MLS range if the MLS policy is enabled. If left unspecified,
|
|
the high MLS level defaults to the low MLS level. The syntax of a valid
|
|
security context is:
|
|
|
|
user:role:type[:sensitivity[:category,...][-sensitivity[:category,...]]]
|
|
|
|
7) fs_use -
|
|
This file defines the labeling behavior for inodes in particular
|
|
filesystem types.
|
|
|
|
8) genfs_contexts -
|
|
This file defines security contexts for files in filesystems that
|
|
cannot support persistent label mappings or use one of the fixed
|
|
labeling schemes specified in fs_use.
|
|
|
|
8) net_contexts -
|
|
This file defines the security contexts of network objects
|
|
such as ports, interfaces, and nodes.
|
|
|
|
9) file_contexts/{types.fc,program/*.fc}
|
|
These files define the security contexts for persistent files.
|
|
|
|
It is possible to test the security server functions on a given policy
|
|
configuration by running the checkpolicy program with the -d option.
|
|
This program is built from the same sources as the security server
|
|
component of the kernel, so it may be used both to verify that a
|
|
policy configuration will load successfully and to determine how the
|
|
security server would respond if it were using that policy
|
|
configuration. A menu-based interface is provided for calling any of
|
|
the security server functions after the policy is loaded.
|