[Clip] Root lock out

[Julian Onions]

> I've just merged this into our policy - and it seems to fix 
> the issue nicely. 
> 
> Many thanks,
> Julian. 

Um - I may have spoke prematurely (read running in permissive - slight
red face). I think now that although things have changed, we are still
getting a similar issue. Both on su, and login for an expired account
still.

I'll continue to look into it, but I don't think it does fix the issue
after all. I'll send you some data when I get a more consistant picture


Julian.

> 
> > -----Original Message-----
> > From: Brandon Whalen [mailto:bwhalen at tresys.com]
> > Sent: 19 May 2009 20:06
> > To: Julian Onions; clip at oss.tresys.com
> > Subject: Re: [Clip] Root lock out
> > 
> > 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
> 
> _______________________________________________
> Clip mailing list
> Clip at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/clip
>