Re: LYNX-DEV Improvement on /tmp code fix?

[Jim Dennis]

> Tom commented:
>  ] not all systems support 3-parameter 'open()' - probably not a lot anymore,
>  ] but they exist - and some of them are prototyped (I remember being bitten
>  ] by that).  we'll have to work around this at some point - though I agree
>  ] in principle with what you're suggesting, the details aren't right yet.
> 
> I remembered you having said that in another message.  It seems to me that
> a #define for such systems (or a -D on the command line) and an fchmod()
> would solve the problem.
> 
> Are these systems like the mythical ones that lynx compiles on that
> don't support symbolic links, or the mythical ones that lynx compiles
> on that don't support sticky directories?  Just curious.  Examples,
> revised Makefile targets, and a few #ifdef sets are all that's needed.
> 
> I'm trying to figure out how fdopen() could possibly help, though; I
> don't need it for fchmod.
> 
> I don't need a stream for the thing in tempname(), and I don't care
> about the exclusive stuff in the rest of the program if I know the
> file is mode 0600 and others can't remove it.
> 
> ...
> 
> I just realized that to make the "safe place checks" appropriate, I also
> need to stat the parents of lynx_temp_space up to the root (well, the
> other direction would be safer) and perform the same checks on them 
> (and confirm that they're all owned by a uid <100 [i.e. system directories 
> of some sort] or the user)...  
> 
> If I could access the stuff at the URL I posted in my last message 
> comfortably I could probably manage to get this here modem to behave 
> so I could log in without having to boot into MS-DOS (ack!), and I'd 
> send another patch.
> 
> Here's something for some sort of documentation on the error message
> that my patch generates for unsafe temp spaces:
> 
> ------------------------------------------------------------------------
> *** ALERT *** Your temp space may be unsafe! Contact your administrator.
> 
> Users who get this message should contact their system administrators
> to fix the problem, described below.
> 
> System administrators:
> 
> If you get this message, it means that the location in which Lynx was
> instructed to store temporary files is not safe (i.e. it may be 
> possible for other users to overwrite things that users download or
> even other files they own on the system).  To get rid of this message,
> you need to change the temp space to a safe place.  Usually, the
> /tmp directory is a safe place to put temporary files; however, if 
> the /tmp directory isn't a "sticky directory", it is possible for
> one user to erase files (in /tmp!) owned by other users.  If your
> system supports "sticky directories" then set the sticky bit on
> /tmp ("chmod +t /tmp").
> 
> If for some reason making /tmp sticky is not an option, you are
> advised to use individual temporary directories per user.  To do
> this, you'll need to instruct Lynx to store temporary files in
> a directory such as "~/.lynx" or "/tmp/$USER".  You can instruct
> Lynx to use a different directory by either (a) setting the
> LYNX_TEMP_SPACE environment variable to the name of the directory
> to use, or (b) editing the "userdefs.h" file in the Lynx source
> distribution and editing the "#define TEMP_SPACE" line, then 
> recompiling Lynx.
> 
> You can edit the tempname() function in LYUtils.c if you want to
> bypass this security precaution, however it is dangerous and you
> ought not do so unless you understand the implications of it.


        Matt Bishop (U. C. Davis) wrote some functions 
        to replace system(), and popen() and also wrote a
        trustfile() function.  These are intended to provide
        better security and are used as samples in his
        lectures on data security tools.

        You can find these at:
                Matt Bishop's Security Tools Archive
                        ftp://nob.cs.ucdavis.edu/pub/sec-tools

        He's given seminars at USENIX (this year) and
        SANS (recently) and is considered to be an expert in 
        the field.  Perhaps it would be worth taking a look 
        as his code and using it.  (I think the copyright allows
        it).

        His version of 'trustfile()' checks the entire path from
        root to the file link against a set of permissions and 
        ownerships that you specify prior to calling the function.
        This prevents race conditions where some directory component
        (possibly several levels up from your link) might be manipulated.

        I've seen considerable traffic regarding mktemp() and friends
        on the Bugtraq mailing list and others -- I'm sure we could
        search the archives there for a consensus as to the most 
        portable and safe approach.

--
Jim Dennis,                                address@hidden
Proprietor,                          address@hidden
Starshine Technical Services              http://www.starshine.org

        PGP  1024/2ABF03B1 Jim Dennis <address@hidden>
        Key fingerprint =  2524E3FEF0922A84  A27BDEDB38EBB95A 
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;