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