[Clip] Root lock out
Julian.Onions at nexor.com
Wed May 20 02:57:47 CDT 2009
> I've just merged this into our policy - and it seems to fix
> the issue nicely.
> Many thanks,
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
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
> > -----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
> > and sometimes they don't when a user needs to update their
> > 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
More information about the Clip