Re: privacy on unix [was: Re: LYNX-DEV fotemods.zip update]

[Matthew Kelly]

On Thu, 22 May 1997, Filip M Gieszczykiewicz wrote:
> You (Nelson Henry Eric) wrote:
> > >   As far as "privacy" issues associated with the Unix /tmp
> > > design are concerned, even systems which now have the "sticky bit"
> > > feature typically don't use it.  I've yet to get on a Unix system
> > > in which I couldn't read any file in the /tmp tree, and there was
> > > no need for spoofing via links to do it. :) :)
> > 
> > This is disturbing.  Just to be sure, you are talking about systems
> > which have implemented neither the `sticky bit' nor subdirectories
> > with write permission only to the owner?  Since installing Screen,
> [snip]
> 
> Greetings. This probably happens on the former system because there
> hasn't been some great incident to warrant the sysadmin to whip
> the system into shape... and their policy doesn't cover it (yet). My
> systems (my ISPs and my own) all have user-only access to /tmp files
> and this spans SunOS, Linux, Solaris so NOT having this setup on
> any system is IMHO just plain carelessness... Someday there will be
> a lawsuit pending for this :-) "You're fired for owning "those"
> pictures of little boys".... "but I though my files were private?"
> "yeah, but we're an incompetant bunch of morons... duh duh duh" 

As far as I know, Solaris now ships with /tmp sticky ... There was an
exploit a while back in the OS that relied on the fact that /tmp wasn't
sticky and the security fix from Sun was to make /tmp sticky.

Ideally I think the way to make sure things are secure is to when creating
/tmp files is to (1) make sure they're created 0600 permissions and (2)
keep the filedescriptor open.  Even if the file is then renamed by another
user or deleted by another user we are still guaranteed to get the same
file.  (3) we can also unlink the file right after creating it,
eliminating another problem mentioned in the thread whereby temp files
linger around when users don't quit properly.

We seem to be past the initial scare, we now have accomadations sysadmins
can make to ensure the current version of lynx is safe -- why not make the
final product safe so that no steps are required?  There is no way of
creating files in a subdir in /tmp that will be safe if creating files in
/tmp isn't safe (ie mkstemp idea), since the subdir can just be renamed.
There's only telling people to use their homedirs, or making lynx keep the
fd's open. (unless I'm missing something big)

thoughts?

Matt

-------------------------------------------------------------------------
Matthew Kelly
address@hidden

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;