[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Special dev access for users @ the console?



On Fri, Nov 03, 2000 at 02:05:44AM -0600, Michael Janssen (CS/MATH stud.) wrote:
> 
> Hello debian ppl! 
> 
> I am a lab admin.  I need to give access to the floppy (/dev/fd0), zip
> drive (/dev/hdd), and sound (/dev/dsp) to the person logged in at the
> console (x or tty).   If this was my personal machine, I would just
> put the users in the group console.  Unforfunately, this cannot be the
> case.  I have around 6500 users, and they are all able to login to
> these machines remotely.   While I agree it would be a good practical
> joke to start playing loud music in another room, it wouldn't be
> prudent in a lab setting.   I have similiar problems with the floppy
> and the zip (ide floppy version).. these devices would be even worse
> because another user could steal code from another (NOT GOOD!).   

why do you need to give out access to the floppy devices?  if you add:

/dev/fd0    /floppy 	auto	defaults,nosuid,nodev,noauto,user   0 0

then users can mount floppies and exclusive access.  there is a small
race condition between when the user physically inserts the floppy and
runs mount /floppy, but exploitation would be rather difficult. 

the only thing they would be unable to do is create filesystems on the
floppy or do low level formats.  but that should not be a problem most
of the time.  

audio devices are a bit more tricky, not sure what i can tell you
there.  once you give someone access they can keep that access as long
as they want, console or not.  screen can be used to create a detached
session maintaining group membership.  (assuming you installed things
correctly allowing you to set all user writable filesystems nosuid)
if you go the redhat way and chown the devices on login your still
screwed since the user can hold a file descriptor open maintaining
access.  

in short you must either trust them to have access permanatly or not
at all.  

> I was wondering if anyone had any solutions for me.  I have thought of
> two different solutions: 
> 
> 1) Use pam_console, compiled separately.   I don't really want to do
> this, because debian doesn't include the file for a reason: it's got a
> gaping security hole, users can hold open file descriptors on devices
> after they're not using a console (through screen, perhaps) and that
> basically makes the changing users a moot point. 

don't use pam_console, it does not buy you any security for reasons
above, and it includes /usr/bin/rootshellhelper giving users instant
root shells whenever they want.  (go look at bugtraq that lame package
has a new root whole every week it seems like) 

pam_console will only REDUCE security not enhance it. 

> 2) Use pam_group, and add them to a group when they're logged in on
> the console.  This works on ttys, I've read, but not on xdm sessions.
> It's important that it works in X because this is what most of our lab
> users (and newbies to linux sometimes, yay!) use most of the time.
> Forcing them to login to a tty isn't really desireable. 

are you sure it doesn't work with X?  i have not checked into it
recently... but again pam_group is not all that useful since it can be
defeated by creating a setgid shell (unless you partitioned correctly
and mount everything nosuid) or by a simple detached screen session.  

> My question is:  Does anyone have any other solutions?  Or can one of
> my solutions be modified to negate my problems with the solution? 

for floppy devices, just don't give them access to the raw devices, i
don't see any reason this won't work formatting disks is not that
common of a need IMO.  perhaps sudo can be configured to allow a
console login to format the device?  (im not sure if sudo allows for
tty restrictions) 

for audio devices i don't know what to tell you there, other then
write a daemon that has access to the sound devices and acts as a go
between, but that would probably be non-trivial to implement.
simplest solution: no sound access.  (albeit not a popular suggestion) 

what linux needs is revoke()

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

Attachment: pgpiiqCQLJoTk.pgp
Description: PGP signature


Reply to: