Re: Any Account Logs In With Any Password
On Wed, 27 Oct 2010, Jordon Bedwell wrote:
> On 10/27/2010 04:05 PM, Henrique de Moraes Holschuh wrote:
> > On Mon, 25 Oct 2010, Michael Loftis wrote:
> >> checks prior to this indicate a soft success. If you remove
> >> authentication from your system, its expected that any attempt to
> >> access will pass, barring and specific denial.
> >
> > If I remove authentication from my system, I expect it to tell me to get
> > lost, as that is the _only_ safe failure scenario. Recovery is supposed to
> > be done through single-user mode and sulogin in that case (if you don't have
> > a root window already open somewhere, that is).
> >
> > This fail-unsafe behaviour looks like it is a "feature" of the default
> > config being shipped in /etc/pam.d/common-*. I wonder what is the
> > justification behind that decision...
Hmm, looking at it very carefully, it is not. common-auth defines pam_deny
as "requisite", and pam_permit as "required". This will *always* fail to
autenticate, i.e. it IS failing safe (to a locked state).
So, no, it is not a misfeature of the config being shipped.
Now, if you manage to mess with that pam_deny, then, all hell breaks lose
because the existence of that pam_permit disables libpam's internal
fail-safe. We would be better off without that pam_permit line at all, if
it is not important for some non-cosmetic reason (which it might well be! I
am wondering what the reason is, however).
But just commenting the pam_unix line should not be able to open the system
wide open.
> Wait, let me get this right. You have a *server running*, you then
> *remove authentication* on said server and then you *expect* the system
Remove authentication:
You explicitly configure pam to remove authentication. That means adding a
"sufficient pam_permit.so" at the right place, which is not something a typo
should cause.
Break authentication:
A typo.
Fail unsafe: system is now wide open. Security breaches are possible.
Fail safe: system is now locked down for new autentications, already
autenticated sessions keep working (and can be used to repair the system,
for example). Special procedures can be used to restore normal operation in
the worst case. No security breach happens because of the failure.
So, yes, it is supposed to fail to locked down state, and the more resilient
it is into failing to locked state when misconfigured (instead of opening
the system to unauthorized access), the better.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: