newrole - adding capabilities for polyinstantiation

[Michael C Thompson <thompsmc@us.ibm.com>]

Stephen Smalley wrote:
> On Wed, 2006-09-27 at 16:25 -0500, Michael C Thompson wrote: 
>> Hey Stephen,
>>
>> It looks like I will be taking over the newrole work that Janak was doing.
> 
> Ok, good.  Please keep discussion on list.  Also there was discussion of
> needing more auditing from newrole on redhat-lspp.

Copying the selinux list on this reply to continue the discussion.

>> After reading the thread, it seems like Janak's patches were getting 
>> close, but quite a few ideas were thrown out there, namely:
>>
>> 1) Have newrole be non-suid by default, and require the LSPP 
>> configuration package to enable its suid status (which would then enable 
>> the capabilities)
>>
>> 2) Have newrole be suid all of the time.
>>
>> 3) Have newrole determine if namespace is used for the configuration, 
>> which would then determine if the caps need to be loaded or not.
>>
>> Do you know if there was any decision on the path to take that I am 
>> unable to find on the mailing list?
> 
> I think (2) is unacceptable (the real issue is not whether it is suid
> per se, but whether it retains powerful capabilities like CAP_SYS_ADMIN
> - it is already suid for the earlier audit support, but drops everything
> but CAP_AUDIT_WRITE and reverts to the caller's uid upon startup).

With Janak's patch, there is no differentiation between the capabilities 
needed to polyinstantiate and the capabilities to audit. Is there a 
desire to audit outside of an LSPP environment? If so, then I will 
address this issue in the patch (I see AUDIT being a requirement of 
LSPP, so there is a clear dependence chain).

There is also the issue which Russel Coker brought up which is that 
pam_namespace is valuable to people outside an LSPP environment. Should 
this future work take that into account?

> I don't know how to do (3) cleanly, as it seems to violate PAM
> encapsulation.
> 
> (1) addresses the concern for non-LSPP users, but doesn't fully address
> my concerns about the additional risk to LSPP users.  One obvious issue
> is that drop_capabilities() currently also resets to the caller's uid,
> which Janak's patches do not change.  Which I think means that any
> directories and files created by pam_namespace will initially be
> assigned the caller's uid, and potentially exposed to tampering by
> processes in the caller's uid.  SELinux policy might prevent such
> tampering, but it bears investigating.  Likewise, this means that the
> newrole process itself runs in the caller's uid and might be exposed to
> interference by the caller in some forms, although I would expect that
> SELinux would block that as long as newrole is running in a different
> domain.

I will take some time and look at this further.

> We also need to consider whether more of the guidelines in e.g. the
> Secure Programming HOWTO or the kinds of safeguards implemented
> in /bin/su should be applied to newrole when it is suid.  Historically,
> newrole wasn't viewed as an especially privileged program, since it
> wasn't suid originally and since the user-role authorizations were
> actually enforced by the kernel, not by newrole.  Thus it wasn't written
> to be as paranoid about the caller as /bin/su is.

Will look at this as well.

Thanks,
Mike


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.