[redhat-lspp] Re: newrole, UID change, etc

Russell Coker rcoker at redhat.com
Fri Apr 21 15:41:02 UTC 2006


On Fri, 2006-04-21 at 06:09 -0400, Daniel J Walsh wrote:
> Russell Coker wrote:
> > On Thu, 2006-04-20 at 08:59 -0400, Daniel J Walsh wrote:
> >> I am real concerned about the selinux=0 and enforcing=0 case on 
> >> newrole.  Since newrole is prompting for the users password, and not the 
> >> root password, we need to be very careful if newrole can change UID.
> >>     
> >
> > In terms of selinux=0, my plan was to disable such use of newrole in
> > that case.  There is no benefit to using newrole when SE Linux is
> > disabled.  Also we could have an option in the policy to determine
> > whether newrole should permit changing the UID so that even if a user is
> > inappropriately granted the access that newrole bases it's checks on
> > then the newrole program would check the permissions for it's own domain
> > too (usually newrole_t but policy could support running in other
> > domains).
> >
> > For enforcing=0 the case is similar to that of sudo.  Misconfiguring a
> > system such that newrole would permit inappropriate UID changes would be
> > no different from the same misconfiguration of sudo (changing to root
> > while only using your personal password is one of the most common
> > reasons for using it).
> >
> Except that newrole can be run by any user including guest accounts, 

sudo may also be run by any user including guest accounts.

> apache, any account that has a login.  sudo
> at least has the /etc/sudoers file.

All along I have been suggesting some configuration method that is
equivalent.  As we generally do things through SE Linux policy not
through plain-text files we can continue this.  Extending the policy to
controlling such things is not that difficult, the rough outline that's
still in the quotes above is one possibility.

>   So I can set it up so dwalsh can 
> gain access but no other accounts.  I can not do this with your proposed 
> newrole changes and enforcing=0.

No, but you could do it such that staff_r was sufficient.  The only
thing that would be slightly confusing is that it would be necessary to
disable such functionality when in permissive mode.





More information about the redhat-lspp mailing list