1
The Makefile targets are:
2
policy - compile the policy configuration.
3
install - compile and install the policy configuration.
4
load - compile, install, and load the policy configuration.
5
relabel - relabel the filesystem.
6
check-all - check individual additional policy files in domains/program/unused.
7
checkunused/FILE.te - check individual file FILE from domains/program/unused.
9
If you have configured MLS into your module, then set MLS=y in the
10
Makefile prior to building the policy. Of course, you must have also
11
built checkpolicy with MLS enabled.
13
Three of the configuration files are independent of the particular
15
1) flask/security_classes -
16
This file has a simple declaration for each security class.
17
The corresponding symbol definitions are in the automatically
18
generated header file <selinux/flask.h>.
20
2) flask/initial_sids -
21
This file has a simple declaration for each initial SID.
22
The corresponding symbol definitions are in the automatically
23
generated header file <selinux/flask.h>.
26
This file defines the access vectors. Common prefixes for
27
access vectors may be defined at the beginning of the file.
28
After the common prefixes are defined, an access vector
29
may be defined for each security class.
30
The corresponding symbol definitions are in the automatically
31
generated header file <selinux/av_permissions.h>.
33
In addition to being read by the security server, these configuration
34
files are used during the kernel build to automatically generate
35
symbol definitions used by the kernel for security classes, initial
36
SIDs and permissions. Since the symbol definitions generated from
37
these files are used during the kernel build, the values of existing
38
security classes and permissions may not be modified by load_policy.
39
However, new classes may be appended to the list of classes and new
40
permissions may be appended to the list of permissions associated with
41
each access vector definition.
43
The policy-dependent configuration files are:
45
This file defines the Type Enforcement (TE) configuration.
46
This file is automatically generated from a collection of files.
48
The macros subdirectory contains a collection of m4 macro definitions
49
used by the TE configuration. The global_macros.te file contains global
50
macros used throughout the configuration for common groupings of classes
51
and permissions and for common sets of rules. The user_macros.te file
52
contains macros used in defining user domains. The admin_macros.te file
53
contains macros used in defining admin domains. The macros/program
54
subdirectory contains macros that are used to instantiate derived domains
55
for certain programs that encode information about both the calling user
56
domain and the program, permitting the policy to maintain separation
57
between different instances of the program.
59
The types subdirectory contains several files with declarations for
60
general types (types not associated with a particular domain) and
61
some rules defining relationships among those types. Related types
62
are grouped together into each file in this directory, e.g. all
63
device type declarations are in the device.te file.
65
The domains subdirectory contains several files and directories
66
with declarations and rules for each domain. User domains are defined in
67
user.te. Administrator domains are defined in admin.te. Domains for
68
specific programs, including both system daemons and other programs, are
69
in the .te files within the domains/program subdirectory. The domains/misc
70
subdirectory is for miscellaneous domains such as the kernel domain and
71
the kernel module loader domain.
73
The assert.te file contains assertions that are checked after evaluating
74
the entire TE configuration.
77
This file defines the Role-Based Access Control (RBAC) configuration.
80
This file defines the Multi-Level Security (MLS) configuration.
83
This file defines the users recognized by the security policy.
86
This file defines additional constraints on permissions
87
in the form of boolean expressions that must be satisfied in order
88
for specified permissions to be granted. These constraints
89
are used to further refine the type enforcement tables and
90
the role allow rules. Typically, these constraints are used
91
to restrict changes in user identity or role to certain domains.
93
6) initial_sid_contexts -
94
This file defines the security context for each initial SID.
95
A security context consists of a user identity, a role, a type and
96
optionally a MLS range if the MLS policy is enabled. If left unspecified,
97
the high MLS level defaults to the low MLS level. The syntax of a valid
100
user:role:type[:sensitivity[:category,...][-sensitivity[:category,...]]]
103
This file defines the labeling behavior for inodes in particular
107
This file defines security contexts for files in filesystems that
108
cannot support persistent label mappings or use one of the fixed
109
labeling schemes specified in fs_use.
112
This file defines the security contexts of network objects
113
such as ports, interfaces, and nodes.
115
9) file_contexts/{types.fc,program/*.fc}
116
These files define the security contexts for persistent files.
118
It is possible to test the security server functions on a given policy
119
configuration by running the checkpolicy program with the -d option.
120
This program is built from the same sources as the security server
121
component of the kernel, so it may be used both to verify that a
122
policy configuration will load successfully and to determine how the
123
security server would respond if it were using that policy
124
configuration. A menu-based interface is provided for calling any of
125
the security server functions after the policy is loaded.
added
removed
README
