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)

I'll be doing this after F9 ships.

I probably would. But I got very little knowledge of SELinux and had not used to it yet. Besides, updating F8 to F9 Rawhide killed any possibility to login to my home computing with SELinux turned on. So I end up with keeping it off until F9 is releases.

Will I be able to login as root from SSH?? Fedora by default doesn't come with "sudo" and "su" is denied so how do I get my root permissions?

I'll be more than happy to learn a little about SE-Linux :)

Fedora comes with sudoe

jds2001

2008-04-26 08:04 pm (UTC)

the default installation of Fedora *does* ship with sudo. However, it's not configured. Dan gave fairly specific instructions on how to configure it to work in this setup.

As someone who tests Fedora and lives on the bleeding edge, and really doesn't care if my machine works or not (very few folks can say that - obviously not my primary machine!) I'll probably set this up, even having no knowledge of SELinux to date (except how to turn it off :P). It will be a fun learning experience for me, and expect tons of questions at the Summit, Dan! :)

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

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.

Hi,

What is the best practice to manage selinux context for SSL sertificates. I usually prefer to use the same certificate/key for all applications: dovecot, sendmail, apache, cups to name a few. Do I have to have separate copies for each daemon or there is a common context exists for this purpoces?

Thanks,
Vadym

Re: shared certificate

danwalsh

2008-12-29 03:21 pm (UTC)

cert_t, I am not sure if all those domains can read cert_t, but if one can not it is a bug.

The /etc/pki directory has this label.

You are viewing danwalsh