Last month, I wrote about confining the user with SELinux. I explained that–as of Fedora 9–SELinux supports the concept of the confined user and comes with 5 confined user types defined.

  • guest_t – Terminal login, nosetuid, nonetwork, noxwindows, noexec in homedir
  • xguest_t – X Windows Login and terminal login, nosetuid, nonetwork, noexec in homedir
  • user_t – X Windows Login and terminal login, nosetuid, noexec in homedir
  • staff_t – X Windows Login and terminal login, nosetuid except sudo
  • unconfined_t – Full login, able to run with almost all privs as with SELinux disabled.
These confined users are a great starting point, but what if you want to create a confined user with different privileges?

I want to create a limited privilege terminal login user with the ability to send mail and read/write files in the /maildir directory.

My son Timothy uses his confined xguest account, but is not happy because he wants to communicate with his friends using AOL.
Fedora 9 has the solution. The SELinux management environment (system-config-selinux) has been updated and includes the ability to build customized SELinux policy modules for the confinement of users.

Remember, this tool is just a wizard–it helps create a framework for building policy. You can then use tools like audit2allow or the package eclipse-slide for further editing of the policy. Thiswill give you a good head start.

In the toolbar panel select:

System->Administration->SELinux Management

This starts system-config-selinux.



Select Policy Module and then Select the New button.



This will start the policy template generator (polgengui).



Click Forward.



As you can see, this screen has been enhanced to allow the creation of policy for confined users as well as confined applications. Writing policy for confined applications was described in a previous article.

The second column, Login Users, allows you to build policy modules that either customize existing user roles or create brand new roles. Selecting Existing User Roles allows you to build policy to change one of the default user types defined above. (guest, xguest, user, staff). Select one of the other radio buttons to define a new user role, based off of the 4 default user roles.

  • Minimal Terminal User Role == guest_t
  • Minimal X Windows User Role == xguest_t
  • User Role == user_t
  • Admin Role == staff_t
The final column, Root Users, allows you to define a user type that other user types can transition to when they are running as root. For example you could define a root role, dbadm, to administer the mysql database. You could set up the staff role to transition to this role using sudo.

I want to create a limited privilege terminal login user with the ability to send mail and read/write files in the /maildir directory?
In order to answer this question, we want to create a new Minimal Terminal User Role called mailuser.

Select Minimal Terminal User Role, and press Forward.





This screen displays a list of confined domains to which this role might transition. For example, if you wanted the mailuser to transition to the ethereal domain you would select this now. Since we do not want any transitions we will just hit forward.



This screen allows you to select other roles to which the current role can transition. This is where you would define the transition to dbadm from staff role described above. We will just hit Forward.



This screen allows you to select ports that the user can listen to. If the confined user was going to run a network server you could select the ports here. We will just select Forward.



Finally, we get to a screen which defines the ports the confined user can connect to. We will select the smtp port #25 and then go forward again.



This screen allows you to define a boolean. If you wanted to allow our confined user to connect to the mail port, only if the “allow_mailuser_sendmail” boolean is set, we could create the boolean here. We are not going to do this so select forward.



This screen allows us to select the directory to write the policy framework into. The directory must already exist.



This final screen tells you which files you are about to create. Press Apply.



The tool will create the following policy:

#vi /root/mailuser/mailuser.te policy_module(mailuser,1.0.0) ######################################## # # Declarations # userdom_restricted_user_template(mailuser)This one interface defines all the interaction of a guest user.

####################################### # # mailuser local policy # sysnet_dns_name_resolve(mailuser_t) corenet_all_recvfrom_unlabeled(mailuser_t) allow mailuser_t self:tcp_socket create_stream_socket_perms; corenet_tcp_sendrecv_all_if(mailuser_t) corenet_tcp_sendrecv_all_nodes(mailuser_t) corenet_tcp_sendrecv_all_ports(mailuser_t) corenet_tcp_connect_smtp_port(mailuser_t)These interfaces allow the mailuser_t to communicate with the smtp ports. Also, the policy generation tool added an interface to resolve host names. We now have enough policy to allow a mailuser_t to login to a machine and connect to a mail server, but not to read/write files to /maildir. This tool is just a framework-generating tool, not a policy editor. We will need to write policy for handing the /maildir directory ourselves. Since we want a directory that the mailuser can read/write to, we need to define a new type, mailuser_rw_t, then we need to tell the system that this is a type that affects files.

type mailuser_rw_t;file_type(mailuser_rw_t)We also need to allow mailuser_t to manage files and directories of this type:

manage_dirs_pattern(mailuser_t, mailuser_rw_t, mailuser_rw_t)manage_files_pattern(mailuser_t, mailuser_rw_t, mailuser_rw_t)We are done with the mailuser.te file.

Now, we want to define the file context in the mailuser.fc file:

# vi /root/mailuser/mailuser.fc/var/maildir(/.*)? gen_context(system_u:object_r:mailuser_rw_t,s0)W e use regular expressions to define the path.

Now we can run the shell script to compile the policy and install it to the test system.

# sh mailuser.shBuilding and Loading Policy+ make -f /usr/share/selinux/devel/MakefileCompiling targeted mailuser module/usr/bin/checkmodule: loading policy configuration from tmp/mailuser.tmp/usr/bin/checkmodule: policy configuration loaded/usr/bin/checkmodule: writing binary representation (version to tmp/mailuser.modCreating targeted mailuser.pp policy packagerm tmp/mailuser.mod.fc tmp/mailuser.mod+ /usr/sbin/semodule -i mailuser.pp+ /usr/sbin/semanage user -a -R mailuser_r mailuser_uAt this point we have a new SELinx user mailuser_u installed on the machine. We want to assign a linux user to this type:

# semanage login -a -s mailuser_u dwalshWe also want to create the directories /var/maildir:

# mkdir /var/maildir# restorecon /var/maildir# chown dwalsh:dwalsh /maildirNow dwalsh can log in and use the /var/maildir directories.

But what about my son and his friends on AOL?

My son Timothy uses his confined xguest account, but is not happy because he wants to communicate with his friends using AOL.
I want to confine my son’s account so that only Firefox can talk to internet ports–but I want to allow his account to communicate with AIM/AOL. I can customize the xguest account and add this access.

Back at system-config-selinux I select New to create a new policy module.



I click forward through the intro screen to get to the policy module selection screen.



I want to modify an existing user role, so I click on Existing User Roles and then click forward.



The next box shows me the list of all exising user roles. Select xguest. The tool will add “my” to the policy name and create policy files named myxguest.

Click forward through the next couple of screens, until you reach the network connect screen.



Add the AOL Ports as a comma separated list, then click forward until the end.



Now take a look at the myxguest.te file that was created:

policy_module(myxguest,1.0.0)gen_require(` type xguest_t, xguest_devpts_t, xguest_tty_device_t; role xguest_r;')##################################### ##### xguest customized policy#sysnet_dns_name_resolve(xguest_t)corenet_ all_recvfrom_unlabeled(xguest_t)allow xguest_t self:tcp_socket create_stream_socket_perms;corenet_tcp_sendrecv_ all_if(xguest_t)corenet_tcp_sendrecv_all_nodes(x guest_t)corenet_tcp_sendrecv_all_ports(xguest_t) corenet_tcp_connect_aol_port(xguest_t)allow xguest_t self:udp_socket { create_socket_perms listen };corenet_udp_sendrecv_all_if(xguest_t)corenet_u dp_sendrecv_all_nodes(xguest_t)corenet_udp_sendr ecv_all_ports(xguest_t)The tool added the AOL ports and the ability to resolve their hosts.

Compile to install the new policy like so:

sh myxguest.shSince I had previously set my son up to log in as xguest_u, no user management would need to be done. He can now use AOL Instant Messages in a secure environment.

If I had not set up his account I would need to execute:

# semodule login -a -s xguest_u twalshor

usermod -Z xguest_u twalshThese examples show that it is fairly simple to extend SELinux confined users. If you need more advanced features, you can use system-config-selinux to build the framework and then use audit2allow or eclipse-slide to do further policy generation.

Next time, we will cover confinement of the root user.




More...