Date:   Sun, 23 Dec 2018 11:46:48 +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: <20181223104648.GB20992@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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="rS8CxjVDS/+yyDmU"
Content-Disposition: inline
In-Reply-To: <20181223102000.GA20992@brutus.lan>
User-Agent: Every email client sucks, this one just sucks less.
Sender: selinux-refpolicy-owner@vger.kernel.org
Precedence: bulk


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

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/fail=
lock
> > >> (which is labeled faillog_t).  sudo and xdm (and probably other doma=
ins)
> > >> will create files in this directory for successful and failed logins
> > >> 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 interf=
ace was forgotten and not updated properly.
> > >
> > > So for example sudo does not even call auth_use_pam() and a lot of st=
uff was added directly to the login_pgm domain that should have been added =
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 what =
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 update=
=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 d=
o logins
>=20
> sudo uses pam but its not a real login program, so afaik sudo should call=
 auth_use_pam()
> xdm is a login_pgm, so is sshd etc
>=20
> systemd is also a pam client, but not a login program

And yes systemd needs to be able to create these /run/faillock/USER files a=
s well, but if you test this on RHEL then you wont see it because
RHEL doesnt use /etc/pam.d/systemd-user (i suppose)

so:

1. auth_use_pam() =3D=3D "pam clients" (programs that have a file in /etc/p=
am.d), they use pam for authentication of some sort
2, auth_login_pgm_domain() =3D=3D superset (special pam clients that need p=
ermissions to do actual logins)

>=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=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

--rS8CxjVDS/+yyDmU
Content-Type: application/pgp-signature; name="signature.asc"

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

iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlwfZ5QACgkQJXSOVTf5
R2m3sAv/SJ7rc0yh+0AxGjEp9TUiLM2lgfFa3gIV7nw8X6M8NKy7T/+35uJC6i+U
X7fRUgSaSc7N+ag18NvpHhUoaqyPaIIHTi69gig9ri9EziEGtnZM8RhK+gMrNxAP
Rs7ELshUDclr6lXEFXJaWvF0jv9CQT8lnpAndVvpwfVKzCNzcpBdO/pN52CmPrrP
J+eA+y4n2cV/rWtjECILpjUGpkuDmfIhPiLPgrWC9Dz0r/CjOk8IQjFE60jxwb0Z
8G47u5lyFqVOzeVbqAG71d4HWJCmKz7xSxyC5iNHXrq0ED0Q8HRWM1/MCpuCHNzJ
pPYzeSZnbvlGSUHbG2Occ7PuRawFBxz0ypWYOzNHv62gC5jz8jvgmqqZgwu928+r
FSdfTBi+Jp+RZmfbHD+9i9lrZTojZTuwaM0j7f2KVNcovDsdrQZFaBsgEIx8aoYe
3iCfPtO56CDN8vTba0SvCgYEkrWiZIxqB3JHcyTiSbct22K9fpmjvymRhHMd319v
iC5RMUb2
=j5ep
-----END PGP SIGNATURE-----

--rS8CxjVDS/+yyDmU--