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