Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 2617 - console.perms probably shouldn't be enabled by default
console.perms probably shouldn't be enabled by default
Product: Red Hat Linux
Classification: Retired
Component: pam (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Michael K. Johnson
: Security
Depends On:
  Show dependency treegraph
Reported: 1999-05-06 17:43 EDT by Chris Evans
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1999-07-30 11:23:23 EDT
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 Chris Evans 1999-05-06 17:43:55 EDT
See the summary.

Giving the user lots of ownership of devices if he/she logs
on at the console is currently a BAD security issue. The
user can hold open fd's to the resource after they log out.
This may allow for snooping.

The problem will be fixed in the future when Linux gets a
revoke() system call

I think the console.perms is a great piece of work and makes
Redhat easy to use - but for security reasons it should
probably default to OFF.

Discussions welcome :-)
Comment 1 Jay Turner 1999-06-23 10:38:59 EDT
This issue has been forwarded  to a developer for further action.
Comment 2 Cristian Gafton 1999-07-28 02:47:59 EDT
assigned to johnsonm. I still have to see an exploit coming out of
somebody snooping on my sound card, but nevertheless, one can never
have too much security.
Comment 3 Michael K. Johnson 1999-07-30 11:23:59 EDT
It will remain enabled by default.  Users with physical access to
the machine can do all sorts of other things to compromise the
system, and because some of the guards against that are completely
out of our control (for example, bios passwords, locked cases, etc.),
it makes sense not to defend heavily against subtle attacks by
users with physical access by default.  We do explain, for those
who wish to secure their machines physically, how to turn this
service off.  We do so in our manual, in the online documentation,
and in a white paper on our website; in short, every documentation
avenue we have open to us.

When we have revoke(), I'll gladly look at putting it into the
pam_console close_session, but defaulting to a hard-to-use system
for no improvement in security (either practically or theoretically)
is not an improvement at all.

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