Bug 2617 - console.perms probably shouldn't be enabled by default
Summary: console.perms probably shouldn't be enabled by default
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pam   
(Show other bugs)
Version: 6.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
URL:
Whiteboard:
Keywords: Security
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-05-06 21:43 UTC by Chris Evans
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-07-30 15:23:23 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 Chris Evans 1999-05-06 21:43:55 UTC
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 14:38:59 UTC
This issue has been forwarded  to a developer for further action.

Comment 2 Cristian Gafton 1999-07-28 06:47:59 UTC
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 15:23:59 UTC
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.