Re: SELinux version of sudo

[Daniel J Walsh <dwalsh@redhat.com>]

[-- 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 --]