[8253] in bugtraq
Re: solaris tape dev permission stupidity (fwd)
daemon@ATHENA.MIT.EDU (joshua grubman)
Fri Oct 23 14:52:17 1998
Date: Thu, 22 Oct 1998 12:39:03 -0400
Reply-To: joshua grubman <jg@FALSE.NET>
From: joshua grubman <jg@FALSE.NET>
To: BUGTRAQ@NETSPACE.ORG
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.
=======================================================================
