Now for the fun stuff! We will create an SE Linux user and assign them a role and then set a default security context for users. Under the old SE Linux, wrapper programs existed for programs like vipw (svipw was the command to use), useradd (suseradd), passwd (spasswd), chfn (schfn) etc. Under the new SE Linux, these programs have their regular names (i.e. not svipw etc etc).
We'll now create our new user. Let's call him setest.
Switch to the sysadm_r:sysadm_t role:domain. Now use the useradd command to add user setest:
root@kaos:~# id
uid=0(root) gid=0(root) groups=0(root) c sid=398
Run id as above to check that your uid is 0 and that you are in the sysadm_r:sysadm_t role:domain. If your uid is that of your regular account, then from your regular account
su to root first, then run the
newrole -r command.
root@kaos:~# useradd -c "SE Linux test user" -m -d /home/setest -g users -s /bin/bash -u 1005 setest
root@kaos:~# finger setest
Login: setest Name: SE Linux test user
Directory: /home/setest Shell: /bin/bash
Never logged in.
No mail.
No Plan.
root@kaos:~# passwd setest
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
The setest user has now been added.
Now we want to assign a role to user setest. Let's say we want him to have access to the user_r role. The configuration file concerned with this is /etc/selinux/users so open it up with your favourite editor and take a quick read through it.
At the end of the file, add the following line:
user setest roles { user_r };
This line means that user setest is authorised to enter the user_r role. If you want user setest to also have access to the sysadm_r role as well, you would instead add
user setest roles { user_r sysadm_r };
We now have to apply the changes we made to the
/etc/selinux/users file. To do this, run the following command when in sysadm_r:sysadm_t role:domain:
make -C /etc/selinux load
This takes a little while as a policy database is being created then compressed with
gzip. When the command finishes executing, you will see something like this towards the end:
Success
touch tmp/load
make: Leaving directory `/usr/share/selinux/policy/current'
With a default role of user_r, the user does not specifically have to be added to
/etc/selinux/users. Only add them to this file if you want them to: have access to a user role other than user_r; be able to change their own password, or to have SE Linux log messages that contain their username where applicable.
We now have to define a default security context.
After adding the new user to /etc/selinux/users, a default security context must be assigned to their login sessions. The configuration file for this is /etc/security/default_context so take a look at it. You'll see the following line:
system_r:local_login_t user_r:user_t
When a user logs in locally (i.e. at the console), the
/bin/login program will run in the domain local_login_t and will then assign a user role and domain of user_r and user_t respectively. If the line above was actually
system_r:local_login_t sysadm_r:sysadm_t user_r:user_t
and the user logging in is authorised to enter the sysadm_t domain, then they will land in the sysadm_t domain upon logging in. If not, the user_t domain will be used.
Look at the line
system_r:sshd_t user_r:user_t
This means that for all logins done via ssh, the user will land in the user_r:user_t role:domain.
If you have used useradd to add a new user with the user_r role, then the relabelling will have been taken care of. If however, you've used something like svipw to create the user, or the user role was *not* user_r, then no relabelling has taken place and you will have to run the following command:
find /home/setest -print0 | xargs -0 chcon -h system_u:object_r:user_home_t ;
chcon -h system_u:object_r:user_home_dir_t /home/setest
This command takes all the files in
/home/setest and runs the
chcon (change file security context) command on them. The user's home directory is assigned the type user_home_dir_t and files underneath the user's home directory are assigned the type user_home_t. Sometimes, a process may be granted access to a user's home directory, but not to any files or directories below, hence the two different types.
