[Clip] Root lock out

[Brandon Whalen]

On 5/6/09 10:45 AM, "Julian Onions" <Julian.Onions at nexor.com> wrote:

> Hi Brandon,
>  
> I've been looking through the options, but as it appears its actually su that
> is changing the password (through pam libraries), so the domain sysadm_su_t
> would need quite a lot of privilege - the ability to write shadow for
> instance. I think this also applies to sudo too incidentally.
>  
> It seems when sysadm_su_t run shell_exec_t it transitions into the sysadm_t
> domain, but there may be ways to get it to carry on running in the sysadm_su_t
> domain. 
> You can certainly do this with sudo, for instance
> sudo id -Z
> shows the context as sysadm_sudo_t - so if you change the
> sudo/su_per_role_template macro to allow password updates, it would seem most
> commands run under sudo would also have that ability. Su is slightly safer as
> it appears to always use the shell to execute -c commands, so you get the
> transition out of the sysadm_su_t domain into sysadm_t domain.
>  
> Just glad we stumbled over this before shipping a system!
>  
> Julian.
>  


Sorry for the long delay but I've finally found the exact problems. You have
stumbled upon a couple policy issues. The first one has to do with running
the cracklib module and the second one has to do with actually changing user
passwords.

The cracklib module issue was caused by the fact that the CLIP policy was
not allowing the derived su domains to read the cracklib database files.
This was fixed by adding in the proper call to the usermanage module.

The other problem is that sometimes the pam libraries run unix_update and
sometimes they don't when a user needs to update their password. The pam
libraries perform checks to determine if the domain is in a "confined"
state. If the libraries find the domain is in this state they call
unix_update and if the domain is not in the "confined" state the libraries
try to edit the shadow file directly. The first check performed by the pam
libraries is a test to see if the domain can read the shadow file. If this
passes no other checks are performed and the pam libraries take for granted
that the domain will be able to read and update the shadow file. The CLIP
policy allowed the su derived domains to read the shadow file and because of
this the domains tried to edit the shadow file directly resulting in the
errors you have seen.

I have fixed both of these issues in revision 285 in trunk and will issue
new policy RPMS later this week. I have also moved some things around in the
policy to be more consistent with upstream reference policy. If you have
time, I'd appreciate it if you would confirm that this does indeed solve
your problems.

Regards,
Brandon 



> 
>>  
>>  
>> 
>>  From: Brandon Whalen  [mailto:bwhalen at tresys.com]
>> Sent: 06 May 2009 15:35
>> To:  Julian Onions; clip at oss.tresys.com
>> Subject: Re: [Clip] Root lock  out
>> 
>>  
>> Julian,
>> 
>> It appears that the su policy does not  have the permissions to allow users
>> to update their passwords, only to check  them. If you have a patch, I¹d be
>> willing to review and possibly accept it.  Otherwise, I¹ll spend some time
>> today and tomorrow writing one and update our  release once I¹ve tested it
>> all out.
>> 
>> Brandon
>> 
>> 
>> On 5/6/09 9:03  AM, "Julian Onions" <Julian.Onions at nexor.com>  wrote:
>> 
>>  
>>> Anyone have any  ideas on this one that we've just tripped over.
>>> 
>>> After installing a clip  system, we age the password of root to force it to
>>> be changed
>>> chage -d 0  root
>>> However when attempting to su to root now, you are forced to change  your
>>> password, as expected.
>>> However this fails because sysadm_su_t is not  allowed access to crack_db_t
>>> - also doesn't have access to shadow_t and a  number of others things it
>>> needs.
>>> I was wondering therefore how to get  around this.
>>> Also - where does the transition from sysadm_su_t to  sysadm_t happen?
>>> 
>>> Thanks
>>> Julian
>>> 
>>> DISCLAIMER: Privileged or confidential information may be  contained in this
>>> message or within any files transmitted with it.  If  you are not the
>>> intended recipient, kindly destroy the message and notify  the sender by
>>> reply email.  Opinions, conclusions and other information  in this message
>>> that do not relate to the official business of Nexor are  neither given nor
>>> endorsed by it.
>>> 
>>> 
>>>  
>>> 
>>>  _______________________________________________
>>> Clip  mailing list
>>> Clip at oss.tresys.com
>>> http://oss.tresys.com/mailman/listinfo/clip
>> 
>> Brandon Whalen         Tresys Technology
>> v: 443-539-0747        Suite 2100
>> f: 410-953-0494        8840 Stanford Blvd
>> bwhalen at tresys.com    Columbia,  MD 21045
>> 
>