Bug 113211 - should login have pam_securetty as requisite?
Summary: should login have pam_securetty as requisite?
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: util-linux (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Elliot Lee
QA Contact: Ben Levenson
URL:
Whiteboard:
Keywords: Security
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-01-09 19:15 UTC by Steve Bonneville
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

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


Attachments (Terms of Use)

Description Steve Bonneville 2004-01-09 19:15:06 UTC
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
intentional.

Version-Release number of selected component (if applicable):
  util-linux-2.11y-31.1 (at least)

Comment 1 Elliot Lee 2004-02-20 19:24:07 UTC
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.