Subject: Re: PAM proposal
To: Roland Dowdeswell <email@example.com>
From: Daniel Carosone <firstname.lastname@example.org>
Date: 05/08/2005 08:25:19
Content-Type: text/plain; charset=us-ascii
On Sat, May 07, 2005 at 11:22:57AM -0400, Roland Dowdeswell wrote:
> The language describing the PAM keywords is rather confusing, so
> I will construct a table of how [our] PAM works. The four columns
> continue:F will continue on failure
> S will continue on success
> can succeed sets the ``can succeed'' flag
=2E.. *on success*
> force deny sets the ``will be denied'' flag
=2E.. *on failure*
> requests which make it through the stack will succeed if both
> the ``can succeed'' flag is set and the ``force deny'' flag is
> not set.
> So, here is how I read our current set of keywords:
> keyword continue:F S can succeed force deny
> ------- ---------- - ----------- ----------
> required yes yes yes yes
> requisite no yes yes yes
> sufficient yes yes yes no
> optional yes yes no no
> binding yes no yes yes
At last this makes sense to me! Please add this to the documentation. =20
Well, almost: 'optional' seems like a NOP to me in this table, useless
unless it's there so the module can have some side-effects? What might
> Now, if we consider a module such as pam_nologin.so, none of
> those definitions make sense. We really want something like:
> X yes yes no yes
> which is unrepresented in the table.
(are there other unrepresented combinations that might be useful?)
> If a system administrator naively comments out pam_unix.so, then
> anyone can log into the system at any time---so we still have a
> system which can [sort of] fail open.
We have a security system where even smart, experienced security
experts are left scratching their heads and drawing truth tables and
wondering what will really happen, even if they think they've figured
it out. That includes possibly failing open, but even if it doesn't
it is still not right.
> This, IMO, needs to be fixed. So, we can take either one of two
> paths. The first would be to come up with a PAM configuration
> syntax which has some semblence of sanity. This would diverge from
> the standards which would be unfortunate.=20
It would. There are a lot of people using this syntax, sane or
otherwise. I'd like to avoid that divergence too.
If the standards are broken beyond repair, we should diverge from them
without fear, but in doing so we should make it clear (perhaps by
using a different syntax entirely) that people used to other systems
should not expect the same behaviour here, otherwise we have a
different form of the same understanding problem.
One such change which would make it less confusing is to have two
columns for keywords, one to describe the four possible continuation
behaviours, another to describe the four possible flag-setting
behaviours. This would also inherently eliminate the 'no keyword for
the behaviour I want' cases, like above.
For example, the meanings of 'required/necessary/sufficient/optional'
are much clearer if they're only encoding the 'can succeed/force deny'
columns, and some new keywords encode the continuation behaviour.
> The other would be to
> change the semantics of a keyword or add a keyword.
> I think that it might be a better idea to just extend the current
> syntax to include an additional keyword ``neccessary'' which would
> specifically not imply any kind of sufficiency.
Yep, I like this, within the current context/syntax.
> ``Necessary'' might be a bad choice of words, but at this point I
> think that all of the words except sufficient and optional are poor
I agree with this entirely. As I suggest above, there is too much
information encoded into a single english word. =20
If we are to diverge, either we split the encoding, or we make it more
explicit (less dependent on english interpretation).
Since I find your table quite helpful, I would be tempted to suggest
that we change the syntax to match the table and allow all
possibilities. Either by having four new columns in place of the
current 'keyword', two columns as above, or by defining a system of
names that encodes the table more directly than the english keywords,
and adding them as aliases alongside the current ones as a compatible
extension to the current syntax.
as a simple straw-man suggestion, a four-character ls-alike:
c: continue -: don't
s: can succced f: force deny
keyword c:F c:S can succeed force deny
------- --- --- ----------- ----------
required =3D ccsf yes yes yes yes
requisite =3D -csf no yes yes yes
sufficient =3D ccs- yes yes yes no
optional =3D cc-- yes yes no no
binding =3D c-sf yes no yes yes
I'm not sure this is great either, but at least I don't have to spend
several minutes thinking about the difference between 'required' and
'requisite', or 'requisite' and 'binding' each time - and worse, if
there are more keywords added, or I'm not a native English speaker.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)
-----END PGP SIGNATURE-----