Log in

No account? Create an account

Previous Entry Share Next Entry
I need Guinea pigs...

One  of the problems I face, is trying to convince people to use new security products.   They say, "Sure just don't break anything".  The problem is I need Guinea pigs to find out what I break.  In the case of confining the user, I have a problem.  I believe this can be a big security step forward, but how do I get people to use it, if it is not fully tested out?  How do I test it out without getting people to use it?

Now I have taken some involuntary test subjects like my wife, and set her up with a confined user account and worked with her to fix problems in xguest.  I have also taken the Jonas Salk approach and tested on my self.  I have been running as the staff_u user for the entire run of Rawhide since Fedora 8.

So I am now beginning to Beg co-workers to try it out.  As people start to install Fedora 9, I want them to try out confined users.  The simplest user for an engineer to try is staff_u with a transition to unconfined_t when you become root.

This is how I set this up.

First you need to modify the SELinux user record to allow it to reach the unconfined_r.  You also want to allow it to reach the system_r since you might be restarting services which need to run as system_r.  The command is a little ugly but follow along

# semanage user -m -R"staff_r unconfined_r system_r" staff_u
This tells the system to modify the staff_u user and allow it to reach the staff_r, unconfined_r and system_r roles.

Now we need to modify the login account to login as the staff_u SELinux user.

We can either change the default, so all users by default will login as the staff_u user.

# semanage login -m -s staff_u __default__

Or we can add a record just for my Linux user "dwalsh"

# semanage login -a -s staff_u -r s0-s0:c0.c1023 dwalsh

Finally I want to setup a sudo to allow me to transition from staff_t to unconfined_t when running commands using sudo.

Add a record like to following using visudo

dwalsh  ALL=(ALL) TYPE=unconfined_t ROLE=unconfined_r   ALL

Now logout and log back in and you should be running as staff_u:staff_r:staff_t,

Execute "sudo sh" and you should be running as staff_u:unconfined_r:unconfined_t.

One caveat for this environment is currently userhelper apps will not work (system-config-*) when executed from staff_t,  But you can run them from the sudo root account.

What does this buy you?  While running in staff_t you will not be allowed to run any setuid application that is not confined.  So if somehow you were tricked into running a setuid app on your machine to become root, it will fail.  You will automatically transition to nsplugin so  your firefox will have confinement.  The ONLY way to become root/unconfined_t is through sudo, which is a well studied application.  If you run attempt to run su, you will be denied.

So do I have any volunteers????

I am fixing a typo in the command above sorry about reposting.

Also if you want to reverse the changes listed above

You could execute

semanage login -d dwalsh

Will remove the record and put dwalsh back to the default.

# semanage login -m -s unconfined_u __default__

Would set the default logins to be unconfined_u (the default)

  • 1
I've been experimenting with this transition for a couple of years. I'm currently running Fedora 10 with selinux in enforcing/targeted mode. As an interim step, I have been using sudo to switch to a lower privileged user and run firefox. Recently, to limit the id further, I have set the id to selinux user user_u. If you login as that user it has the expected context user_u:user_r:user_t. But, I just discovered that as of Fedora 5, sudo doesn't switch the context to the user it is running the command as. It keeps the original context.

Is there some way to get selinux to switch the context when you run sudo such as with pam or a selinux policy? I know sudo will let you set the role and type if allowed, but not the selinux user.

If you read the notes in this chain, it explains how to set up sudoers to transition to different domains, using the ROLE= and TYPE= options.

I was just wondering if there was any way to fully switch to the new user's context. As I stated above, I'm aware of the role and type options.

Anyway I set up as describe in this chain. I added user_r to staff_u. Again I'm using Fedora 10 with selinux in enforcing/targeted mode. When I run sudo with out specifying the role and type it works fine. When I try the following command:

sudo -u firefox -r user_r -t user_t /usr/bin/id

I get these errors:

sudo: unable to open /dev/pts/0: Permission denied
sudo: unable to setup tty context for staff_u:user_r:user_t:s0: Permission denied

For some reason it is trying to set the context of tty device to that of the user. The permissions and context of /dev/pts/0 is as it should be:

crw--w---- dcove tty staff_u:object_r:staff_devpts_t:s0 0

I tried sudo from a console window with the same result. I tried setting role and type in the sudoers file instead of command line with the same result. Is this a known issue in Fedora 10? If not, do you have any suggestions on how to fix this? Thanks.

Please download selinux-policy-3.5.13-34.fc10 from koji to see if that solves your problem.

THe policy was not allowing staff_t->user_t transitions.

Thank you for your assistance. This weekend, I tried installing selinux-policy-3.5.13-34.fc10 and selinux-policy-targeted-3.5.13-34.fc10. It didn't change the behavior of sudo. It is still failing with the same errors when trying to transition from staff_t->user_t.

BTW, whether you successfully sudo with the same context or unsuccessfully sudo trying to transition from staff_t to user_t, the same four entries are in audit.log all with res=success. They are CRED_ACQ, USER_START, USER_END, and USER_CMD. There are no failures in audit.log

Looks like a bug in sudo, this does not work in permissive mode, if I remove the changing of the context it works.

The problem is sudo is changing the real and effective user id before it tries to set the terminal context, so it basically drops privs before running the SELinux code. And the user is not allowed to modify the attributes of the terminal.

Thank you very much. I'll keep an eye out for an update to sudo that fixes this. But, shouldn't it be trying to set the tty context to staff_u:object_r:user_tty_device_t instead of staff_u:user_r:user_t? Just curious.

it is trying to set the context to staff_u:object_r:user_tty_device_t. staff_u:user_r:user_t is the context of the process.

  • 1