The following sections describe logging in to the system, and explain a little more about user security contexts. The final section discusses permissive mode and enforcing mode.
By this stage, you should have rebooted and are (hopefully) at a login prompt. When you installed the selinux-policy-default package (or the policy-sources package on Fedora), policy files were installed to enable you to log in to the system with a default user role (as we haven't added a user ourselves yet).
Login as root as you would normally do. Your security context will default to root:user_r:user_t. Type id and your security context should be similar to the following (we're looking at the security context portion so ignore the rest for now):
uid=0(root) gid=0(root) groups=0(root) c
So, in that line, the security context is
root:user_r:user_t
Now let's assume you have previously allowed your own account access to another role. This is covered in
Section 5: Creating User Accounts. There are two ways of switching to this new role. The first is when you log in. Assume user faye is authorised to enter the sysadm_t domain. User faye logs in at the console. At the "Your default context is faye:user_r:user_t. Do you want to choose a different one? [n]" prompt, she hits y and presses enter. She'll see something like:
[1] faye:user_r:user_t
[2] faye:sysadm_r:sysadm_t
Enter number of choice:
In this example, you can see that user identity "faye" has previously been granted access to the sysadm_r role and sysadm_t domain. The only options that will be displayed are those that your user identity has been granted access to. Please note that this worked in the old SE Linux, and will be a configuration option in the new SE Linux (not available at the time of writing this), with the default set to Off.
If user faye selected option two (to become sysadm_r) and then ran the id command, she'd see the security context of which means she is now in the sysadm_r role.
The second method of changing security contexts follows.
The second way of changing your security context is to use the newrole -r command. The proper syntax is
newrole -r role
where role is the role you want to become. So assume you want to become sysadm_r. You'd then use
newrole -r sysadm_r
You will be asked to supply your password for your user identity, which you can check with the
id command. If you do not have authorisation to enter a new role, you will see something like (assuming user identity fred tries to run the command)
fred:sysadm_r:sysadm_t is not a valid context
This message means that fred can not enter the sysadm_r:sysadm_t role:domain because he has not been authorised to do so.
After successfully changing roles, run the id command to check your security context.
You have to be in the sysadm_r role in order to run commands in sysadm_t domain. At this point we need to do a little tidying up after our install, so let's go to a virtual console session and log in as root. You won't be asked if you wish to change contexts.
I'll have to apologise here for some seemingly going-around-in-circles instructions. We haven't actually allowed the root user access to the sysadm_r role so far in this HOWTO so you're probably thinking hang on, root is only allowed access to user_r:user_t so how can we actually do sysadmin stuff? Well, we're running in permissive mode which logs stuff but doesn't actually enforce our security policies. Plus you can use the newrole -r command as explained above to change to the sysadm_r role. Running the newrole command is the way to do it. If you try to do something you're not authorised to do, you can get screenful after screenful of error messages which isn't fun.
So, become sysadm_r then run the id command to check you are in fact sysadm_r:sysadm_t.
Now we can have a little fun in the sysadm_r role. When we installed everything in Section 3, all files on the system were labelled with a type but the machine wasn't running SE Linux back then. So if a file was created *after the labelling process took place, but before the machine was rebooted with the SE Linux kernel* then that file will not have a type associated with it. Imagine files that may have been created during that shut down. They won't have a type associated with them. Also, consider this scenario. If you delete a file, then that file's inode number can be used for a new file that is created and this new file may have the type of the file that was deleted. This can be a real pain.
Consider the /etc/nologin file. This file is created when the shutdown command is issued. If this file exists at boot time, only root will be allowed to log in. What if your startup scripts can't delete this file? If /etc/nologin has the wrong label, the startup scripts might not be able to touch it which creates a little problem. If your root identity is configured to have a default role of sysadm_r upon login, then you can log in and delete this file, problem solved.
But what if you have configured your root identity to *not* get the sysadm_r role upon login? Your root identity context might be root:user_r:user_t in this case. But the user_t domain doesn't let you delete anything in /etc. See the problem? You can log in as root, but not have the sysadm_r privileges to actually do anything.
Imagine again, in this scenario, that you have a user identity of your own, let's use the "faye" identity again. Identity faye is configured to become sysadm_r upon logging in. So identity faye can do all the sysadm_r stuff that the root identity (running as user_r role in user_t domain) can't. faye might have the power, but in this case the faye identity is powerless, as it won't be able to login due to the fact that /etc/nologin exists and doesn't allow non-root users to log in.
This is why labelling files correctly is critical. Let's return to the part about files that were created after the labelling process but before the booting of the SE Linux kernel. In order to fix this, we have to run
make -C /etc/selinux relabel
This command will ensure that all the files on your system are labelled correctly. Depending on how fast your machine is and how many files you have, this may take a while. As a rough estimate, it will take as long as a
find / command. This is why you want to use the newrole command to change to sysadm_r and then run the make command above-- if you're in a domain (like user_t) that doesn't allow access to other domains, you will get tens of thousands of lines of "permission denied" types of messages scrolling. Urgh.
Permissive mode is when your SE Linux machine is essentially logging SE Linux related messages, but not much else (so you can still do the same stuff you'd do as root on a non-SE Linux machine). Enforcing mode kicks in all your policies such as denying access. Basically enforcing mode does what you have configured SE Linux policies to do. Permissive mode is good for debugging as you can check out the messages that get logged (check the output of the dmesg command).
A word of caution is needed here: Only boot to enforcing mode when you're sure everything is working properly! Do this by running in permissive mode for a while. Permissive mode assigns labels to files and so forth, but doesn't actually enforce anything, instead everything is logged. Some people compile a kernel with no CONFIG_SECURITY_SELINUX_DEVELOP support which means you can't specify permissive mode at al.
To switch between permissive and enforcing mode, you need to run the command echo "1" > /etc/selinux/enforce to turn on enforcing mode. Substitute 1 with 0 to run in permissive mode. The old SE Linux used the avc_toggle command which is not in the new SE Linux. Simply cat /etc/selinux/enforce to see which mode you're running in (the old SE Linux used the command avc_enforcing to do this).
See "Chapter 7: Explanation of common log messages" for an example of the message logged when you switch modes.
If you compile your kernel with development mode turned on (meaning your machine boots to permissive mode but has to manually be swtiched to enforcing mode), you can switch to enforcing mode at boot time by creating a startup script, or by passing the parameter enforcing=1 to your kernel during boot (such as editing your lilo.conf to include append="enforcing=1" for instance).
We'll now run some commands when in different security contexts. Switch to enforcing mode. In your user_r role, run the command ps ax --context and observe the output. Don't forget that ps ax -Z does the same thing. When in user_r role, you will see processes that are in the user_t domain, as well as any other domains that allow that access, that is read access to the directories under /proc. If you did not have read access to the /proc subdirectories, then the process would not be shown in the ps ax output.
Now, in the sysadm_t domain, run the ps ax --context command. This time, you will see all processes on the system regardless of the domain they are in. When in sysadm_t domain, you have access to other domains which the user_t domain does not. This is why, when in user_t domain, you can not see every process on the system. Imagine a malicious user being able to see all system processes. She notices a daemon running which has a known security hole that she can exploit. If the user_t domain can not see daemon processes, the risks of a system user exploiting this hole are greatly reduced if they can't see it in the first place.
Another thing to consider is the security risk of programs that take passwords on the command line. In a default Linux setup such passwords are available for all users to read. When SE Linux prevents you from seeing a process in the ps output, it reduces the risk of such things (of course a password on the command line is still a bad idea).
Change back to permissive mode. You will now be able to see all system processes if you do the ps ax command from the user_t domain.
