Stephen Smalley wrote:

>On Wed, 2003-04-30 at 15:06, Daniel J Walsh wrote:
>  
>
>>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?
>>    
>>
>
>No, I'm talking about your allow rule for directory access.  An *exec_t
>type should never be applied to a directory; it is supposed to be the
>type of an entrypoint executable for a domain.  For allowing sudo to
>search directories containing binaries, you should just be able to
>enumerate the set of directory types, e.g. bin_t, sbin_t, lib_t, etc_t,
>etc.  There is no valid reason to use file_type.  Just define a macro in
>global macros that enumerates the list of system directories with
>authorized programs, and use that macro in your rule.
>  
>
Ok now I understand.  I can just go with the directory commands from  
can_exec_any rule.
    allow $1 { bin_t sbin_t lib_t etc_t }:dir r_dir_perms;
    allow $1 { bin_t sbin_t }:lnk_file read;

in sudo.te which would satisfy my needs.  Probably do not need lib_t or 
etc_t.
Is that what you had in mind?

>  
>
>>So sudo needs all the rights that su/newrole has for a particular
>>    
>>
>role.  
>
>Right, but we would ultimately like to see the roles pruned down to
>least privilege, e.g. you don't really want sysadm_t running arbitrary
>executables directly, as that can easily lead to a compromise.
>
>  
>
>>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?
>>    
>>
>
>In that case, the program shouldn't be accessing the terminal, and you
>should redirect input and/or output to a file if the program wants to
>read any input or write any output.
>
>  
>
Not exactly an ideal behaviour.  

Consider
sudo -r sysadm_r /bin/sh
would be broken by this.

This is an interesting problem in that two processes want to use the 
terminal at the same time, each with a different security context.  So 
if one is running and is suspended, do we change the security context of 
the terminal to the now running terminal?  Could we do that?

Dan