LSPP Requirement Specifically for Auditing

[Stephen Smalley]

On Mon, 2005-10-03 at 10:22 -0400, Steve Grubb wrote:
> Newrole should be a small enough program that it can be analyzed for any 
> problems. Other programs that do this are also suid root.:
> 
> [root at discovery ~]# ls -l /usr/bin/newgrp
> -rwsr-xr-x  1 root root 74458 Sep 27 04:14 /usr/bin/newgrp
> 
> Are you thinking of some problem that would prevent this?
> 
> I'm worried that the helper program approach could be easily abused.

It is simply a matter of minimizing the trust burden, for the sake of
improved assurance.  It seems wrong to have to make a previously
non-suid program suid just for the sake of adding audit functionality to
it, thereby potentially exposing the system to greater risk because of
the greater privilege with which the entire program code runs.

I understand that the trust boundary would be weak for such a helper, as
it would just (I suppose) be taking an audit message provided by the
caller and sending it off.  But one could certainly restrict execute
access to it via DAC and via policy, along with putting it into its own
domain.

Note that newrole presently lacks its own domain in targeted policy,
unlike strict policy, so if you do end up making it suid in Fedora, we
should likely put it into its own domain in the targeted policy there
(possibly needed anyway for MCS level changes) as well as auditing the
code.

-- 
Stephen Smalley
National Security Agency