linux security - Mar 1998 - Linux libc5 ''bug'' in mkstemp().

Pardon me if this is already known -- Theo, at least, had never heard of a
Unix doing this.

mkstemp() under Linux claims to conform to BSD4.3, but BSDs (FreeBSD and
OpenBSD, at least) seem to have a slightly different behavior.  Under Linux,
new files are created with mode 0666, while under BSDs new files are created
with mode 0600.  A user need only set his umask to 0 and he will be able to
write to temp files created with mkstemp() by suid root programs, unless the
suid root programs set their own umask.  This is probably not a major
problem for any apps, but it''s something everyone should note when
porting
security-sensitive apps to Linux from BSDs (and possibly other platforms).

[mod: I disagree with the "not a major problem" part, every breach
like
this leads to a root hole. -- REW]

A quick check shows that mkstemp() is implemented in glibc2.0.7-pre1 using
0666 as well, but that was just from a prefunctory glance at the code --
something may be going on that I didn''t notice.

Greg Alexander - also <gralexan@indiana.edu> - http://sietch.home.ml.org/
----
Any sufficiently advanced bug is indistinguishable from a feature.
		-- Rich Kulawiec

>Pardon me if this is already known -- Theo, at least, had never heard of a
>Unix doing this.
>
>mkstemp() under Linux claims to conform to BSD4.3, but BSDs (FreeBSD and
>OpenBSD, at least) seem to have a slightly different behavior.  Under Linux,
>new files are created with mode 0666, while under BSDs new files are created
>with mode 0600.  A user need only set his umask to 0 and he will be able to
>write to temp files created with mkstemp() by suid root programs, unless the
>suid root programs set their own umask.  This is probably not a major
>problem for any apps, but it''s something everyone should note when
porting
>security-sensitive apps to Linux from BSDs (and possibly other platforms).
On Solaris, mkstemp() uses a 0600 parameter as well.  This seems to
be the rpoper thing to do.


It is interesting to note that tmpfile() *MUST* use mode 0666; even though
a file exists only fr a very short while, standard compliance tests
include the honoring of the umask as part of the tests.

Solaris 2.6 tmpfile() was changed to use mkstemp(), but it needs to
fchmod() afterwards for standards complaince. Originally, mkstemp()
was changed to use mode 0666 during development, but I quickly got them
to mend their ways.

Solaris 2.6 tmpfile() does perform the unlink() *before* the fchmod(),
so there''s no way anyone will ever get to read/write your temporary
file.

More importantly, tmpfile() is not safe in most SV derived implementations.
Solaris 2.x tmpfile() isn''t safe until release 2.6; I''m pretty
sure that AIX and IRIX tmpfile() aren''t safe either; at least, they
weren''t safe back then.

Casper