Date:   Sun, 23 Dec 2018 17:09:21 +0100
From:   Dominick Grift <dac.override@gmail.com>
To:     "Sugar, David" <dsugar@tresys.com>,
        "selinux-refpolicy@vger.kernel.org" 
        <selinux-refpolicy@vger.kernel.org>
Subject: Re: [PATCH 2/2] pam_faillock creates files in /run/faillock
Message-ID: <20181223160921.GD20992@brutus.lan>
Mail-Followup-To: "Sugar, David" <dsugar@tresys.com>,
        "selinux-refpolicy@vger.kernel.org" <selinux-refpolicy@vger.kernel.org>
References: <20181221014026.2867-1-dsugar@tresys.com>
 <20181221014026.2867-2-dsugar@tresys.com>
 <20181221103416.GA4520@brutus.lan>
 <2d2d6c7f-3084-d6f6-ce1b-42c9d9535969@tresys.com>
 <20181223102000.GA20992@brutus.lan>
 <20181223104648.GB20992@brutus.lan>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="C1iGAkRnbeBonpVg"
Content-Disposition: inline
In-Reply-To: <20181223104648.GB20992@brutus.lan>
User-Agent: Every email client sucks, this one just sucks less.
Sender: selinux-refpolicy-owner@vger.kernel.org
Precedence: bulk


--C1iGAkRnbeBonpVg
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 23, 2018 at 11:46:48AM +0100, Dominick Grift wrote:
> On Sun, Dec 23, 2018 at 11:20:00AM +0100, Dominick Grift wrote:
> > On Sat, Dec 22, 2018 at 02:58:41AM +0000, Sugar, David wrote:
> > >=20
> > > On 12/21/18 5:34 AM, Dominick Grift wrote:
> > > > On Fri, Dec 21, 2018 at 01:41:25AM +0000, David Sugar wrote:
> > > >> These are changes needed when pam_fallock created files in /run/fa=
illock
> > > >> (which is labeled faillog_t).  sudo and xdm (and probably other do=
mains)
> > > >> will create files in this directory for successful and failed logi=
ns
> > > >> attempts.
> > > > The pam stuff has become a bit broken in my view.
> > > >
> > > > We use to use auth_use_pam() for these kinds of things but the inte=
rface was forgotten and not updated properly.
> > > >
> > > > So for example sudo does not even call auth_use_pam() and a lot of =
stuff was added directly to the login_pgm domain that should have been adde=
d to auth_use_pam() instead.
> > > >
> > > > My opinion is that this belongs in auth_use_pam()
> > >=20
> > > Dominick,
> > >=20
> > > I see those interfaces.=A0 It looks like xdm_t already uses=20
> > > auth_login_pgm_domain(xdm_t).=A0 It also isn't really clear to me wha=
t the=20
> > > difference is between auth_login_pgm_domain() and auth_use_pam().=A0 =
I=20
> > > will make updates moving my change into auth_use_pam() and also updat=
e=20
> > > sudo_role_template() to use (I think) auth_login_pgm_domain ().
> >=20
> > sudo is not an auth_login_pgm_domain() i believe
> >=20
> > the auth_use_pam() is a subset of auth_login_pgm_domain()
> >=20
> > so login_pgm domains are pam clients plus extras needed to log in users
> >=20
> > a auth_use_pam() (pam client) has a pam stack but it might not actually=
 do logins
> >=20
> > sudo uses pam but its not a real login program, so afaik sudo should ca=
ll auth_use_pam()
> > xdm is a login_pgm, so is sshd etc
> >=20
> > systemd is also a pam client, but not a login program
>=20
> And yes systemd needs to be able to create these /run/faillock/USER files=
 as well, but if you test this on RHEL then you wont see it because
> RHEL doesnt use /etc/pam.d/systemd-user (i suppose)
>=20
> so:
>=20
> 1. auth_use_pam() =3D=3D "pam clients" (programs that have a file in /etc=
/pam.d), they use pam for authentication of some sort
> 2, auth_login_pgm_domain() =3D=3D superset (special pam clients that need=
 permissions to do actual logins)

Another interesting detail is that pam_faillock clients need cap_dac_overri=
de to be able to write records to /run/faillock/USER files
I wonder whether that is a bug

for example sshd (root) creates /run/faillock/joe with joe.root and 0600 bu=
t then sshd (root) needs cap_dac_override to write records to that file
Probably should have created the files with 0660 ... to avoid the need for =
cap_dac_override...

>=20
> >=20
> > >=20
> > > I will resubmit this patch,
> > >=20
> > > --- snip ---
> >=20
> > --=20
> > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6=
B02
> > Dominick Grift
>=20
>=20
>=20
> --=20
> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02
> Dominick Grift


--=20
Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02
Dominick Grift

--C1iGAkRnbeBonpVg
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlwfsy0ACgkQJXSOVTf5
R2kaigwAu/MITcNOJg6hu3QeXPLeZbjYLatZDw0Gl+XyQTnJgGtANBdjUeTkfKsW
tZAViYQ0Fj+L6hJSTPn8U5HGDt2vyOS+1Jvc1IU5HZ8xcAEz63s1OwJa4de+plrW
JwryK/VveW5kCpNcN1D2aj3K8JUlx/GMba4RcKizfgBIFJ1scbSVn/EvFlgGq1xo
WEsP9ET5IEVE/mvUk6djEu1aHkQvnlzXAdvG0NARQVZhXTvdcTSsz1/lZKWv1paW
NoP9U2mLQZfAjT1inIIWORnNAGJtSrHTydXJnsH3gR0N/x9zDkpRvq4+xk7iCfpy
EAiMmJAJcW4YTx/9OfosSyZCMsa4TRlvOpaPvQaGQPM638nbbZ8w7cINN2qamd8X
IpZz0QnKgKW99SVlbXfEWObRFWZl2Ue5cVspgoQwiLedpZ+CMZsqrGLYS1xjSZvF
+W02glbiOnqmLJiaB360DFsCuL0OWmObaHXLRfT8BJvqFUKgAi7OrpEs2OvKX2Ud
oIor5+Rz
=QyZ7
-----END PGP SIGNATURE-----

--C1iGAkRnbeBonpVg--