Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 113211 - should login have pam_securetty as requisite?
should login have pam_securetty as requisite?
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: util-linux (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
Ben Levenson
: Security
Depends On:
  Show dependency treegraph
Reported: 2004-01-09 14:15 EST by Steve Bonneville
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-02-20 14:24:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Steve Bonneville 2004-01-09 14:15:06 EST
In /etc/pam.d/login, the auth management group reads:
  auth  required  pam_securetty.so
  auth  required  pam_stack.so service=system-auth
  auth  required  pam_nologin.so

I was discussing this with johnsonm, and my understanding is that the
original intent here was that if root is attempting to log in from a
insecure terminal, authentication should fail before root exposes the
root password over the wire.  That would imply that pam_securetty.so
should be requisite (to fail immediately), not required (which causes
authentication to fall through to system-auth and a password prompt,
even though PAM knows it will fail).

The obvious counter-argument is that by using requisite, it would leak
information about why root authentication on an insecure terminal is
failing, which is why we don't use requisite anywhere now.

I'm filing this bug to make sure that the current configuration is

Version-Release number of selected component (if applicable):
  util-linux-2.11y-31.1 (at least)
Comment 1 Elliot Lee 2004-02-20 14:24:07 EST
It's a tradeoff between transmitting the root password in the clear,
and transmitting the fact that we're using securetty to anyone who
wants it.

Since the latter is something anyone would reasonably assume anyways,
and the former is a very secret piece of information, I'd have to say
that the present setup makes more sense.

Note You need to log in before you can comment on or make changes to this bug.