From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id C511413829C for ; Tue, 31 May 2016 21:02:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0AB78254051; Tue, 31 May 2016 21:02:03 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8C9E321C039 for ; Tue, 31 May 2016 21:02:01 +0000 (UTC) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7A6D620729 for ; Tue, 31 May 2016 17:02:00 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Tue, 31 May 2016 17:02:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=trystero.is; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=B9X7npQUlp2fszt0CrOt6eMq4l4=; b=X2rFY0 NJgkneSZSPa06gY2LySDwSA4TIyG5vyi1jzD0UmQkwtDm1Qdh91Me8wpXQLGkbKV 8VlTQMRUy8Weaa0YaH151uh3aDLSHf8AFNeDYGUEa+RTrTeNUAXydMDsPAMZhdEc qMCxLVeqGo94z7rQAo3rM0y0PsGNIz8AQbNgk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=B9X7npQUlp2fszt 0CrOt6eMq4l4=; b=koRRInY+0WivEhGEt+ud0njJx72R210RYaf3beqfxkatr6T BrDDINd0S1NrnIPbPGniQd2uiI/YiwJKRZgCorp3f6l1DJn1l/9bUslweZzCn6Hh Ht20L8Y1tolJ5nbdNOvLgYgnuGgHynTirr8gar1ge/CCzlkBsSrtiM2wjUXM= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4ADB21E38D; Tue, 31 May 2016 17:02:00 -0400 (EDT) Message-Id: <1464728520.2608374.624071985.174A476B@webmail.messagingengine.com> X-Sasl-Enc: U8cTKQLwKnXBNSHpdmuGIci5T2DGSBHyllrlviFv9cND 1464728520 From: "Max R.D. Parmer" To: gentoo-user@lists.gentoo.org Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e26fc460 Subject: Re: [gentoo-user] CoreOS vulnerability inherited from Gentoo? Date: Tue, 31 May 2016 14:02:00 -0700 In-Reply-To: <1464718053.2574116.623884473.5DE11FA8@webmail.messagingengine.com> References: <3181100.83d2K62WRd@dell_xps> <1464718053.2574116.623884473.5DE11FA8@webmail.messagingengine.com> X-Archives-Salt: 826d90f8-81c9-43c5-803d-e4d358e2ae8b X-Archives-Hash: 5952b661bfb27492bd39484354ff807a 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:: > > >=20 > > > Security brief: CoreOS Linux Alpha remote SSH issue > > > May 19, 2016 =C2=B7 By Matthew Garrett > > >=20 > > > > > >=20 > > > Gentoo defaults to ending the PAM configuration with an optional pam_= permit. > > >=20 > > > This meant that failing both pam_unix and pam_sss on CoreOS systems w= ould > > > surprisingly result in authentication succeeding, and access being gr= anted. > > >=20 > > > The operator user was not used by CoreOS, but existed because it exis= ts in > > > the Gentoo Portage system from which CoreOS is derived. > > > > > >=20 > > > Full read [1]. It kinda shows that CoreOS is derived from Gentoo > > > and not ChromeOS; at least when time to blame a security lapse elsewh= ere.... > > >=20 > > >=20 > > > enjoy, > > > James > > >=20 > > > [1] https://coreos.com/blog/ > >=20 > > Does this mean we need to do anything to improve the security of our > > systems? >=20 > 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. >=20 > the pam_permit.so line was introduced here: > https://gitweb.gentoo.org/proj/pambase.git/commit/?id=3Dac9023eecfe3c13d2= 12c548bb9d5d1b42a4e044b >=20 > At the very least, it does seem like it ought to be pam_deny.so instead. >=20 > I wonder if this issue is still even relevant for Kerberos users? > https://bugs.gentoo.org/show_bug.cgi?id=3D333393=20 >=20 Yeah -- doesn't work with a locked or expired account either.