In this section we'll discuss what policies are, what you can do with them,
how they're created and how you make them take effect.
Policies are a set of rules governing things such as the roles a user has
access to; which roles can enter which domains and which domains can access
which types. You can edit your policy files according to how you want your
system set up. The purpose of SE Linux is to enforce policies, so policies form
the core of SE Linux. The default policy is to deny everything and every operation has to be explicitly permitted in a policy file.
Polices allow you the flexibility to configure your system as you wish. You
may choose to have user A access both the user_r and sysadm_r roles, and
have user B access the user_r role only. Policies can be as strict or as
lenient as you require. Policies can also control what programs can do,
and how programs can interact with each other such as controlling the
accessing of files, programs tracing eachother, and sending signals. For
example, with regard to accessing files you can have a policy for files
created under
/tmp so that one domain creates them, but another domain
can't access them.
Policies must be compiled in to binary form before they can be used. In order
to do this, you must run
make in the policy directory,
which is
/etc/selinux/ for Debian and
/etc/security/selinux/src/policy under Red Hat. The process of compiling the SE Linux policy is
as follows:
1) The policy configuration files are concatenated together.
The policy configuration files end in .te and
are found in the policy directory and subdirectories under that.
2) The m4 macro processor is applied to the result of the above
concatenation, which then creates the policy.conf file.
The policy.conf file is found in the policy
directory, and contains things such as the definition of types, domains, rules
for what each domain can do, roles, users, what roles users can access and
lots of other stuff.
3) The checkpolicy policy compiler is run on policy.conf.
This results in the creation of the policy.VERSION file, where VERSION is the version number. policy.VERSION is installed in to the /etc/security/selinux directory by running the command make install in the policy directory. This policy will then be loaded on the next reboot. If however, you wish to make a runtime change to your policy, you can run the command make load in the policy directory so that you can load the new policy in to a running kernel.
When you wish to perform a certain operation on a SE Linux system, your ability to do so is determined by your security context, the class of the object you're trying to access and the type of that object. For instance, a file has a class of file, a directory has a class of dir, and a Unix domain socket has a class of sock_file. The type of the object you're trying to access is predetermined by the policy. Let's say that as unprivileged user faye, I try to do
ls -l /etc/shadow. Here is what gets logged (check the output of the dmesg command as sysadm_r) when I do this:
avc: denied { getattr } for pid=10387 exe=/bin/ls path=/etc/shadow dev=03:03 ino=129766 \
sc tc t
The Getting Started With SE Linux HOWTO document discussed these kinds of messages so I won't talk about them in depth here, instead I'll just talk about the bits relevant to this section. The source context (scontext) of the user running
ls -l /etc/shadow is faye:user_r:user_t. So the identity is "faye" and I'm in the user_r role in the user_t domain. The target context (tcontext) is system_u:object_r:shadow_t so in other words,
/etc/shadow has the type shadow_t. The class (tclass) of the target is file, so we know that
/etc/shadow has a class of file. The entire avc message above shows my attempt to stat, or "getattr"
/etc/shadow has failed.
So where is it specified that /etc/shadow has the type shadow_t? The answer is in the file file_contexts under the directory file_contexts, which is under your policy source directory. If we grep for /etc/shadow in this file we see
/etc/shadow.* -- system_u:object_r:shadow_t
The specification for
/etc/shadow's type is also found in the
types.fc file, which is compiled to produce the file_contexts file. In this example, files called
/etc/shadow.* have the system_u identity, as any files "owned" by the system have system_u. object_r is the role assigned to files, which doesn't mean all that much as roles are not relevant to files.
