[redhat-lspp] newrole, UID change, etc

[Russell Coker]

On Tue, 2006-04-18 at 09:04 -0400, Stephen Smalley wrote:
> > > I have a feeling that we need something along these lines, but your
> > > suggestion doesn't seem to quite match the needs.
> > > 
> > > I'll spend some time working on this and send some mail to the list.  I
> > > might need to spend a couple of days working on this.
> > 
> > Based on the discussion on the telecon, at this time it seems that an
> > enhancement to newrole to support changing UID is the best option.
> > 
> > I'll work on this and send some code to the list if my tests show it as
> > viable.
> 
> Rationale?  We just got done reverting pam_selinux from su and friends;
> why do we want to put su-like functionality into newrole?  Sounds like a
> regression to me...

We need multiple roles for different administrative tasks.  We currently
have sysadm_r and secadm_r and desire auditadm_r.  Given the current
situation it wouldn't be surprising if someone wanted yet more roles (if
only as customised policy outside of support arrangements and upstream
inclusion).

These roles are all inadequate on their own to perform their purposes
and require Posix capabilities that are only available to UID==0.
Therefore administrative role + UID==0 is the requirement.

Multiple accounts with the same UID are not supported by Unix tools such
as useradd.  Hacking /etc/passwd to support this is easy (I've already
posted an example of how to do it from kickstart).  Modifying the code
to useradd etc is not so difficult either.  The solution of having
multiple Unix accounts with UID==0 that are each permitted to use
different roles is viable (I've used it on my own machines since 2002),
but I consider it a perversion of the Unix design philosophy.  Also SE
Linux is an independent layer of security so changing roles
independently of UID is a good thing, and at the same time we want to
support a SE Linux machine being booted without SE Linux and still being
secure (I know that people running LSPP certified configurations don't
need this, but most SE Linux users do).

This leads me to believe that we need multiple accounts with UID != 0
that are permitted to assume administrative privs.  Allowing "newrole -r
sysadm_r" followed by "su -" works, but it is inconvenient (which is why
I have been using multiple accounts with UID==0 since 2002).

Changing newrole (which is already SUID root) to permit running shells
under different UIDs is a potential solution to this problem.  It will
be quite different to the su patch though.  Firstly the su patch changed
the SE Linux identity, which is just a bad idea IMHO.  Next there's the
issue of the MLS level which was changed to the default by the su patch,
changing the level will be possible with newrole, but it won't be a
default operation.  Su has it's own logic for determining when a UID may
be changed which is based on the idea of assuming all the login privs of
the account in question.  If we have three different possibilities for
getting the UID==0 account with different amounts of SE Linux access the
PAM model as used by su breaks down.  Finally newrole doesn't get used
by scripts the way that su does (although such use of su has
significantly decreased since we introduced runuser).

Now we want policy control over when such things.  I considered the
option of using a text file for such control (a vaguely similar concept
to how sudo uses text files for control over UID change), but dismissed
it because the practice in SE Linux has been to have the access control
be performed through the policy database and have text files only be for
default settings and things which need to be known before SE Linux is
running.

I now believe that the correct thing to do is to have a new objectclass
for a permission check on changing uid.  The permission in question
would be granted to domains such as sysadm_t, secadm_t, and auditadm_t
and if newrole found such a permission when changing domain it would
change the UID (probably change to UID=0 by default and give the user
the option of specifying a different UID on the command-line).


As before, I'm still not certain that this is the best solution.  It's
merely the best that I've thought of, and (IMHO) better than any idea
anyone else has come up with.  I believe that the problems of managing
multiple roles effectively must be solved.  Therefore if no-one can
devise a better solution then I think that my idea will have to be
implemented.

I am not trying to force my idea on anyone, given the changes involved I
plan to give people time to consider it.  So I won't do any coding for
at least a week.