Re: solaris tape dev permission stupidity (fwd)

[jg () FALSE NET (joshua grubman)]

more info re: sun's BSM package.


---
josh grubman / http://false.net/~jg
"if you don't ask, i won't upset you"

---------- Forwarded message ----------
Date: Thu, 22 Oct 1998 09:32:49 -0700 (PDT)
From: Brad Powell <Brad.Powell () Eng Sun COM>
To: jg () false net
Subject: Re: solaris tape dev permission stupidity


> From jg () false net  Thu Oct 22 09:00:42 1998
>
> /etc/logindevperm doesn't affect removable media - only login devices ;)

login runs suid root. It can change permissions on any file/device.

This way at login time the ownweship of /dev/mt* or whatever can be set
to the user who owns the "console" . Agreed this doen't work unless
either root or some other user is logged onto the "console" but it does
protect desktop systems from remote users.

An old trick was to snarf the /etc/shadow file from a servers backup tape after
logging in as a normal user if the admin left a tape in the device for automated
tape backup. :-)

Unattended tapes are like NFS exports to "everyone" (or NT shares ;^})
bad juju.


> the basic security module package allows you te correct this (changing perms
> upon removable media insertion)

true, thats a little better but still not bullet proof.

and breakes if a new user has access to "console" :-). Scenario; bsm user
inserts tape (ownership is then set to them) but if he/she isn't at the
"console" any user that logs onto the "console" can get the permissions set
to them (with logindevperm) Sort of far-fetched, but shows one utility
overriding another.

Maybe splitting hairs, but the BSM/logindevperm both work for single user
systems (common desktops/laptops). But start to fall apart when we talk about
multi-user logins to the same system. In those cases, I guess most of /dev/
should be root owned mode 600 or whatever umask is set to.

> but it still leaves a default installation
> wide open.

it has to (well no it doesn't; your right) it doesn't matter too much who
"owns" the removal media device until something is put into it. Of course
having a suid root binary on a removable media device that by default doesn't
mount the device 'nosuid' is another can of worms ;-)


No good answers I'm afraid for a system where you can't trust users, and don't
authenticate users strongly to make sure they _are_ your users :-\
(can you tell i'm a fan of non-reuseable passwords and encrypted/non-hijackable
 sessions?) :-)

I guess in a long winded way I'm agreeing with you.


=======================================================================
Brad Powell : brad.powell () Sun COM
Sr. Network Security Architect
Sun Microsystems Inc.
=======================================================================
               The views expressed are those of the author and may
                  not reflect the views of Sun Microsystems Inc.
=======================================================================