How do I make sudo "trusted"?

[Stephen Smalley]

On Fri, 2004-03-12 at 01:39, Aleksey Nogin wrote:
> Well, sudo + sudoers does authenticate the "I am somebody who can act on 
> behalf of the target user", why is this insufficient?

It might be sufficient (if you are willing to fully trust sudo and
/etc/sudoers), although it would mean that you would lose the
preservation of the SELinux user identity for its auditing on kernel
operations.  Your counterargument is presumably that sudo will log
sufficiently (but again that presumes trust in sudo, and doesn't provide
auditing on the kernel operations).

To do this, you would need to patch sudo to set the SELinux user
identity to the new value; you cannot just use pam_selinux as is done
for su, as the pam user identity is set to the old identity since that
is the identity that is authenticated.

> Do you expect everybody who are used to doing things via sudo (a lot of 
> places where more than one user has admin access have policies insisting 
> on sudo - in particular because sudo will log everything) to be willing 
> to figure this out? Why is this information (e.g. "user x is allowed to 
> act as root when re-authenticated") has to be listed in _two_ separate 
> places (sudoers and policies)?

SELinux policy doesn't specify who is allowed to act as Linux uid 0 when
re-authenticated.  It does specify what roles you can enter.  Whether or
not sudo should change the SELinux user identity is certainly open to
debate; we (NSA) didn't try integrating SELinux with sudo, so this is
something that RH has to work out.

> > In order to have sudo safely change the SELinux user identity (to root),
> > you would need another mechanism for specifying what roles/domains are
> > permitted to the calling user, e.g. new fields in /etc/sudoers. 
> 
> That would be the best solution IMHO. Should I file a Bugzilla RFE?

I'm in favor of being able to specify roles and domains in /etc/sudoers
regardless of whether sudo changes the SELinux user identity.

> > Even
> > then, you still need to start from staff_r in order to reach sysadm_r;
> > the policy doesn't allow user_r to transition to sysadm_r (if SELinux is
> > in enforcing mode).
> 
> Not sure I understand what you are saying - it works with su, why can't 
> it be made to work with sudo?

It isn't permitted in the upstream policy, just the RH policy.  user_r
is more confined in the upstream policy.

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency