Following are some examples of things you can try to get a feel for editing policy.
Don't forget to run make load in your policy source directory after saving the policy file.
12.1 Allow user_t to use tcpdump
If you haven't done so already, create a custom file (let's call it custom.te) in the subdirectory
domains/misc/ under your policy source directory. Add the following lines:
# your own comment here
domain_auto_trans(userdomain, netutils_exec_t, netutils_t)
in_user_role(netutils_t)
allow netutils_t user:chr_file rw_file_perms;
First of all, we need to be able to transition from the user domain (userdomain here refers to all possible user domains, so user_t, staff_t, sysadm_t and whatever other user domains you may have) to the domain for the actual tcpdump process, which is netutils_exec_t. What the first line is saying is "when the user domain runs the tcpdump executable, an automatic transition is made to the tcpdump process domain which is netutils_t".
The in_user_role macro (defined in the file user_macros.te) permits the domain passed as a parameter (in this case netutils_t) to be in all the user roles (such as user_r and staff_r. sysadm_r is an administrative role, not a user role). This line is needed so that any combination of role user_r and domain netutils_t is valid in a security context.
The third line allows the domain netutils_t to access user pty types. netutils_t needs this access so that you can read from and write to your terminal device. chr_file is needed to write to the terminal device.
Exercise 1: Play around with these lines. Comment out the allow line, reload the policy and try to tcpdump. Check the logs to give you hints on why nothing seems to be happening.
Exercise 2: With the allow line commented out, switch to a virtual console (assuming you were using an xterm before) and try to tcpdump from there. If you have not specifically allowed tcpdump access from a tty device, try to make it happen. You should be able to tcpdump from a pty device, but not from a tty device so make the necessary changes and try again.
12.2 Allow user_t to read the /etc/selinux/ directory.
Ordinarily you probably don't want unprivileged users to see what's in
/etc/selinux/ but for the sake of learning (assuming you're on a test machine playing around with SE Linux) I'll use this example. Edit your custom.te file to include the following:
# your comment here
r_dir_file(user_t,policy_src_t)
The r_dir_file allows you to read a directory and files underneath it. user_t is the domain, and policy_src_t is the type of
/etc/selinux .
Exercise 1: try to access /etc/selinux before and after editing custom.te (and reloading the policy). Check the logs to see what's happening.
Exercise 2: from user_t try to access /boot. Got "permission denied"? Create a rule that allows user_t to read this directory.
12.3 Creating a new type
In this example we'll create a new file type for ourselves in custom.te so add the following lines and then run the make load command:
type ourtype_t,file_type,sysadmfile;
allow staff_t ourtype_t:file { create_file_perms relabelfrom relabelto };
We define our new type called "ourtype_t", assign it the attribute file_type and sysadmfile so that the administrator can access it. The second line says that staff_t has full access to files of type ourtype_t (read, write and so forth). The relabelfrom and relabelto mean that staff_t can relabel files of type ourtype_t from and to another type.
Now, in a staff_t role (I'm not going to tell you how to do that, read the Getting Started with SE Linux HOWTO) create a file. Check the security context of that file:
faye@kaos:~$ ls -Z foo
-rw-r--r-- faye faye faye:object_r:staff_home_t foo
So we see file "foo" has the type staff_home_t. Now change that type to ourtype_t:
faye@kaos:~$ chcon -t ourtype_t foo
faye@kaos:~$ ls -Z foo
-rw-r--r-- faye faye faye:object_r:ourtype_t foo
Now let's remove the type we just created. Once again, edit your custom.te file to comment out what you just added. Run make load again, and try to look at the file's attributes:
faye@kaos:~$ ls -Z foo
ls: foo: Permission denied
As sysadm_r run the same ls command:
-rw-r--r-- faye faye faye:object_r:ourtype_t /home/faye/foo
Now check your logs for the error that was logged when, as staff_r, you tried to access file foo:
avc: denied { getattr } for pid=29494 exe=/bin/ls path=/home/faye/foo dev=md7 ino=145445 sc
_r:staff_t tc t
Note that the target context contains the type unlabeled_t for file foo. When we removed type ourtype_t from the policy, any files we created with that type are relabelled to type unlabeled_t. Note that even though ls -Z says the type is ourtype_t the kernel regards it as unlabeled_t as ourtype_t does not exist in the policy.
