danwalsh


Dan Walsh's Blog

Got SELinux?


Previous Entry 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)

staff_r role privileges

salimpathan

2008-08-06 05:05 am (UTC)

Hi Dan,

I've a specific requirement...I need to give admin user on a linux FC5 box privileges to shutdown/reboot the machine. By default admin user logs into "staff_r" role...

I don't want to assign "sysadm_r" role to admin user, as this will defeat my purpose.

Thanks in advance.

Cheers !

Re: staff_r role privileges

danwalsh

2008-08-06 12:28 pm (UTC)

FC5 has not been supported for well over a year. You need to upgrade to at least Fedora 8 and preferably Fedora 9 What happens when the user types reboot? What AVC's are you seeing?

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.

Re: staff_r role privileges

danwalsh

2008-08-12 01:32 pm (UTC)

Well there is no Strict policy as of Fedora 9, If you are using confined users:
Why not setup sudo with a rule for the reboot command that has this access rather then adding all of these privs to staff_t

admin ALL=(ALL) TYPE=unconfined_t ROLE=unconfined_r /sbin/reboot
or
admin ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r /sbin/reboot

This way you are relying on sudo as the only mechanism for getting access to those privs.

From a minimum security point of view you could design a user admin role whose only privs is the ability to reboot. reboot_t and reboot_r.

If you do any of the above you will also need to modify the staff_u user to include the role required for transition

semanage user -m -R"staff_r sysadm_r" staff_u for example

Or create a new user admin_u

# semanage user -m -P user -R"staff_r sysadm_r" -rs0-s0:c0.c1023 admin_u
# semanage login -m -s admin_u admin



Re: staff_r role privileges

salimpathan

2008-08-13 09:38 am (UTC)

Hi Dan,

I've created admin_u selinux user, with staff_r and sysadm_r roles assigned:

[root@xyz ~]# semanage login -l

Login Name SELinux User MLS/MCS Range

__default__ user_u s0
admin admin_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

admin_u staff s0 s0-s0:c0.c1023 sysadm_r staff_r
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 set up sudoers as follows for admin user:-

ADMIN ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r /sbin/reboot


Now when I issue reboot command:-

[admin@xyz ~]$ id -Z
admin_u:staff_r:staff_t:s0
[admin@xyz ~]$ sudo /sbin/reboot

A lot of avc message were generated. When I used audit2allow utility on these messages I got following "type-enforcement" file :-

module test 1.0;

require {
type sysadm_t;
type staff_t;
type sysadm_devpts_t;
type staff_devpts_t;
type staff_tty_device_t;
type tty_device_t;
type sysadm_tty_device_t;
type pam_var_run_t;
type usr_t;
type proc_t;
type kernel_t;
class process { siginh transition setexec noatsecure rlimitinh };
class capability { setuid sys_resource dac_override };
class key search;
class chr_file { relabelfrom relabelto getattr write };
class file { read getattr write create entrypoint unlink execute execute_no_trans };
class dir { write remove_name add_name search getattr };
}

#============= staff_t ==============
allow staff_t kernel_t:key search;
allow staff_t self:capability { setuid sys_resource dac_override };
allow staff_t staff_tty_device_t:chr_file { relabelfrom relabelto };
allow staff_t tty_device_t:chr_file { write getattr };
allow staff_t sysadm_tty_device_t:chr_file { relabelto relabelfrom getattr };
allow staff_t staff_devpts_t:chr_file { relabelto relabelfrom };
allow staff_t sysadm_devpts_t:chr_file { relabelto relabelfrom};
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 };
allow staff_t self:process setexec;
allow staff_t sysadm_t:process { siginh rlimitinh transition noatsecure };

#============= sysadm_t ==============
allow sysadm_t sysadm_devpts_t:chr_file { relabelto relabelfrom };
allow sysadm_t usr_t:file { entrypoint execute execute_no_trans } ;


Still admin user is not able to reboot the machine. Following avc message keeps on coming:-

Aug 13 14:39:55 xyz kernel: audit(1218618595.898:5): avc: denied { transition } for pid=2058 comm="sudo" path="/usr/local/libexec/sesh" dev=hda9 ino=96888 scontext=admin_u:staff_r:staff_t:s0 tcontext=admin_u:sysadm_r:sysadm_t:s0 tclass=process


This avc is translated into :-

allow staff_t sysadm_t:process transition;

I've already allowed this in last line of "staff_t" rules in .te file above.

Is there something I'm missing???


Thanks,Regards



Re: staff_r role privileges

danwalsh

2008-08-13 03:16 pm (UTC)

I think you have a problem in your policy. I tried what you explained above on Fedora 9 and it worked fine.

I think you might be getting a constraint violation

Run the transition rule through audit2why and I think you will see what the problem is.

Fedora has these calls in it
userdom_role_change_template(staff, sysadm)
userdom_dontaudit_use_sysadm_terms(staff_t)

Re: staff_r role privileges

salimpathan

2008-08-14 12:34 pm (UTC)

Added following lines to my .te file :
userdom_role_change_template(staff, sysadm)
userdom_dontaudit_use_sysadm_terms(staff_t)

But when tried to make module, got following error:

[root@xyz ~]# checkmodule -M -m test.te -o test.mod
checkmodule: loading policy configuration from test.te
(unknown source)::ERROR 'syntax error' at token 'userdom_role_change_template' on line 42:
userdom_role_change_template(staff, sysadm)

checkmodule: error(s) encountered while parsing configuration

[root@xyz ~]# checkmodule -V
Module versions 4-6

I think checkmodule policy compiler is not recognizing "userdom_role_change_template".


any ideas why????

Re: staff_r role privileges

danwalsh

2008-08-14 12:40 pm (UTC)

You don't have the interface defined.

template(`userdom_role_change_template',`
gen_require(`
role $1_r, $2_r;
type $1_t, $2_t;
type $1_devpts_t, $2_devpts_t;
type $1_tty_device_t, $2_tty_device_t;
')

allow $1_r $2_r;
type_change $2_t $1_devpts_t:chr_file $2_devpts_t;
type_change $2_t $1_tty_device_t:chr_file $2_tty_device_t;
# avoid annoying messages on terminal hangup
dontaudit $1_t { $2_devpts_t $2_tty_device_t }:chr_file ioctl;
')

Re: staff_r role privileges

salimpathan

2008-08-18 09:23 am (UTC)

Aug 13 14:39:55 xyz kernel: audit(1218618595.898:5): avc: denied { transition } for pid=2058 comm="sudo" path="/usr/local/libexec/sesh" dev=hda9 ino=96888 scontext=admin_u:staff_r:staff_t:s0 tcontext=admin_u:sysadm_r:sysadm_t:s0 tclass=process

audit2why on above avc gives:-

Was caused by:
Constraint violation.
Check policy/constraints.
Typically, you just need to add a type attribute to the domain to satisfy the constraint.


With correct interface file defined I added

userdom_role_change_template(staff, sysadm)
userdom_dontaudit_use_sysadm_terms(staff_t)

to my .te file and loaded the resultant policy.

Still I don't have any success... When I issue "sudo /sbin/reboot" as admin user, the terminal logout happens..(but no reboot!)

Re: staff_r role privileges

danwalsh

2008-08-18 10:12 am (UTC)

Are you seeing an additional AVC? Do you see anything in the log files?

Re: staff_r role privileges

salimpathan

2008-08-18 10:38 am (UTC)

Hi Dan,

The same avc is still coming: -

Aug 18 15:56:34 xyz kernel: audit(1219055194.331:6): avc: denied { transition } for pid=2128 comm="sudo" path="/usr/local/libexec/sesh" dev=hda9 ino=96888 scontext=admin_u:staff_r:staff_t:s0 tcontext=admin_u:sysadm_r:sysadm_t:s0 tclass=process

I'm wondering why the following type-enforcement rule is still not working????

allow staff_t sysadm_t:process { siginh rlimitinh transition noatsecure };





Re: staff_r role privileges

danwalsh

2008-08-18 11:28 am (UTC)

Well there is something wrong with your policy.

I just setup everything you are describing in Fedora 10 and it worked correctly.

I created an admin_u account.

# semanage user -a -R"staff_r sysadm_r" admin_u
# useradd -Z admin_u admin
# cp /etc/selinux/context/users/staff_u /etc/selinux/contexts/users/admin_u
# visudo
admin ALL=(ALL) ROLE=sysadm_r TYPE=sysadm_t ALL

Login as admin
> id -Z
admin_u:staff_r:staff_t:s0
> sudo sh
[sudo] password for admin:
# id -Z
admin_u:sysadm_r:sysadm_t:s0

I would look at your definition of sysadm and see if it is missing some attribute. It might not see sysadm_t as a domain?

Since this is not a RHEL or Fedora policy please bring up discussion on the NSA list

You are viewing danwalsh