password policy question

password policy question

[JANAK DESAI]

Hello,

I am looking at the serefpolicy-2.2.2 (downloaded this morning from 
fedora core
development SRPMS) and am trying to figure out how, in an mls 
environment, a
user logged in at anything other s0 would be able to change his/her 
password. I
expected to see a "typeattribute passwd_t mlsfilewrite" in the 
monolithic policy.conf
file that I generated. What am I missing?

I haven't installed this policy on my test machine. I just created the 
policy file for
a training class.

Thanks.

-Janak

--
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: password policy question

[Stephen Smalley]

On Wed, 2006-01-25 at 10:04 -0500, JANAK DESAI wrote:
> Hello,
> 
> I am looking at the serefpolicy-2.2.2 (downloaded this morning from 
> fedora core
> development SRPMS) and am trying to figure out how, in an mls 
> environment, a
> user logged in at anything other s0 would be able to change his/her 
> password. I
> expected to see a "typeattribute passwd_t mlsfilewrite" in the 
> monolithic policy.conf
> file that I generated. What am I missing?

Is that really what you want?  It would allow a high process to
downgrade information via the passwd file.

-- 
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: password policy question

[JANAK DESAI]

Stephen Smalley wrote:

>On Wed, 2006-01-25 at 10:04 -0500, JANAK DESAI wrote:
>  
>
>>Hello,
>>
>>I am looking at the serefpolicy-2.2.2 (downloaded this morning from 
>>fedora core
>>development SRPMS) and am trying to figure out how, in an mls 
>>environment, a
>>user logged in at anything other s0 would be able to change his/her 
>>password. I
>>expected to see a "typeattribute passwd_t mlsfilewrite" in the 
>>monolithic policy.conf
>>file that I generated. What am I missing?
>>    
>>
>
>Is that really what you want?  It would allow a high process to
>downgrade information via the passwd file.
>
>  
>
What happens if you have user that is defined with mls range of
s3 to s9. How would this user change their password? Looking at
the password policy, I couldn't figure out how that would work.

-Janak

--
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: password policy question

[Stephen Smalley]

On Wed, 2006-01-25 at 13:00 -0500, JANAK DESAI wrote:
> What happens if you have user that is defined with mls range of
> s3 to s9. How would this user change their password? Looking at
> the password policy, I couldn't figure out how that would work.

In that case, if the passwd file was labeled s0, they wouldn't - they
would have to ask an admin to do it for them.  Otherwise, you are
allowing an arbitrary user process to downgrade info through the passwd
file, as I said.

-- 
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: password policy question

[Chad Hanson]

MLS attributes of mlsfilewrite and mlsfiledowngrade should be on passwd_t

> 
> On Wed, 2006-01-25 at 13:00 -0500, JANAK DESAI wrote:
> > What happens if you have user that is defined with mls range of
> > s3 to s9. How would this user change their password? Looking at
> > the password policy, I couldn't figure out how that would work.
> 

That is correct, these attributes need to be used for password changing.


> In that case, if the passwd file was labeled s0, they wouldn't - they
> would have to ask an admin to do it for them.  Otherwise, you are
> allowing an arbitrary user process to downgrade info through 
> the passwd file, as I said.
> 

This isn't an arbitrary process, this is the passwd program running in the
passwd_t domain. The only thing the "trusted" program does is alter password
data. The password data itself isn't classified so downgrading is allowed in
this controlled instance.

-Chad

--
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: password policy question

[Stephen Smalley]

On Wed, 2006-01-25 at 13:35 -0500, Chad Hanson wrote:
> This isn't an arbitrary process, this is the passwd program running in the
> passwd_t domain. The only thing the "trusted" program does is alter password
> data. The password data itself isn't classified so downgrading is allowed in
> this controlled instance.

Yes, but it is the caller that provides the input data (the new
password), which could be used to leak arbitrary data through the passwd
file.  In the case of the password itself, the channel is constrained by
the fact that the plaintext is not saved to the file, but there is still
a channel under the control of the caller.  In the case of other passwd
file fields settable via chfn/chsh and some forms of the passwd program
(not sure about the RH one), you can leak arbitrary plaintext (subject
only to length limitations).

-- 
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: password policy question

[Chad Hanson]

Very true that this is a downgrade channel. We should probably create
another boolean for the ability of disallowing the chsh/chfn access, similar
to ping, thus closing this channel.

> 
> On Wed, 2006-01-25 at 13:35 -0500, Chad Hanson wrote:
> > This isn't an arbitrary process, this is the passwd program running in
the
> > passwd_t domain. The only thing the "trusted" program does is alter
password
> > data. The password data itself isn't classified so downgrading is
allowed in
> > this controlled instance.
> 
> Yes, but it is the caller that provides the input data (the new
> password), which could be used to leak arbitrary data through the passwd
> file.  In the case of the password itself, the channel is constrained by
> the fact that the plaintext is not saved to the file, but there is still
> a channel under the control of the caller.  In the case of other passwd
> file fields settable via chfn/chsh and some forms of the passwd program
> (not sure about the RH one), you can leak arbitrary plaintext (subject
> only to length limitations).

--
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: password policy question

[JANAK DESAI]

Chad Hanson wrote:

>Very true that this is a downgrade channel. We should probably create
>another boolean for the ability of disallowing the chsh/chfn access, similar
>to ping, thus closing this channel.
>  
>
I think that would be very useful. Even though LSPP doesn't require that 
users
should be allowed to change their passwords, it does seem like a severe
restriction for non-s0 users.

-Janak

>  
>
>>On Wed, 2006-01-25 at 13:35 -0500, Chad Hanson wrote:
>>    
>>
>>>This isn't an arbitrary process, this is the passwd program running in
>>>      
>>>
>the
>  
>
>>>passwd_t domain. The only thing the "trusted" program does is alter
>>>      
>>>
>password
>  
>
>>>data. The password data itself isn't classified so downgrading is
>>>      
>>>
>allowed in
>  
>
>>>this controlled instance.
>>>      
>>>
>>Yes, but it is the caller that provides the input data (the new
>>password), which could be used to leak arbitrary data through the passwd
>>file.  In the case of the password itself, the channel is constrained by
>>the fact that the plaintext is not saved to the file, but there is still
>>a channel under the control of the caller.  In the case of other passwd
>>file fields settable via chfn/chsh and some forms of the passwd program
>>(not sure about the RH one), you can leak arbitrary plaintext (subject
>>only to length limitations).
>>    
>>
>
>--
>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.
>
>
>  
>


--
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: password policy question

[Steve G]

>In the case of other passwd file fields settable via chfn/chsh and some 
>forms of the passwd program (not sure about the RH one), you can leak
>arbitrary plaintext (subject only to length limitations).

Out of curiosity...is anyone doing any covert channel analysis? Even if no one
is, we should start collecting this information as a starting point for people
that will ultimately do this.

-Steve

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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