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.Powellat_private> To: jgat_private Subject: Re: solaris tape dev permission stupidity >From jgat_private 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.powellat_private 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. =======================================================================
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:20:37 PDT