Re: [gentoo-user] CoreOS vulnerability inherited from Gentoo?
On Tue, 31 May 2016 18:44:10 +0100, Mick wrote: > > The operator user was not used by CoreOS, but existed because it > > exists in the Gentoo Portage system from which CoreOS is derived. > > > > > > 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 ChromeOS is based on Gentoo, so if CoreOS is based no ChromeOS it is a second generation Gentoo derivative. > Does this mean we need to do anything to improve the security of our > systems? The report seems to be saying that the problem is caused by using the Gentoo default config, which assumes a Gentoo environment. So it's fine on Gentoo. But it won't hurt to run glsa-check from time to time (my sync script does it every time and mails me if there's a problem). -- Neil Bothwick Everything else being equal, fat people use more soap. pgpy2izMXq6Lo.pgp Description: OpenPGP digital signature
Re: [gentoo-user] CoreOS vulnerability inherited from Gentoo?
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 > > > > > > > > > > > > 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. > > > > > > > > > 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=93 > Yeah -- doesn't work with a locked or expired account either.
Re: [gentoo-user] CoreOS vulnerability inherited from Gentoo?
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 > > > > > > > > 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. > > > > > > 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=93
Re: [gentoo-user] CoreOS vulnerability inherited from Gentoo?
On 05/31/2016 01:44 PM, 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 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. 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? I tried logging in as operator with any password, it did not work for me. Unsure if that's because of my SSH set up or not though. The blog post does however mention reverting their SSSD change did fix the issue, so I assume if you set up SSSD the same way they did you would have issues. With that being said, maybe it would be a good idea for the gentoo pam team to set up pambase to support SSSD and not cause issues. (Currently if you want to set up SSSD you are left to do it manually)
Re: [gentoo-user] CoreOS vulnerability inherited from Gentoo?
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 > > > > 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. > > > 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? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
