[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