Mailinglist Archive: opensuse-security (471 mails)

< Previous Next >
Re: [suse-security] /dev permissions get changed
  • From: Roman Drahtmueller <draht@xxxxxxx>
  • Date: Thu, 26 Oct 2000 05:25:02 +0200 (MEST)
  • Message-id: <Pine.LNX.4.21.0010260213480.29485-100000@xxxxxxxxxxxx>
> so this is a good idea and it makes sense, but what it means that i cannot
> use the cdrom for instance from an ssh console if i wasn't the user last
> logged in physically? of course, we don't really want this, because then
> i could freely do whatever i wish with the floppy of someone else.

Right.

> my question then (considering that i will probably go ahead and amend
> /etc/security/console.perms appropriately) is how suse handles this. so on
> a suse system, what determines what to do if a ssh user and a console user
> both request /dev/ttyS0 write access, and how will this situation be handled?

One of the reasons why we didn't include the pam_console thingy was that
it may be very hard to tell if a user is logged on on the physical console
(eg you have to check $DISPLAY of the process which logs in a user. If it
isn't local, then the user could have come through an X -query X-session.).

Even without that mechanism it's difficult to chmod or chown a floppy
device or even worse, a cdrom device. If the user changes his IDE setup
and reconfigures his /dev/cdrom symlink, we'd end up with a world-open
hard disk device file which equals to root for just about anybody
capable(READ_MANUAL). Also, what do you do if a user has been logged on to
the console but left behind a process with /dev/vcs1 open, mmap()ed or
reading from it?

Currently, SuSE does chown(),chmod() /dev/tty? within /bin/login after
execve() from mingetty. mingetty does chmod,chown back to root.tty(660).
/dev/vcs? are not touched, the code in login.c is present, but #if'ed 0.

Today's applications using pseudo terminals such as xterm and alike use
the devpts mechanism from glibc + kernel. It works by opening /dev/ptmx
and getting back a valid fd for a master terminal device file, whereas the
name of which can also be obtained. It doesn't require any privs, because
the terminal file is owned by the current fsuid of the opening process
already.

/dev/cdrom, /dev/audio, /dev/dsp or /dev/fb and alike aren't touched in a
SuSE system yet. This might be subject to a change soon... Currently,
mounting a cdrom drive is possible for all users. The filesystem will then
be mounted nosuid,nodev and the files will be owned by the user. See
/etc/fstab, look for "user". audio devices are wide open, which I don't
find too irritating.

Roman.
--
- -
| Roman Drahtm├╝ller <draht@xxxxxxx> "Caution: Cape does not |
SuSE GmbH - Security enable user to fly."
| N├╝rnberg, Germany (Batman Costume warning label) |
- -




< Previous Next >
References