Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

The Guide to Writing SELinux Policy
Prev Home Next

2. All about policies


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.

2.1 What is a policy?


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.

2.2 What can you do with policies?


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.

2.3 How are policies created, and how do they take effect?


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.

2.4 How are decisions made?


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.

The Guide to Writing SELinux Policy
Prev Home Next

 
 
  Published with kind permission of Faye Coker Design by Interspire