Re: [gentoo-user] CoreOS vulnerability inherited from Gentoo?

[Max R.D. Parmer]

On Tue, May 31, 2016, at 11:07, Max R.D. Parmer wrote:
> On Tue, May 31, 2016, at 10:44, Mick wrote:
> > On Tuesday 31 May 2016 16:30:27 James wrote:
> > >  Here is an interesting read::
> > >
> > > Security brief: CoreOS Linux Alpha remote SSH issue
> > > May 19, 2016 · By Matthew Garrett
> > >
> > > <snippets>
> > >
> > > Gentoo defaults to ending the PAM configuration with an optional pam_permit.
> > >
> > > This meant that failing both pam_unix and pam_sss on CoreOS systems would
> > > surprisingly result in authentication succeeding, and access being granted.
> > >
> > > The operator user was not used by CoreOS, but existed because it exists in
> > > the Gentoo Portage system from which CoreOS is derived.
> > > <end/snippets>
> > >
> > > Full read [1]. It kinda shows that CoreOS is derived from Gentoo
> > > and not ChromeOS; at least when time to blame a security lapse elsewhere....
> > >
> > >
> > > enjoy,
> > > James
> > >
> > > [1] https://coreos.com/blog/
> >
> > Does this mean we need to do anything to improve the security of our
> > systems?
>
> The interaction seems to be problematic when SSSD is introduced to the
> mix, as the SSSD documentation seems to assume a fallthrough to
> pam_permit.so. With a merely empty user password, I cannot trigger this
> issue. I will have to try with an expired account and a locked account
> later.
>
> the pam_permit.so line was introduced here:
> https://gitweb.gentoo.org/proj/pambase.git/commit/?id=ac9023eecfe3c13d212c548bb9d5d1b42a4e044b
>
> At the very least, it does seem like it ought to be pam_deny.so instead.
>
> I wonder if this issue is still even relevant for Kerberos users?
> https://bugs.gentoo.org/show_bug.cgi?id=333393
>

Yeah -- doesn't work with a locked or expired account either.