danwalsh


Dan Walsh's Blog

Got SELinux?


Previous Entry Add to Memories Share Next Entry
I need Guinea pigs...
danwalsh
REPOSTING WITH SOME FIXES

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)

Re: staff_r role privileges

salimpathan

2008-08-12 09:29 am (UTC)

Hi Dan,

To be very precise I'm working on: Scientific Linux SL release 5.1(2.6.18-53.1.4.el5), I think SELinux implementation in this release is equivalent to FC9 (In earlier post I mistyped FC9 as FC5, apology for that...)

I'm running SELinux STRICT policy in enforcing mode. Semanage command output is as follows:-

[root@xyz ~]# semanage login -l

Login Name SELinux User MLS/MCS Range

__default__ user_u s0
admin staff_u s0
root root s0-s0:c0.c1023
system_u system_u s0-s0:c0.c1023


[root@xyz ~]# semanage user -l

Labeling MLS/ MLS/
SELinux User Prefix MCS Level MCS Range SELinux Roles

root sysadm s0 s0-s0:c0.c1023 system_r sysadm_r staff_r
staff_u staff s0 s0-s0:c0.c1023 staff_r
sysadm_u sysadm s0 s0-s0:c0.c1023 sysadm_r
system_u user s0 s0-s0:c0.c1023 system_r
user_u user s0 s0 user_r

I've put 'admin' user in sudoers list and allowed him to reboot, shutdown the machine.

OK when I start executing the command "sudo /sbin/reboot" I got lot of avc's. When I used audit2allow utility on these messages I got following "type-enforcement" file :-

module test 1.0;

require {
type staff_t;
type root_t;
type sysadm_home_t;
type staff_devpts_t;
type init_exec_t;
type var_run_t;
type pam_var_run_t;
type kernel_t;
type pam_var_run_t;
type sysadm_devpts_t;
type initctl_t;
class system syslog_mod;
class chr_file { relabelfrom relabelto setattr };
class capability { setuid sys_resource dac_override };
class fifo_file write;
class key search;
class file { rename setattr read create execute_no_trans execute write relabelfrom getattr relabelto unlink append };
class dir { read write search getattr setattr remove_name add_name };
}

#============= staff_t ==============
allow staff_t init_exec_t:file { read execute_no_trans execute };
allow staff_t initctl_t:fifo_file write;
allow staff_t kernel_t:key search;
allow staff_t kernel_t:system syslog_mod;
allow staff_t pam_var_run_t:dir { write setattr };
allow staff_t root_t:dir { write add_name };
allow staff_t root_t:file { read write create };
allow staff_t self:capability { setuid sys_resource dac_override };
allow staff_t staff_devpts_t:chr_file relabelfrom;
allow staff_t sysadm_devpts_t:chr_file relabelto;
allow staff_t sysadm_home_t:file { read write append };
allow staff_t var_run_t:dir { write remove_name add_name };
allow staff_t var_run_t:file { write read create unlink };
allow staff_t pam_var_run_t:dir { write remove_name add_name search getattr };
allow staff_t pam_var_run_t:file { write read create unlink };

On loading this file as policy using semodule, I'm able to reboot the machine from admin account. Now the question is: Is the above mentioned 'allow' rules cause some kind of security threat/flaw??? as lot of things are now allowed for "staff_t" type...for example: allow staff_t root_t:dir { write add_name };

How to make sure that user 'admin' in 'staff_r' role is not going to harm my machine in any way???

Your help will be highly appreciated.

Thanks in advance.

No HTML allowed in subject

  
 
   
 

(will be screened)

You are viewing danwalsh