We'll now get in to the fun part of actually editing SE Linux policy. This takes a fair bit of practise. The best thing to do is just play around with it all. It can be quite a challenge to get started with as a lot of stuff isn't documented and you'll most likely take the trial-and-error approach. Make sure you look at other policies already written in
/etc/selinux/domains/program/ and the corresponding
file_contexts file in
/etc/selinux/file_contexts/program/ .
Here are some tips to keep in mind when you edit policy.
Work out what you want to change/edit.
Try to get a good understanding of what you're going to change. Is there some kind of action you want to allow, such as (for instance) allowing users in the user_r role to be able to see a certain directory not allowed in a default installation? What domain/s would be involved? What macros would you need to call? Look at existing rules to get an idea of syntax. Look up macros in the macros directory to get a feel for what they do.
Create a file where you have custom rules.
I have a file called custom.te in the subdirectory domains/misc/ (under my policy source directory). In this file I include my own rules which are customised for what I want to do. Call this file something unique so that it won't get overwritten during an upgrade of the policy. custom.te should be fine. You can use this file to test stuff.
Study the kernel messages.
If something isn't happening as you want it to, check out the kernel messages. A big part of writing policy is to study the logs then add or change rules to eliminate errors listed in the logs. If staff_t tries to run tcpdump and the operation is denied for instance, check the logs. You might see something like
avc: denied { create } for pid=17824 exe=/usr/bin/traceroute.lbl sc tc :staff_r:staff_t t
Here we can see that someone in the staff_t domain tried to execute the traceroute command and was denied. From this log message we can work out that traceroute was running in the domain staff_t but we want it to run in a privileged domain that is able to traceroute. What we would need to do is edit our policy to allow staff_t to transition to traceroute_t (the domain for the traceroute process) when it executes the type traceroute_exec_t (which is the type of the actual traceroute executable, as opposed to the traceroute process that runs after you've executed the traceroute command).
Comment the changes you make and why you made them.
Self explanatory :)
