newrole - adding capabilities for polyinstantiation

newrole - adding capabilities for polyinstantiation

[Michael C Thompson]

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.

Re: newrole - adding capabilities for polyinstantiation

[Michael C Thompson]

Michael C Thompson wrote:
> Stephen Smalley wrote:
>> On Wed, 2006-09-27 at 16:25 -0500, Michael C Thompson wrote:
<snip>
>>> 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 think it would be acceptable to have AUDIT_PRIV and NAMESPACE_PRIV, 
based on my suggestion below.

>> 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.

After some discussion with some people in my department, I would like to 
suggest the following proposal for newrole, which I believe would 
address the need for polyinstantiation in the LSPP environment.

I propose we fork newrole into a two separate processes in the LSPP 
environment. One process would retain only the CAP_AUDIT_WRITE 
capability, and be responsible for handling the bulk of newrole 
operation. The other process, which would only be forked when compiled 
for the LSPP environment, would retain all capabilities required for the 
polyinstantiation operation.

This second, more privilaged, process's scope would be limited to 
handling the pam_session requests. This would allow this separate 
process to remain suid for its lifetime (hopefully alleviating Stephen 
Smalley's concerns) and split it from the more vulnerable code.

Interactions between the less-secure and more-secure processes would be 
handled through a restricted IPC mechanism.

What do people think of this idea?

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.

Re: newrole - adding capabilities for polyinstantiation

[Stephen Smalley]

On Fri, 2006-09-29 at 14:42 -0500, Michael C Thompson wrote:
> After some discussion with some people in my department, I would like to 
> suggest the following proposal for newrole, which I believe would 
> address the need for polyinstantiation in the LSPP environment.
> 
> I propose we fork newrole into a two separate processes in the LSPP 
> environment. One process would retain only the CAP_AUDIT_WRITE 
> capability, and be responsible for handling the bulk of newrole 
> operation. The other process, which would only be forked when compiled 
> for the LSPP environment, would retain all capabilities required for the 
> polyinstantiation operation.
> 
> This second, more privilaged, process's scope would be limited to 
> handling the pam_session requests. This would allow this separate 
> process to remain suid for its lifetime (hopefully alleviating Stephen 
> Smalley's concerns) and split it from the more vulnerable code.
> 
> Interactions between the less-secure and more-secure processes would be 
> handled through a restricted IPC mechanism.
> 
> What do people think of this idea?

pam_namespace has to run in the same process that exec's the user shell;
otherwise, it ends up manipulating the namespace of its own process and
has no effect on the user shell's namespace.  That is why you can't just
run it as a helper or separate process.  You'd have to move the exec'ing
of the user shell into it as well, at which point you also have to move
the setting up of the new context into it, and voila!  you've re-created
newrole in this second process.

-- 
Stephen Smalley
National Security Agency


--
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.

Re: newrole - adding capabilities for polyinstantiation

[Michael C Thompson]

Michael C Thompson wrote:
> Stephen Smalley wrote:
>> (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.

As the code stands, even if we delayed the setresuid till right before 
the call to exec the shell, the files created by pam_namespace would 
still have the caller's uid because the real uid of the process isn't 
affected by the suid bit (only the effective uid), and file system 
operations are based on the real uid.

What we would need to do is change the real uid to be, say, root in 
order to protect the operations done by pam_namespace. This could be 
done right before the calls to pam_namespace, but I'm not sure how much 
value is obtained from that approach.

<snip>
>> 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.

There are a few concerns which have arisen due to this polyinstantiation 
and suid newrole work. One such concern is that with labeled networking, 
using newrole to change your MLS level will not work as intended, since 
the relabeled tty will not be able to talk to the socket. This would 
limit using newrole to manipulate our MLS to the console, and would 
leave newrole capable of only changing the role and type on network 
connections.

However, even with this MLS level concern aside, is it expected that 
using newrole to change your active role will also polyinstantiate 
directories? If so, then newrole needs to be a setuid root program.

If making newrole to be a setuid root program is considered 
unacceptable, an alternative needs to be provided for users to specify 
the desired role (and type) to assume upon login.

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.

Re: newrole - adding capabilities for polyinstantiation

[Russell Coker]

On Wednesday 04 October 2006 08:40, Michael C Thompson <thompsmc@us.ibm.com> 
wrote:
> There are a few concerns which have arisen due to this polyinstantiation
> and suid newrole work. One such concern is that with labeled networking,
> using newrole to change your MLS level will not work as intended, since
> the relabeled tty will not be able to talk to the socket. This would
> limit using newrole to manipulate our MLS to the console, and would
> leave newrole capable of only changing the role and type on network
> connections.

What do you mean?

You have sshd talking to /dev/ptmx and the shell talking to /dev/pts/X.  
If /dev/pts/X is relabeled to a different range then sshd will still keep 
talking to /dev/ptmx without any change (in fact sshd can't conveniently know 
about this change).

The only problems you have with network logins and newrole are if you do "exec 
newrole" or if your connection is closed due to a network error.  In those 
cases sshd may try to restore the context of a /dev/pts/X device that it is 
not permitted to access.  Of course given that /dev/pts/X is going to 
disappear this makes no real difference.

The only way I can think of network context being an issue is if you run the 
following command:
ssh user@host "newrole -r foo_r"

In that case sshd will not create a pty and will instead use a Unix domain 
socket.  But I can't imagine any situation in which you would do that 
(newrole typically requires an interactive session).

> However, even with this MLS level concern aside, is it expected that
> using newrole to change your active role will also polyinstantiate
> directories? If so, then newrole needs to be a setuid root program.

I believe that this is necessary.  What is the point of having 
poly-instantiated directories if the standard commands used to change 
security contexts don't use them?  Also if you have two shells open in role 
foo_r which have different versions of /tmp because the initial logins were 
from different contexts then it will be at best confusing and at worst a 
security leak.

> If making newrole to be a setuid root program is considered
> unacceptable, an alternative needs to be provided for users to specify
> the desired role (and type) to assume upon login.

We already have that for ssh and console logins.  Doing it for X logins was 
not viable in the past due to lack of PI.  But with a PI home directory it is 
viable to allow the user to select a context through an XDM program.  With PI 
directories my previous objections to context selection for an X login have
become obsolete.

Also for an X session it's quite viable to ssh to localhost from an xterm to 
create a session with a different context, and that is no more difficult than 
running newrole.  I am not advocating doing this, just noting that it is 
possible.

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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.

Re: newrole - adding capabilities for polyinstantiation

[Stephen Smalley]

On Tue, 2006-10-03 at 17:40 -0500, Michael C Thompson wrote:
> Michael C Thompson wrote:
> > Stephen Smalley wrote:
> >> (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.
> 
> As the code stands, even if we delayed the setresuid till right before 
> the call to exec the shell, the files created by pam_namespace would 
> still have the caller's uid because the real uid of the process isn't 
> affected by the suid bit (only the effective uid), and file system 
> operations are based on the real uid.

That is not correct.  File system operations in Linux are based on the
fsuid, which shadows the euid unless explicitly set.  

> What we would need to do is change the real uid to be, say, root in 
> order to protect the operations done by pam_namespace. This could be 
> done right before the calls to pam_namespace, but I'm not sure how much 
> value is obtained from that approach.

If you delay the setresuid call until after pam_namespace runs, then
files created by it should be created in uid 0 by default, and thus not
immediately accessible to the caller.

> There are a few concerns which have arisen due to this polyinstantiation 
> and suid newrole work. One such concern is that with labeled networking, 
> using newrole to change your MLS level will not work as intended, since 
> the relabeled tty will not be able to talk to the socket. This would 
> limit using newrole to manipulate our MLS to the console, and would 
> leave newrole capable of only changing the role and type on network 
> connections.
> 
> However, even with this MLS level concern aside, is it expected that 
> using newrole to change your active role will also polyinstantiate 
> directories? If so, then newrole needs to be a setuid root program.

For some users, yes.  But this will vary depending on user need.

> If making newrole to be a setuid root program is considered 
> unacceptable, an alternative needs to be provided for users to specify 
> the desired role (and type) to assume upon login.

-- 
Stephen Smalley
National Security Agency


--
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.

Re: newrole - adding capabilities for polyinstantiation

[Michael C Thompson]

Russell Coker wrote:
> On Wednesday 04 October 2006 08:40, Michael C Thompson <thompsmc@us.ibm.com> 
> wrote:
>> There are a few concerns which have arisen due to this polyinstantiation
>> and suid newrole work. One such concern is that with labeled networking,
>> using newrole to change your MLS level will not work as intended, since
>> the relabeled tty will not be able to talk to the socket. This would
>> limit using newrole to manipulate our MLS to the console, and would
>> leave newrole capable of only changing the role and type on network
>> connections.
> 
> What do you mean?

TBH, I don't totally understand it myself. However, it was explained to 
me that if you newrole to a new level over a labeled network connection, 
this will break the session since the network connection is at one 
level, and you are now at another.

> You have sshd talking to /dev/ptmx and the shell talking to /dev/pts/X.  
> If /dev/pts/X is relabeled to a different range then sshd will still keep 
> talking to /dev/ptmx without any change (in fact sshd can't conveniently know 
> about this change).
> 
> The only problems you have with network logins and newrole are if you do "exec 
> newrole" or if your connection is closed due to a network error.  In those 
> cases sshd may try to restore the context of a /dev/pts/X device that it is 
> not permitted to access.  Of course given that /dev/pts/X is going to 
> disappear this makes no real difference.
> 
> The only way I can think of network context being an issue is if you run the 
> following command:
> ssh user@host "newrole -r foo_r"
> 
> In that case sshd will not create a pty and will instead use a Unix domain 
> socket.  But I can't imagine any situation in which you would do that 
> (newrole typically requires an interactive session).
> 
>> However, even with this MLS level concern aside, is it expected that
>> using newrole to change your active role will also polyinstantiate
>> directories? If so, then newrole needs to be a setuid root program.
> 
> I believe that this is necessary.  What is the point of having 
> poly-instantiated directories if the standard commands used to change 
> security contexts don't use them?  Also if you have two shells open in role 
> foo_r which have different versions of /tmp because the initial logins were 
> from different contexts then it will be at best confusing and at worst a 
> security leak.

The I will gladly continue my work on it :) I just wanted to make sure 
that I wasn't spending time on something that would end up having no value.

>> If making newrole to be a setuid root program is considered
>> unacceptable, an alternative needs to be provided for users to specify
>> the desired role (and type) to assume upon login.
> 
> We already have that for ssh and console logins.

I wasn't aware. What is the mechanism?





--
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.

Re: newrole - adding capabilities for polyinstantiation

[Stephen Smalley]

On Wed, 2006-10-04 at 09:52 +1000, Russell Coker wrote:
> On Wednesday 04 October 2006 08:40, Michael C Thompson <thompsmc@us.ibm.com> 
> wrote:
> > There are a few concerns which have arisen due to this polyinstantiation
> > and suid newrole work. One such concern is that with labeled networking,
> > using newrole to change your MLS level will not work as intended, since
> > the relabeled tty will not be able to talk to the socket. This would
> > limit using newrole to manipulate our MLS to the console, and would
> > leave newrole capable of only changing the role and type on network
> > connections.
> 
> What do you mean?
> 
> You have sshd talking to /dev/ptmx and the shell talking to /dev/pts/X.  
> If /dev/pts/X is relabeled to a different range then sshd will still keep 
> talking to /dev/ptmx without any change (in fact sshd can't conveniently know 
> about this change).

See the thread starting here:
http://www.redhat.com/archives/redhat-lspp/2006-July/msg00024.html

> 
> The only problems you have with network logins and newrole are if you do "exec 
> newrole" or if your connection is closed due to a network error.  In those 
> cases sshd may try to restore the context of a /dev/pts/X device that it is 
> not permitted to access.  Of course given that /dev/pts/X is going to 
> disappear this makes no real difference.
> 
> The only way I can think of network context being an issue is if you run the 
> following command:
> ssh user@host "newrole -r foo_r"
> 
> In that case sshd will not create a pty and will instead use a Unix domain 
> socket.  But I can't imagine any situation in which you would do that 
> (newrole typically requires an interactive session).
> 
> > However, even with this MLS level concern aside, is it expected that
> > using newrole to change your active role will also polyinstantiate
> > directories? If so, then newrole needs to be a setuid root program.
> 
> I believe that this is necessary.  What is the point of having 
> poly-instantiated directories if the standard commands used to change 
> security contexts don't use them?  Also if you have two shells open in role 
> foo_r which have different versions of /tmp because the initial logins were 
> from different contexts then it will be at best confusing and at worst a 
> security leak.
> 
> > If making newrole to be a setuid root program is considered
> > unacceptable, an alternative needs to be provided for users to specify
> > the desired role (and type) to assume upon login.
> 
> We already have that for ssh and console logins.  Doing it for X logins was 
> not viable in the past due to lack of PI.  But with a PI home directory it is 
> viable to allow the user to select a context through an XDM program.  With PI 
> directories my previous objections to context selection for an X login have
> become obsolete.
> 
> Also for an X session it's quite viable to ssh to localhost from an xterm to 
> create a session with a different context, and that is no more difficult than 
> running newrole.  I am not advocating doing this, just noting that it is 
> possible.
> 
-- 
Stephen Smalley
National Security Agency


--
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.

Re: newrole - adding capabilities for polyinstantiation

[Michael C Thompson]

Stephen Smalley wrote:
> On Tue, 2006-10-03 at 17:40 -0500, Michael C Thompson wrote:
>> Michael C Thompson wrote:
>>> Stephen Smalley wrote:
>>>> (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.
>> As the code stands, even if we delayed the setresuid till right before 
>> the call to exec the shell, the files created by pam_namespace would 
>> still have the caller's uid because the real uid of the process isn't 
>> affected by the suid bit (only the effective uid), and file system 
>> operations are based on the real uid.
> 
> That is not correct.  File system operations in Linux are based on the
> fsuid, which shadows the euid unless explicitly set.

hmm, you are right (and I, alas, was wrong). However, the files will be 
created with the egid being the calling user (as it stands). I imagine 
we'd want to change that.

>> What we would need to do is change the real uid to be, say, root in 
>> order to protect the operations done by pam_namespace. This could be 
>> done right before the calls to pam_namespace, but I'm not sure how much 
>> value is obtained from that approach.
> 
> If you delay the setresuid call until after pam_namespace runs, then
> files created by it should be created in uid 0 by default, and thus not
> immediately accessible to the caller.

I assume then that this is desirable? If so, I'll implement it. I've 
been working on breaking the code up to be a little more modular, so 
that such a change would be clean and easy to implement.

>> There are a few concerns which have arisen due to this polyinstantiation 
>> and suid newrole work. One such concern is that with labeled networking, 
>> using newrole to change your MLS level will not work as intended, since 
>> the relabeled tty will not be able to talk to the socket. This would 
>> limit using newrole to manipulate our MLS to the console, and would 
>> leave newrole capable of only changing the role and type on network 
>> connections.
>>
>> However, even with this MLS level concern aside, is it expected that 
>> using newrole to change your active role will also polyinstantiate 
>> directories? If so, then newrole needs to be a setuid root program.
> 
> For some users, yes.  But this will vary depending on user need.

I'll continue my work on making newrole a more accetpable suid program then.

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.

Re: newrole - adding capabilities for polyinstantiation

[Stephen Smalley]

On Wed, 2006-10-04 at 11:31 -0500, Michael C Thompson wrote:
> Stephen Smalley wrote:
> > That is not correct.  File system operations in Linux are based on the
> > fsuid, which shadows the euid unless explicitly set.
> 
> hmm, you are right (and I, alas, was wrong). However, the files will be 
> created with the egid being the calling user (as it stands). I imagine 
> we'd want to change that.

Not clear that it matters.  IIUC, pam_namespace already sets the user
and group ownership after creation, so the only reason we care about
euid/fsuid is ensuring that the directory isn't temporarily accessible
to the caller.  As long as the directory mode is owner-only (as I think
it is), the initial gid on the directory shouldn't matter.

-- 
Stephen Smalley
National Security Agency


--
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.

Re: newrole - adding capabilities for polyinstantiation

[Stephen Smalley]

On Wed, 2006-10-04 at 11:19 -0500, Michael C Thompson wrote:
> Russell Coker wrote:
> > On Wednesday 04 October 2006 08:40, Michael C Thompson <thompsmc@us.ibm.com> 
> > wrote:
> >> If making newrole to be a setuid root program is considered
> >> unacceptable, an alternative needs to be provided for users to specify
> >> the desired role (and type) to assume upon login.
> > 
> > We already have that for ssh and console logins.
> 
> I wasn't aware. What is the mechanism?

It did exist at one time, but I don't think it is still there.
pam_selinux used to provide support for context selection when there
were multiple contexts authorized for the user, but I think it was
ultimately dropped by Red Hat, as they wanted to simplify and provide
consistency among all forms of login, and chose to only allow initial
login in the default context for the user.  There was also experimental
support (by Colin Walters) for specifying a role for ssh a long time ago
(e.g. ssh root/sysadm_r@hostname) and I see that code in the Fedora tree
still (but whether it works with current policy is another matter), but
it doesn't appear to be included in the selinux support that is now
included in the upstream openssh (as of 4.4p1), so I assume it is slated
for demise.

-- 
Stephen Smalley
National Security Agency


--
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.

Re: newrole - adding capabilities for polyinstantiation

[Klaus Weidner]

On Wed, Oct 04, 2006 at 09:52:02AM +1000, Russell Coker wrote:
> On Wednesday 04 October 2006 08:40, Michael C Thompson <thompsmc@us.ibm.com> 
> wrote:
> > There are a few concerns which have arisen due to this polyinstantiation
> > and suid newrole work. One such concern is that with labeled networking,
> > using newrole to change your MLS level will not work as intended, since
> > the relabeled tty will not be able to talk to the socket. This would
> > limit using newrole to manipulate our MLS to the console, and would
> > leave newrole capable of only changing the role and type on network
> > connections.
> 
> What do you mean?
> 
> You have sshd talking to /dev/ptmx and the shell talking to /dev/pts/X.  
> If /dev/pts/X is relabeled to a different range then sshd will still keep 
> talking to /dev/ptmx without any change (in fact sshd can't conveniently know 
> about this change).

But that's not supposed to work, see:

	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200110

and the thread that Stephen Smalley also referred to:

	http://www.redhat.com/archives/redhat-lspp/2006-July/msg00024.html

The communication between the master and slave ends of the pty violates
the MLS policy, and makes it easy for unprivileged users to violate the
policy restrictions.

LSPP is not concerned with covert channels, but the pty hole isn't
covert, it's a direct use of official interfaces according to their
specification, and that's not acceptable for an evaluation.

Unfortunately this means that the current system will make "newrole -l"
essentially useless over ssh sessions, and since there is no support for
selecting a level at login time it may be necessary to use workarounds,
such as creating multiple Linux usernames mapped to the same UID but with
different default MLS levels (configured via "semanage login"). (I've
just tested that - it works, but I'm not sure if that's how people expect
the system to behave.)

> Also for an X session it's quite viable to ssh to localhost from an xterm to 
> create a session with a different context, and that is no more difficult than 
> running newrole.  I am not advocating doing this, just noting that it is 
> possible.

Well, this should only work if you have a proper MLS aware desktop that
can prevent cut&paste between the sessions at various levels, and would
require MLS override capabilites for the X server and/or window manager.

Currently, even localhost networking is supposed to be labeled, so you
wouldn't be able to use a SSH session running at a different label for
communication.

-Klaus

--
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.

Re: newrole - adding capabilities for polyinstantiation

[Michael C Thompson]

Stephen Smalley wrote:
> On Wed, 2006-10-04 at 11:31 -0500, Michael C Thompson wrote:
>> Stephen Smalley wrote:
>>> That is not correct.  File system operations in Linux are based on the
>>> fsuid, which shadows the euid unless explicitly set.
>> hmm, you are right (and I, alas, was wrong). However, the files will be 
>> created with the egid being the calling user (as it stands). I imagine 
>> we'd want to change that.
> 
> Not clear that it matters.  IIUC, pam_namespace already sets the user
> and group ownership after creation, so the only reason we care about
> euid/fsuid is ensuring that the directory isn't temporarily accessible
> to the caller.  As long as the directory mode is owner-only (as I think
> it is), the initial gid on the directory shouldn't matter.
> 

 From pam_namespace.c:
mkdir(ipath, S_IRUSR)

After this, the security attributes of the directory are set according 
to those of the original with the appropriate uid/gid and perm mask.

So again, you are indeed correct. One of these days...!

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.

Re: newrole - adding capabilities for polyinstantiation

[Russell Coker]

On Thursday 05 October 2006 06:20, Klaus Weidner <klaus@atsec.com> wrote:
> > You have sshd talking to /dev/ptmx and the shell talking to /dev/pts/X.
> > If /dev/pts/X is relabeled to a different range then sshd will still keep
> > talking to /dev/ptmx without any change (in fact sshd can't conveniently
> > know about this change).
>
> But that's not supposed to work, see:
>
> 	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200110
>
> and the thread that Stephen Smalley also referred to:
>
> 	http://www.redhat.com/archives/redhat-lspp/2006-July/msg00024.html
>
> The communication between the master and slave ends of the pty violates
> the MLS policy, and makes it easy for unprivileged users to violate the
> policy restrictions.

How is ssh supposed to work then?

Currently the sshd code for selecting roles is being discussed.  I never 
expected the sshd upstream people to include that at the first pass and 
considered that they might refuse to ever include it.  This is not a big deal 
IMHO as patching base SE Linux support in the openssh source tree to have 
more features is less work and less risk than patching in SE Linux support 
where previously there was none.

If sshd role selection support is maintained and if it's then extended to 
support a selection of MLS/MCS ranges then what restrictions will be placed 
on the range selected?  Is the aim to make sshd use labeled networking 
features to enforce a range that matches the client end?  If so then newrole 
should be prevented on ssh sessions (IE all pty sessions).

If the ssh client should be permitted to select the role and range then there 
is little extra vulnerability in also permitting the newrole program to 
perform the operations being discussed as the user could always cat the file 
from one ssh session and then proxy it to a cat command in another session at 
a different level.  This issue may still apply if the ssh client can not 
select the level as the user may have multiple Unix accounts on the server 
that have different levels.

It seems to me that the minimal solution to this problem of data relabeling is 
to prevent newrole from accessing regular pty devices (*) and to prevent ssh 
logins unless the labeled networking functionality is enabled, the client 
process is at the same level, and the client computer has the same level of 
integrity and the same meanings for MLS levels.

(*) This can be achieved by having more types for tty devices, we have 
user_devpts_t for ptys created by the user and we could have 
user_system_devpts_t for ptys created for the user by sshd or similar 
programs.  Then newrole could operate on ptys created by sshd but not on 
those created by the user.  This also means that newrole in an xterm would be 
impossible, but given the issues related to capturing data from an xterm this 
is a good thing.  It would be quite easy to have the default policy have such 
types and have a boolean to determine whether newrole_t can access 
user_devpts_t.

When we get SE-X going we could have an X enabled version of newrole that 
spawns an xterm in the new context.

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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.

Re: newrole - adding capabilities for polyinstantiation

[Klaus Weidner]

On Thu, Oct 05, 2006 at 10:45:35AM +1000, Russell Coker wrote:
> On Thursday 05 October 2006 06:20, Klaus Weidner <klaus@atsec.com> wrote:
> > But that's not supposed to work, see:
> > 	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200110
> > and the thread that Stephen Smalley also referred to:
> > 	http://www.redhat.com/archives/redhat-lspp/2006-July/msg00024.html
> >
> > The communication between the master and slave ends of the pty violates
> > the MLS policy, and makes it easy for unprivileged users to violate the
> > policy restrictions.
> 
> How is ssh supposed to work then?

I think the sane behaviors for MLS login would be any of the following:

- for local VTs or serial terminals, login at the default level,
  and permit using newrole to change level (or role). newrole relabels
  the tty device to match. Alternatively, choosing a context when
  logging in would be ok.

- when using SSH with labeled networking, the network connection has a
  MLS label corresponding to the sending process (ssh client), and the
  login session gets this MLS level if it's within the user's clearance
  range, otherwise the session is rejected. Newrole is not useful for
  changing levels since the input or output stream won't be permitted
  to communicate over the socket, but newrole can be used for launching
  noninteractive programs that don't need to communicate with the pty.

- when using SSH over unlabeled networks (which is of course a leak for
  MLS information), newrole can relabel the pty. Alternatively, choosing
  a context when logging in would be ok.

For SSH with labeled networking, since you don't get to choose the level
you want to work at, your ssh client needs to be at the correct level
already. This means that you need to be logged in at the local machine at
the appropriate level, or use a MLS capable GUI desktop with a terminal
window at the right level. The GUI version doesn't work (yet) for Linux,
but it could be a legacy trusted OS that uses CIPSO to communicate.

Maybe the easiest way to get this behavior is to ensure that relabeling
one end of a pty pair automatically relabels the other end too. Of
course, trusted apps can use MLS overrides, but sshd should not do so.

> Currently the sshd code for selecting roles is being discussed.  I never 
> expected the sshd upstream people to include that at the first pass and 
> considered that they might refuse to ever include it.  This is not a big deal 
> IMHO as patching base SE Linux support in the openssh source tree to have 
> more features is less work and less risk than patching in SE Linux support 
> where previously there was none.
> 
> If sshd role selection support is maintained and if it's then extended to 
> support a selection of MLS/MCS ranges then what restrictions will be placed 
> on the range selected?  Is the aim to make sshd use labeled networking 
> features to enforce a range that matches the client end?  If so then newrole 
> should be prevented on ssh sessions (IE all pty sessions).

The main focus for the LSPP projects is MLS labels, and there isn't a
requirement that roles and types get synchronized and type enforced
across the network.

For the MLS levels, it shouldn't be necessary to modify sshd to support
the restrictions - on the contrary, the restrictions should happen
automatically since sshd doesn't have MLS override capabilities.

Using sshd modifications or PAM modules to support context selection
sounds like a nice feature for non-MLS uses, but it is not required (or
useful) for the case of ssh login over a MLS labeled network.

> If the ssh client should be permitted to select the role and range then there 
> is little extra vulnerability in also permitting the newrole program to 
> perform the operations being discussed as the user could always cat the file 
> from one ssh session and then proxy it to a cat command in another session at 
> a different level.  This issue may still apply if the ssh client can not 
> select the level as the user may have multiple Unix accounts on the server 
> that have different levels.

See my latest update to the bug quoted above, this proxying isn't
supposed to be possible, and it would not happen if ptys have sane
relabeling behavior - meaning that either both ends always have the same
label, or alternatively (if they have different labels) the MLS
constraints are applied to the data flow.

> It seems to me that the minimal solution to this problem of data relabeling is 
> to prevent newrole from accessing regular pty devices (*) and to prevent ssh 
> logins unless the labeled networking functionality is enabled, the client 
> process is at the same level, and the client computer has the same level of 
> integrity and the same meanings for MLS levels.

I don't think it's necessary to be this restrictive. We don't need to
stop people from using ssh over unlabeled networks if that's what they
want to do (this may be perfectly appropriate for a less paranoid MCS
system). The expectation is that there's a single switch to disable
unlabeled network communication for people who need MLS enforced
networking, and then the MLS restrictions would do the right thing
without needing to modify programs. Admins could assign MLS overrides to
processes that need them.

> (*) This can be achieved by having more types for tty devices, we have 
> user_devpts_t for ptys created by the user and we could have 
> user_system_devpts_t for ptys created for the user by sshd or similar 
> programs.  Then newrole could operate on ptys created by sshd but not on 
> those created by the user.  This also means that newrole in an xterm would be 
> impossible, but given the issues related to capturing data from an xterm this 
> is a good thing.  It would be quite easy to have the default policy have such 
> types and have a boolean to determine whether newrole_t can access 
> user_devpts_t.

I think that's a slippery slope, and it would be better to properly
enforce the MLS constraints rather than patching up gaps using type
enforcement.

> When we get SE-X going we could have an X enabled version of newrole that 
> spawns an xterm in the new context.

Yes - then that would be the recommended way to handle multilevel access.
If you want to ssh to a system at "secret" level, you'd first open a
"secret" xterm, then do plain ssh to the remote system and you'd be
logged in as "secret" there to match the socket label.

-Klaus

--
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.

MLS login (Was: Re: newrole - adding capabilities for polyinstantiation)

[Stephen Smalley]

On Thu, 2006-10-05 at 11:08 -0500, Klaus Weidner wrote:
> On Thu, Oct 05, 2006 at 10:45:35AM +1000, Russell Coker wrote:
> > On Thursday 05 October 2006 06:20, Klaus Weidner <klaus@atsec.com> wrote:
> > > But that's not supposed to work, see:
> > > 	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200110
> > > and the thread that Stephen Smalley also referred to:
> > > 	http://www.redhat.com/archives/redhat-lspp/2006-July/msg00024.html
> > >
> > > The communication between the master and slave ends of the pty violates
> > > the MLS policy, and makes it easy for unprivileged users to violate the
> > > policy restrictions.
> > 
> > How is ssh supposed to work then?
> 
> I think the sane behaviors for MLS login would be any of the following:
> 
> - for local VTs or serial terminals, login at the default level,
>   and permit using newrole to change level (or role). newrole relabels
>   the tty device to match. Alternatively, choosing a context when
>   logging in would be ok.
> 
> - when using SSH with labeled networking, the network connection has a
>   MLS label corresponding to the sending process (ssh client), and the
>   login session gets this MLS level if it's within the user's clearance
>   range, otherwise the session is rejected.

Just to be clear, this behavior would only occur if running sshd under
xinetd, right?  So that the sshd instance is run in the peer's range and
is already bound by it?  Otherwise, the normal sshd selinux support will
just select a default context for the user without consideration of the
peer label.

>  Newrole is not useful for
>   changing levels since the input or output stream won't be permitted
>   to communicate over the socket, but newrole can be used for launching
>   noninteractive programs that don't need to communicate with the pty.

Not sure that will work presently without some changes to newrole.

> - when using SSH over unlabeled networks (which is of course a leak for
>   MLS information), newrole can relabel the pty. Alternatively, choosing
>   a context when logging in would be ok.
> 
> For SSH with labeled networking, since you don't get to choose the level
> you want to work at, your ssh client needs to be at the correct level
> already. This means that you need to be logged in at the local machine at
> the appropriate level, or use a MLS capable GUI desktop with a terminal
> window at the right level. The GUI version doesn't work (yet) for Linux,
> but it could be a legacy trusted OS that uses CIPSO to communicate.
> 
> Maybe the easiest way to get this behavior is to ensure that relabeling
> one end of a pty pair automatically relabels the other end too. Of
> course, trusted apps can use MLS overrides, but sshd should not do so.

I think sshd_t gets MLS overrides in policy, like other login-like
domains, since it can create user sessions at various levels and sets
the pty labels accordingly.

> For the MLS levels, it shouldn't be necessary to modify sshd to support
> the restrictions - on the contrary, the restrictions should happen
> automatically since sshd doesn't have MLS override capabilities.

...except I think it does.  The discussion seems a bit divorced from
reality.

-- 
Stephen Smalley
National Security Agency


--
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.

Re: MLS login (Was: Re: newrole - adding capabilities for polyinstantiation)

[Klaus Weidner]

On Thu, Oct 05, 2006 at 03:04:37PM -0400, Stephen Smalley wrote:
> On Thu, 2006-10-05 at 11:08 -0500, Klaus Weidner wrote:
> > I think the sane behaviors for MLS login would be any of the following:
> > 
> > - for local VTs or serial terminals, login at the default level,
> >   and permit using newrole to change level (or role). newrole relabels
> >   the tty device to match. Alternatively, choosing a context when
> >   logging in would be ok.
> > 
> > - when using SSH with labeled networking, the network connection has a
> >   MLS label corresponding to the sending process (ssh client), and the
> >   login session gets this MLS level if it's within the user's clearance
> >   range, otherwise the session is rejected.
> 
> Just to be clear, this behavior would only occur if running sshd under
> xinetd, right?  So that the sshd instance is run in the peer's range and
> is already bound by it?  Otherwise, the normal sshd selinux support will
> just select a default context for the user without consideration of the
> peer label.

Yes, that's the current plan.

> >  Newrole is not useful for
> >   changing levels since the input or output stream won't be permitted
> >   to communicate over the socket, but newrole can be used for launching
> >   noninteractive programs that don't need to communicate with the pty.
> 
> Not sure that will work presently without some changes to newrole.

It wouldn't be a required feature, I was just bringing it up as an
example of what would be compatible with the restrictions.

> > Maybe the easiest way to get this behavior is to ensure that relabeling
> > one end of a pty pair automatically relabels the other end too. Of
> > course, trusted apps can use MLS overrides, but sshd should not do so.
> 
> I think sshd_t gets MLS overrides in policy, like other login-like
> domains, since it can create user sessions at various levels and sets
> the pty labels accordingly.

Argh, I wasn't aware that sshd has full MLS overrides:

	TYPES:
	sshd_t (11 attributes)
		ssh_server
		domain
		can_change_process_identity
		can_change_process_role
		can_change_object_identity
		mlsfileread
		mlsfilewrite
		mlsfileupgrade
		mlsfiledowngrade
		mlsprocsetsl
		privfd

Doesn't this have even worse consequences? For example when sshd does
port forwarding, does that mean that a client can ask it to connect to
arbitrary ports using sshd's MLS overrides? Of course, the evaluated
config could disable port forwarding, but this makes it doubtful if sshd
is trustworthy in an MLS environment.

> > For the MLS levels, it shouldn't be necessary to modify sshd to support
> > the restrictions - on the contrary, the restrictions should happen
> > automatically since sshd doesn't have MLS override capabilities.
> 
> ...except I think it does.  The discussion seems a bit divorced from
> reality.

Yes, unfortunately reality seems to be deficient :-(

How about a completely different approach for the MLS system
configuration:

- restrict newrole to admins only

- create a new sshd_via_xinetd_t domain with restricted privileges that
  doesn't change contexts and doesn't have general MLS overrides, just
  whatever is necessary to make polyinstantiation work
  
- for regular user console login (or if not enforcing labeled
  networking), create multiple Linux users for each human user that share
  the same uid and home directory, and use "semanage login" to map them
  to appropriate types. So you'd have smith_secret_cat1,
  smith_unclassified and so on.

I know it's ugly, but would this be a strategy to get an LSPP/RBAC
compliant system in the near future without having to rewrite sshd,
newrole, the kernel pty drivers, or the other potentially affected areas?

Comments?

-Klaus

--
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.