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. Firstly though, we will discuss some wrapper programs for common user account related functions.
We've already covered using the spasswd command to change your own password, and the sadminpasswd command for a user in the sysadm_t domain to change other user passwords.
schsh is a wrapper for the chsh (change login shell) program. It does not let you supply any paramters. You will be prompted as follows:
faye@kaos:~$ schsh
Password:
Changing the login shell for faye
Enter the new value, or press return for the default
Login Shell [/bin/bash]:
faye@kaos:~$
schfn is a wrapper for the chfn (change username and information) program. schfn also does not allow you to supply parameters and prompts you as follows:
faye@kaos:~$ schfn
Password:
Changing the user information for faye
Enter the new value, or press ENTER for the default
Full Name: Faye Coker
Room Number []:
Work Phone []:
Home Phone []:
faye@kaos:~$
faye@kaos:~$
svipw is a wrapper for the vipw (edit password file) command. Functionality is the same as the regular vipw. You can only run this command when in the sysadm_t domain.
The suseradd command is a wrapper for the useradd command. It also provides transitional rules to assign the correct types to files, as well as allowing write access to /etc/shadow when the new user is added. Check the man page for useradd for the proper syntax. Note that suseradd only works for user_r (i.e. it is only used when creating a user who will have the user_r role).
We'll now create our new user. Let's call him setest.
Switch to the sysadm_r:sysadm_t role:domain. Now use the suseradd command to add user setest:
root@kaos:~# id uid=0(root) gid=0(root) groups=0(root) context=faye:sysadm_r:sysadm_t sid=398Run 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:~# suseradd -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:~# sadminpasswd setest Enter new UNIX password: Retype new UNIX password: passwd: password updated successfullySo the setest user has now been added. The suseradd command allows the identity user_u to take effect. The user_u identity is only allowed to have access to the user_r role. But if a user has an identity of user_u they won't be able to change their own password. Recall that in order to change your password, your Unix username and SE Linux identity must match. So if we have an identity of user_u and a Unix account name of setest, the two won't match.
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 loadThis 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_tWhen 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_tand 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_tThis means that for all logins done via ssh, the user will land in the user_r:user_t role:domain.
If you have used suseradd 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 | xargs chcon -h system_u:object_r:user_home_t ; chcon -h system_u:object_r:user_home_dir_t /home/setestThis 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.