SELinux version of sudo

SELinux version of sudo

[Daniel J Walsh]

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

I have been playing around with SELinux a little and was getting 
agravated in always changing roles and
then having to su to root.  What I really needed was the functionality 
of sudo and newrole combined together.
So I am building a version of sudo that will take as a parameter the 
role and or type to execute the program as.
(I would eventually move this to the /etc/sudoers file if I can figure 
out how to use yacc).  I am not sure whether
this is a good idea or not.  It could lead to better security, since I 
believe most users are going to get sick of
changing to sysadm_r and executing su/sudo every time they want to 
change the configuration, so they are likely
to just log in at sysadm_r.  By making it easier for them to do this 
with sudo, they might maintain better security.  

The code seems to work except that I am hitting on a policy error. 
 Basically I don't have a policy that allows
/usr/bin/sudo to exec other applications.   What do I need to change in 
policy to make this happen?
I am getting the following errors in the /var/log/messages

Apr 15 09:13:40 pxe kernel: avc:  denied  { setattr } for  pid=2377 
exe=/usr/bin/sudo path=/var/run/sudo/dwalsh/1 dev=03:02 ino=962189 
scontext=dwalsh:user_r:user_su_t tcontext=dwalsh:object_r:var_run_t 
tclass=file
Apr 15 09:13:50 pxe kernel:
Apr 15 09:13:50 pxe kernel: avc:  denied  { transition } for  pid=2378 
exe=/usr/bin/sudo path=/usr/local/selinux/bin/id dev=03:02 ino=2316548 
scontext=dwalsh:user_r:user_su_t tcontext=dwalsh:sysadm_r:sysadm_t 
tclass=process


Added the following line to policy/file_contexts/program/su.fc
/usr/bin/sudo            system_u:object_r:su_exec_t

Also modified policy/domains/program/newrole.te

--- newrole.te~    2003-03-06 18:13:25.000000000 -0500
+++ newrole.te    2003-04-14 16:26:10.000000000 -0400
@@ -27,7 +27,8 @@
 can_exec(newrole_t, chkpwd_exec_t)
 
 # Allow newrole_t to transition to user domains.
-domain_trans(newrole_t, shell_exec_t, userdomain)
+# domain_trans(newrole_t, shell_exec_t, userdomain)
+domain_trans(newrole_t,{ bin_t sbin_t exec_type }, userdomain)
 domain_trans(newrole_t, ls_exec_t, userdomain)

 # Use capabilities.


[-- Attachment #2: sudo-1.6.6-4.src.rpm --]
[-- Type: application/x-rpm, Size: 344709 bytes --]

Re: SELinux version of sudo

[Stephen Smalley]

On Tue, 2003-04-15 at 10:32, Daniel J Walsh wrote:
> I have been playing around with SELinux a little and was getting 
> agravated in always changing roles and
> then having to su to root.  What I really needed was the functionality 
> of sudo and newrole combined together.

The idea of merging su and newrole has been suggested on the list
previously; please be sure that you have read the earlier discussions
and are aware of the potential risks, e.g. see the thread starting at
http://marc.theaimsgroup.com/?l=selinux&m=102643997004008&w=2, so that
you can avoid common pitfalls.

> Apr 15 09:13:40 pxe kernel: avc:  denied  { setattr } for  pid=2377 
> exe=/usr/bin/sudo path=/var/run/sudo/dwalsh/1 dev=03:02 ino=962189 
> scontext=dwalsh:user_r:user_su_t tcontext=dwalsh:object_r:var_run_t 
> tclass=file

You need to define a type for the /var/run files created by sudo (e.g.
type var_run_sudo_t, sysadmfile, file_type;) and grant permissions to it
via allow rules.  It isn't clear that you should be using the existing
$1_su_t domain for this purpose, unless you are also patching su to
provide this functionality and to ensure that it does not allow
processes with uid 0 to transition to arbitrary SELinux security
contexts.  I'm also not sure whether it will end up being beneficial to
keep this as a derived domain ($1_sudo_t) from the user domain or if you
should just make it a basic domain (sudo_t in a domains/program/sudo.te
file) like newrole.  You will naturally need to use many of the same
attributes and rules as newrole_t for your desired functionality, so
extending newrole_t may be the better choice (or at least duplicating
newrole_t's rules for a new domain).

> Apr 15 09:13:50 pxe kernel:
> Apr 15 09:13:50 pxe kernel: avc:  denied  { transition } for  pid=2378 
> exe=/usr/bin/sudo path=/usr/local/selinux/bin/id dev=03:02 ino=2316548 
> scontext=dwalsh:user_r:user_su_t tcontext=dwalsh:sysadm_r:sysadm_t 
> tclass=process

The domain must have the privrole attribute to transition to a different
role, and $1_su_t does not possess this attribute at present (whereas
newrole_t does).  You also need a domain_trans rule to authorize this
domain transition.  As above, I don't think that you should add these
attributes and rules to $1_su_t unless you are also patching the su
program, and you can copy much of what you need from the newrole_t
domain.  Starting with the newrole_t domain may be a better choice.

> Also modified policy/domains/program/newrole.te
> 
> --- newrole.te~    2003-03-06 18:13:25.000000000 -0500
> +++ newrole.te    2003-04-14 16:26:10.000000000 -0400
> @@ -27,7 +27,8 @@
>  can_exec(newrole_t, chkpwd_exec_t)
>  
>  # Allow newrole_t to transition to user domains.
> -domain_trans(newrole_t, shell_exec_t, userdomain)
> +# domain_trans(newrole_t, shell_exec_t, userdomain)
> +domain_trans(newrole_t,{ bin_t sbin_t exec_type }, userdomain)
>  domain_trans(newrole_t, ls_exec_t, userdomain)
> 
>  # Use capabilities.

This is only useful if you are modifying newrole or putting sudo into
the newrole_t domain.  It serves no purpose if you are using $1_su_t or
a completely new domain.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux version of sudo

[Daniel J Walsh]

[-- Attachment #1: Type: text/plain, Size: 3547 bytes --]

Stephen Smalley wrote:

>On Tue, 2003-04-15 at 10:32, Daniel J Walsh wrote:
>  
>
>>I have been playing around with SELinux a little and was getting 
>>agravated in always changing roles and
>>then having to su to root.  What I really needed was the functionality 
>>of sudo and newrole combined together.
>>    
>>
>
>The idea of merging su and newrole has been suggested on the list
>previously; please be sure that you have read the earlier discussions
>and are aware of the potential risks, e.g. see the thread starting at
>http://marc.theaimsgroup.com/?l=selinux&m=102643997004008&w=2, so that
>you can avoid common pitfalls.
>  
>
I will change the version of sudo to require a password when changing 
context always (including
if root runs sudo).  I think that is the only thing I broke in my 
version of sudo.  I will attempt to make
the changes you suggest in policy and see if it works.  Thanks.  

>  
>
>>Apr 15 09:13:40 pxe kernel: avc:  denied  { setattr } for  pid=2377 
>>exe=/usr/bin/sudo path=/var/run/sudo/dwalsh/1 dev=03:02 ino=962189 
>>scontext=dwalsh:user_r:user_su_t tcontext=dwalsh:object_r:var_run_t 
>>tclass=file
>>    
>>
>
>You need to define a type for the /var/run files created by sudo (e.g.
>type var_run_sudo_t, sysadmfile, file_type;) and grant permissions to it
>via allow rules.  It isn't clear that you should be using the existing
>$1_su_t domain for this purpose, unless you are also patching su to
>provide this functionality and to ensure that it does not allow
>processes with uid 0 to transition to arbitrary SELinux security
>contexts.  I'm also not sure whether it will end up being beneficial to
>keep this as a derived domain ($1_sudo_t) from the user domain or if you
>should just make it a basic domain (sudo_t in a domains/program/sudo.te
>file) like newrole.  You will naturally need to use many of the same
>attributes and rules as newrole_t for your desired functionality, so
>extending newrole_t may be the better choice (or at least duplicating
>newrole_t's rules for a new domain).
>
>  
>
>>Apr 15 09:13:50 pxe kernel:
>>Apr 15 09:13:50 pxe kernel: avc:  denied  { transition } for  pid=2378 
>>exe=/usr/bin/sudo path=/usr/local/selinux/bin/id dev=03:02 ino=2316548 
>>scontext=dwalsh:user_r:user_su_t tcontext=dwalsh:sysadm_r:sysadm_t 
>>tclass=process
>>    
>>
>
>The domain must have the privrole attribute to transition to a different
>role, and $1_su_t does not possess this attribute at present (whereas
>newrole_t does).  You also need a domain_trans rule to authorize this
>domain transition.  As above, I don't think that you should add these
>attributes and rules to $1_su_t unless you are also patching the su
>program, and you can copy much of what you need from the newrole_t
>domain.  Starting with the newrole_t domain may be a better choice.
>
>  
>
>>Also modified policy/domains/program/newrole.te
>>
>>--- newrole.te~    2003-03-06 18:13:25.000000000 -0500
>>+++ newrole.te    2003-04-14 16:26:10.000000000 -0400
>>@@ -27,7 +27,8 @@
>> can_exec(newrole_t, chkpwd_exec_t)
>> 
>> # Allow newrole_t to transition to user domains.
>>-domain_trans(newrole_t, shell_exec_t, userdomain)
>>+# domain_trans(newrole_t, shell_exec_t, userdomain)
>>+domain_trans(newrole_t,{ bin_t sbin_t exec_type }, userdomain)
>> domain_trans(newrole_t, ls_exec_t, userdomain)
>>
>> # Use capabilities.
>>    
>>
>
>This is only useful if you are modifying newrole or putting sudo into
>the newrole_t domain.  It serves no purpose if you are using $1_su_t or
>a completely new domain.
>
>  
>


[-- Attachment #2: Type: text/html, Size: 4347 bytes --]

Re: SELinux version of sudo

[Russell Coker]

On Wed, 16 Apr 2003 03:33, Stephen Smalley wrote:
> The idea of merging su and newrole has been suggested on the list
> previously; please be sure that you have read the earlier discussions
> and are aware of the potential risks, e.g. see the thread starting at
> http://marc.theaimsgroup.com/?l=selinux&m=102643997004008&w=2, so that
> you can avoid common pitfalls.

That thread did not entirely convince me not to do it, but did convince me 
that it would take much of consideration and testing, and that there were 
more important things to spend time on.

Another potential solution to this issue is to allow the administrators in 
question to ssh into an account with UID=0 and then they only need to use 
newrole to get all the privs they need.

> via allow rules.  It isn't clear that you should be using the existing
> $1_su_t domain for this purpose, unless you are also patching su to
> provide this functionality and to ensure that it does not allow

I agree.  The $1_su_t domain only makes sense when you are limiting the 
transitions to a certain set of domains.  If you grant the su/sudo program 
privrole access then there is no benefit in having more than one domain in 
the way it is currently done.

Maybe we should work from the other direction and consider adding setuid() 
support to newrole?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux version of sudo

[Daniel J Walsh]

[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]



Russell Coker wrote:

>On Wed, 16 Apr 2003 03:33, Stephen Smalley wrote:
>  
>
>>The idea of merging su and newrole has been suggested on the list
>>previously; please be sure that you have read the earlier discussions
>>and are aware of the potential risks, e.g. see the thread starting at
>>http://marc.theaimsgroup.com/?l=selinux&m=102643997004008&w=2, so that
>>you can avoid common pitfalls.
>>    
>>
>
>That thread did not entirely convince me not to do it, but did convince me 
>that it would take much of consideration and testing, and that there were 
>more important things to spend time on.
>
>Another potential solution to this issue is to allow the administrators in 
>question to ssh into an account with UID=0 and then they only need to use 
>newrole to get all the privs they need.
>
>  
>
>>via allow rules.  It isn't clear that you should be using the existing
>>$1_su_t domain for this purpose, unless you are also patching su to
>>provide this functionality and to ensure that it does not allow
>>    
>>
>
>I agree.  The $1_su_t domain only makes sense when you are limiting the 
>transitions to a certain set of domains.  If you grant the su/sudo program 
>privrole access then there is no benefit in having more than one domain in 
>the way it is currently done.
>
>Maybe we should work from the other direction and consider adding setuid() 
>support to newrole?
>  
>
I like the idea of combining DAC with MAC using sudo rather than 
su/newrole.  This would allow
an administrator to allow other people run functions that require 
greater access to the system without them
having to have the root password.   IE.  You could allow someone to 
manage the printers database without
having to become root.  Doing all MAC becomes to combersome for this 
type of thing.

>  
>

[-- Attachment #2: Type: text/html, Size: 2437 bytes --]

Re: SELinux version of sudo

[Russell Coker]

On Wed, 16 Apr 2003 20:33, Daniel J Walsh wrote:
> I like the idea of combining DAC with MAC using sudo rather than
> su/newrole.  This would allow
> an administrator to allow other people run functions that require
> greater access to the system without them
> having to have the root password.   IE.  You could allow someone to
> manage the printers database without
> having to become root.  Doing all MAC becomes to combersome for this
> type of thing.

To solve this problem I was thinking of creating some setuid programs that do 
the following:
1)  Check if SE Linux is in enforcing mode and exit if not.
2)  setreuid(0, 0)
3)  Call run_init or other similar program to do the real work once the 
security context has been set.

Domain transition rules (the run_program() macro) would be used to determine 
who is authorised to run the program.

As for authentication, it would use PAM which can probably be used to 
configure whether a password is required for such operations.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.