Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 2617 - console.perms probably shouldn't be enabled by default
Summary: console.perms probably shouldn't be enabled by default
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pam
Version: 6.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
URL:
Whiteboard:
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:
Clone Of:
Environment:
Last Closed: 1999-07-30 15:23:23 UTC


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.