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

[Stephen Smalley]

On Thu, 2006-04-20 at 20:39 +1000, Russell Coker wrote:
> 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.

If that is your concern, then maybe you should follow the suggestion I
gave Serge Hallyn on linux-security-module earlier this week for
enabling SELinux to selectively override capabilities.  Just introduce a
new cap_override security class that mirrors capability, and change
selinux_capable to check it first.  If granted by that security class,
then skip the call to the secondary module and authoritatively grant the
capability based on SELinux domain alone.  If denied by that security
class, recheck the normal capability class, and if that is allowed, call
the secondary module as usual to require both to pass.  Then you can
give out Linux capabilities selectively to non-uid 0 processes, while
phasing it in gradually without disturbing existing policy and without
immediately exposing everything to risk.

> 
> 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.
> 
-- 
Stephen Smalley
National Security Agency