Stephen Smalley wrote:

>On Wed, 2003-04-30 at 11:42, Daniel J Walsh wrote:
>  
>
>>I have a hard time with the previous two.  Just seems to me SELinux
>>needs some sort
>>of dontallow functionality to handle these situation.  Otherwise every
>>time I add a policy 
>>that has a somewhat global effect on files/dir, I need to change the
>>all the file/directory attributes 
>>in the policy.  Has this been discussed previously?
>>    
>>
>
>True.  The problem is more severe for exec_type than for the directory
>access; IMHO, it isn't too much to ask you to enumerate the major
>directory types in which binaries to be executed by sudo might live, and
>most (all?) of those types should be part of the basic policy
>definition, not package-specific, e.g. bin_t, sbin_t, etc.  You don't
>even need to define an attribute for that purpose; you can just list
>them in your allow rule, or pull them from a macro definition added to
>the global macros.
>  
>
I am still not sure I can do this.  Are you are stating that I would 
have to have an allow rule for
each *exec_t?  Just searching domains/programs I found  > 100 of these 
in the default policy.  
Maybe we are at odds with what sudo can do.  I consider sudo to be a 
shortcut from doing
su,newrole,COMMAND.  So sudo needs all the rights that su/newrole has 
for a particular role.  
Now you might be against this because of the security ramifications, 
which is ok.  But if users
are going to use a SELinux system they are going to expect this behaviour.

>  
>
>>This is a problem since with Sudo you are sharing the same terminal
>>between the process that rand sudo
>>and the sudo process.  So if you change the privs of the terminal one
>>process or the other could have 
>>more privs.  I would prefer to leave the terminal with the current
>>privs (Usually lower) and make the 
>>application run by sudo change the terminal privs if it has to. 
>>(probably seldom).  Any other ideas?
>>    
>>
>
>I'm not clear as to why you can't implement something akin to what
>newrole does.  Otherwise, what prevents another process of lower
>privilege from arbitrarily accessing the privileged process' terminal?
>You can't rely on the DAC protections.
>
>  
>
Ok I just went back and read the code again and it looks like I can 
implement the terminal stuff.
There is a -b option on the sudo command that allows sudo to run in 
background.  Or using job
control you could run the command in background.

sudo -r sysadm_r /usr/bin/PROGRAM &

So what happens to control over the terminal in this situation?

Dan