Is /tmp still appropriate? (was Re: [hacksware]Pine temporary file hijacking vulnerability)

[Andrew Church <achurch () ACHURCH ORG>]

> I do not really think the problem is this.  /tmp is there for a reason,
> and I don't really find any fault in vendors/developers for using it
> accordingly.

     This has always been my initial reaction to complaints about /tmp
vulnerabilities.  But it occurred to me:  Is /tmp, perhaps, no longer
appropriate to keep around in today's Internet?

     The world-writable /tmp we all know and {love,hate} was created way
back before the Internet was anything like it is today (I assume--I wasn't
around back then), back when antisocial people didn't have access to the
systems, much less knowledge of how to break them.  If all programs on the
system cooperate, then--even if they're poorly designed--nothing will go
wrong.  But these days with practically every system networked to some
extent and rootkits coming out the wazoo, that assumption is clearly one
that can no longer be made.  And if we can't assume that programs (or
users) will cooperate with each other, can we really justify having any
sort of shared-write directory around?

     I haven't decided what my own opinion is on this yet, and I can see
solutions that allow a shared /tmp with unsafe programs (such as
disallowing creation of links or special files, or the "hlfsd" another
poster mentioned), but at any rate I think it's an issue that merits some
thought.

> I think the real problem here is the use of '$$' in temporary file
> creation.  mkstemp(3) is there for a reason:
>
> NAME
>       mkstemp - create a unique temporary file

     Even without this, proper coding will give you safe temporary files:
open("/tmp/unsafe_and_obvious_filename", O_RDWR | O_CREAT | O_EXCL, 0600)
This could be another solution to the /tmp problem, but given the general
lack of security consciousness "out there", I think we need to look for a
solution that can be implemented on the sysadmin's end without needing to
hack a bunch of proprietary and/or massive software.

  --Andrew Church
    achurch () achurch org | New address - please note.
    http://achurch.org/ | $B%a!<%k%"%I%l%9$,JQ$o$j$^$7$?!#(B

> Just my $.02. :)
>
> Cheers,
> Ryan
>
> +-- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --+
>   Ryan W. Maple          "I dunno, I dream in Perl sometimes..."  -LW
>   Guardian Digital, Inc.                     ryan () guardiandigital com
> +-- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --+
>
>
> On Mon, 11 Dec 2000, Thomas Corriher wrote:
>
> > So many of these problems would just disappear if the
> > system's default profile had something like "$TMPDIR=$HOME"
> > or "$TMPDIR=$HOME/tmp".  Pine is not really the problem.
> > Poorly configured systems are the problem.  Linux
> > distributors: are you paying attention?  Why should all
> > users be given full access to any directory; especially if
> > most programs are designed to use that directory by default?
> > It is time that we wake up certain corporations and software
> > distribution companies.  This sloppiness should not be
> > tolerated.
> >
> > This type of problem appears again, and again, and again; yet
> > these problems could be fixed with a one-liner.  Oh the insanity!
> >
> > I am not even an expert on security matters, but I do know enough
> > about the basics to realize that many default configurations are
> > incredibly stupid.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE6Nt9UIwAIA9MpKWcRAgpVAJ0ZTeB3cCPvV5RgbzUqdSXA+Q4FHgCfbxjg
> 7PvBnp4ReLVu2eNq2IMpMLc=
> =eSD8
> -----END PGP SIGNATURE-----