Safe auto-clean
Tim Newsham
Eugene Radchenko (ge...@qsar.chem.msu.su) wrote:
: Hi!
: I would like to auto-clean some publicly-accessible directories but recall
: reading that it is a security hole. Can someone tell how exactly this hole
: works and whether this can be done safely?
consider:
find /tmp -type f |xargs rm
find runs, finds all the files in/tmp, writes them to xargs which
executes rm several times to remove them all. Now consider
an actual tree being deleted:
/tmp/foo/bar
/tmp/foo/passwd
/tmp/blah
now find will print out these three lines, and cause rm to be run:
rm /tmp/foo/bar /tmp/foo/passwd /tmp/blah
The rm is not atomic with the find operation and there is time
for an attacker to muck around between the time when find stats a
file and when rm unlinks the file. Now if I am the attacker,
and created those files in /tmp, and knew when find was running,
I could rename the foo directory after find lists its contents.
Then I can make a symlink from the foo directory to some other
directory:
mv /tmp/foo /tmp/bar
ln -s /etc /tmp/foo
now the rm line runs:
rm /tmp/foo/bar /tmp/foo/passwd /tmp/blah
which actually does:
rm /etc/bar /etc/passwd /tmp/blah
As far as I know, this problem is due solely to the ability
to symlink to a directory (note: hardlinks to directories are
not allowed). One workaround is to only execute commands
relative to a directory. For example if "find" was to
chdir into a directory, list all the files, execute the command
and then move to the next directory there would be no problem:
cd /tmp/foo
rm *
in this case, even if an attacker replaces a file with a symlink
or a hard link, the rm will only remove the link.
To facilitate this, some versions of find have an "-execdir"
option:
-execdir utility [argument ...];
The --execdir primary is identical to the --exec primary with the
exception that Utility will be executed from the directory that
holds the current file. The filename substitued for the string
``{}'' is not qualified.
so something like:
find /tmp -type f -execdir rm {} \;
should be safe.
: Eugene V. Radchenko Research associate, Computer Chemistry
: E-mail: ge...@qsar.chem.msu.su http://org.chem.msu.su/~genie
Tim N..
Theo de Raadt
new...@aloha.net (Tim Newsham) writes:
> To facilitate this, some versions of find have an "-execdir"
> option:
>
> -execdir utility [argument ...];
> The --execdir primary is identical to the --exec primary with the
> exception that Utility will be executed from the directory that
> holds the current file. The filename substitued for the string
> ``{}'' is not qualified.
>
> so something like:
>
> find /tmp -type f -execdir rm {} \;
>
> should be safe.
That's a paste out of the OpenBSD man page. Todd Miller added that to
solve the find race problems. It took him quite a while to get it
right, since he had to also fix the recursive directory traversal
routines in libc (aka fts(3) to make them non-raceable. (There's even
further issues beyond those which Tim enumerated).
Anyways, I am not aware of another system with this mechanism.
Theo de Raadt
new...@aloha.net (Tim Newsham) writes:
> -execdir utility [argument ...];
> The --execdir primary is identical to the --exec primary with the
> exception that Utility will be executed from the directory that
> holds the current file. The filename substitued for the string
> ``{}'' is not qualified.
>
> so something like:
>
> find /tmp -type f -execdir rm {} \;
>
> should be safe.
Please note that the -execdir thingy has a bug. This is being
fixed. It's quite obscure. For the moment I would suggest
(cd /tmp; find /tmp -type f -execdir rm {} \;)
to avoid the problem.
--
This space not left unintentionally unblank. der...@openbsd.org
www.OpenBSD.org -- We're fixing security problems so you can sleep at night.
(If it wasn't so fascinating I might get some sleep myself...)
Nick Maclaren
Well, we know the following:
1) Most auto-cleans are dangerous, and some are very dangerous.
2) OpenBSD has a find extension to reduce the risk.
Has anyone written a portable program that will do auto-clean safely,
by which I mean immune to the symbolic link traps that have been
discussed in this thread? I can see at least a couple of ways to do
this, though none are particularly nice. I don't really want to have
to write one if I can scrounge one.
I can see NO way to write an auto-clean program that will have decent
semantics in conjunction with long-running programs or scripts; for
that, you need system semantics that Unix doesn't provide. But that
is a more advanced requirement.
Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Nick Maclaren
In article <1997Sep321...@koobera.math.uic.edu>,
D. J. Bernstein <d...@koobera.math.uic.edu> wrote:
>
>Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>> Has anyone written a portable program that will do auto-clean safely,
>
>cleans his own ~/tmp.
Thank you for not answering the question. Yes, I am extremely familiar
with MVS.
Actually, it isn't as simple under Unix, because processes can change uid
(which they can't under MVS). And, naturally, no right-minded system
relies on users doing their own regular cleaning. But something along
these lines could probably be done by the developers of a Unix variant.
However, like most of the people reading this group, I am using Unix
systems that were developed by other organisations.
>The cleanup script is trivial and portable. The hardest part is changing
>/tmp to $TMPDIR in existing system programs, particularly shell scripts.
PARTICULARLY shell scripts? I can assure you that it is a damn sight
easier to change those than to change executables for which you do not
have the source.
Scott Schwartz
d...@koobera.math.uic.edu (D. J. Bernstein) writes:
> Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
> > Has anyone written a portable program that will do auto-clean safely,
>
> Yes. /tmp is gone; each user has his own ~/tmp; each user periodically
> cleans his own ~/tmp.
>
> /tmp to $TMPDIR in existing system programs, particularly shell scripts.
There's an example of where unix is just too ugly. In a system with
per-process namespaces, like Plan 9, your startup file says:
bind $home/tmp /tmp
See? The conventional name "/tmp" refers to appropriate private
storage, and that mapping is inherited by children of the startup
shell. Later on, if you run "ramfs", a user mode file server, you get
a private ram based filesystem mounted on "/tmp" for that shell and
its children.
Casper H.S. Dik - Network Security Engineer
[[ Reply by email or post, don't do both ]]
Theo de Raadt <der...@zeus.theos.com> writes:
>A large fraction of binaries do not use tmpnam() and tmpfile(). They
>use mktemp(), or -- worse -- they roll their own using getpid().
Indeed.
>At least some implementations of tmpfile() are written to call
>mkstemp(), and are the tmpfile() is safe.
But not so the System V versions. We fixed this for Solaris 2.6
where tmpfile() uses mkstemp(). (But note that standard mkstemp()
uses open(OCREAT,O_EXCL, 0600) whereas some standard requires tmpfile()
to honor umask(), even though the file is unlinekd immediately!!)
I think I checked IRIX and AIX and they don't have a save tmpfile()
either.
>Oh... that is assuming that the system's mkstemp() is safe. Most are
>not completely safe, though the small remaining race is impossible to
>win in most cases. But mkstemp() can be fixed, of course if you have
>control over your entire system.
Oh? How are they unsafe? I mean, how much safer than
open(.., O_CREAT|O_EXCL, 0600) can you get?
>We've fixed it, but I doubt anyone else has.
We already have fixed quite a few of the problems, but we haven't yet
done shell scripts and probably not many of the unprivileged/non-daemon
utilities.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Nick Maclaren
In article <casper.8...@uk-usenet.uk.sun.com>, Caspe...@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) writes:
|> Theo de Raadt <der...@zeus.theos.com> writes:
|>
|> >Oh... that is assuming that the system's mkstemp() is safe. Most are
|> >not completely safe, though the small remaining race is impossible to
|> >win in most cases. But mkstemp() can be fixed, of course if you have
|> >control over your entire system.
|>
|> Oh? How are they unsafe? I mean, how much safer than
|> open(.., O_CREAT|O_EXCL, 0600) can you get?
It isn't the modes that typically cause the trouble, as no sane
administrator runs with a stupid umask, though I have to say that
most vendors ship systems with completely insane umasks for most of
the network daemons :-(
The main problem is symbolic links - you want the semantics that
the open() will NOT follow symbolic links beyond /tmp. Of course,
if the ownership and access permissions of symbolic links were not
broken-as-designed, you could restrict it to following only those
owned by root.
Scott Gifford
> I will answer your question with a pointer:
>
> Search for any postings by Zygo Blaxell in old bugtraq, ie more than a
> year ago. He is the person who caused me many sleepless nights and
> explained the entire issue very completely.
FWIW, this appears to be the post in question...It's not by Zygo Blaxell,
but it's in a thread where he was very active...
http://geek-girl.com/bugtraq/1996_2/0143.html
-----Scott.
Theo de Raadt
> where tmpfile() uses mkstemp(). (But note that standard mkstemp()
> uses open(OCREAT,O_EXCL, 0600) whereas some standard requires tmpfile()
> to honor umask(), even though the file is unlinekd immediately!!)
> I think I checked IRIX and AIX and they don't have a save tmpfile()
> either.
That sounds completely bogus. I could write a program that would
misuse this, and then be raceable. Naw, I think this is very wrong.
What standard says this?
> >Oh... that is assuming that the system's mkstemp() is safe. Most are
> >not completely safe, though the small remaining race is impossible to
> >win in most cases. But mkstemp() can be fixed, of course if you have
> >control over your entire system.
>
> Oh? How are they unsafe? I mean, how much safer than
> open(.., O_CREAT|O_EXCL, 0600) can you get?
Some mktemp(3)'s still had one stat(3) in a place where they needed a
lstat(3) instead.
This produced a very small window of opportunity. I think it is
unfeasable to win the race against a daemon or other user. However,
the window is as wide as you want if you use single-stepping
techniques against setuid binaries...
You can compare against our lib/libc/stdio/mktemp.c
> >We've fixed it, but I doubt anyone else has.
>
> We already have fixed quite a few of the problems, but we haven't yet
> done shell scripts and probably not many of the unprivileged/non-daemon
> utilities.
Thank you for being honest ;-)
There's a few more I still need to fix. Some programs use the
filenames generated by mktemp(3) in very strange ways. Like yacc(1)
and patch(1)... Now some of you are probably laughing at me...
Theo de Raadt
Caspe...@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) writes:
> A umask of 022 is till a problem for administrators, unless temporary
> files are opened mode 0600).
All temporary files and directories should be made mode 600. If they
aren't, they fall into the class of problems I call a "localhost
information gathering attack".
Hmm, I sure do love reading your cpp output files to see what you are
working on.
Theo de Raadt
Caspe...@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) writes:
> (And a safe chroot would be nice too :-)
I don't see any way of getting close to this with the existing semantics.
mknod and ptrace aren't even the biggest issues.
Nick Maclaren
In article <c4t7zo...@zeus.theos.com>,
Theo de Raadt <der...@zeus.theos.com> wrote:
>Caspe...@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) writes:
>
>> files are opened mode 0600).
>
>All temporary files and directories should be made mode 600. If they
>aren't, they fall into the class of problems I call a "localhost
>information gathering attack".
I don't really agree. The number of scripts that need to handle secret
information is very small, and they should be double-checked anyway.
After all, if the allocation is secure, a quick chmod is all you need;
the problem is getting the allocation secure in the first place.
>Hmm, I sure do love reading your cpp output files to see what you are
>working on.
Precisely. I scanned every system script on two systems, and the only
ones that needed secret temporary files were the ones that updated the
password files. And those files were not in /tmp, anyway (/etc/ptmp
etc.) I am pretty sure that the same applies to the system programs.
Casper H.S. Dik - Network Security Engineer
[[ Reply by email or post, don't do both ]]
Theo de Raadt <der...@zeus.theos.com> writes:
>Caspe...@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) writes:
>>
>> But not so the System V versions. We fixed this for Solaris 2.6
>> where tmpfile() uses mkstemp(). (But note that standard mkstemp()
>> uses open(OCREAT,O_EXCL, 0600) whereas some standard requires tmpfile()
>> to honor umask(), even though the file is unlinekd immediately!!)
>> I think I checked IRIX and AIX and they don't have a save tmpfile()
>> either.
>That sounds completely bogus. I could write a program that would
>misuse this, and then be raceable. Naw, I think this is very wrong.
>What standard says this?
No you can't :-) (There's nothing saying you need to open(,0666),
the mode after open need to be 0666 &~umask.
When we first changed tmpfile() to call the traditional mkstemp(), standard
conformance tests failed.
>Some mktemp(3)'s still had one stat(3) in a place where they needed a
>lstat(3) instead.
Ah, but mktemp() is always raceble. As long as you combinme O_CREAT|O_EXCL
[and your system does the right thing]
SVR3, Solaris 2.x (before 2.6) and SVR4 all use access() which is
as bad as stat().
That produces a huge window; as long as O_EXCL isn't used, you don't
need to race.
>There's a few more I still need to fix. Some programs use the
>filenames generated by mktemp(3) in very strange ways. Like yacc(1)
>and patch(1)... Now some of you are probably laughing at me...
Yeah; and we found weird things when changing the underlying name
generation with mktemp(), it now uses random to give a better spread;
it's seeded with getpid(), so it's not to make racing it less feasible;
previously pid N and N+1 would easily collide. One program assumed
that the values returned by mktemp() only differed in one character.
(I'd like to have it truely random, seeded with time so that lying in
wait until someone runs some program becomes seriously infeasible;
but using lstat() instead of access() already is a leap forward; you
can no longer put 30000 links in /tmp and win. You need to actually
race.
Theo de Raadt
nm...@cus.cam.ac.uk (Nick Maclaren) writes:
> I don't really agree. The number of scripts that need to handle secret
> information is very small, and they should be double-checked anyway.
> After all, if the allocation is secure, a quick chmod is all you need;
> the problem is getting the allocation secure in the first place.
I really have no idea why you would think it is OK for temporary files
to be public information.
> >Hmm, I sure do love reading your cpp output files to see what you are
> >working on.
>
> Precisely. I scanned every system script on two systems, and the only
> ones that needed secret temporary files were the ones that updated the
> password files. And those files were not in /tmp, anyway (/etc/ptmp
> etc.) I am pretty sure that the same applies to the system programs.
It's wrong. You should not be able to watch /tmp and see what anyone
else is working on.
Theo de Raadt
Caspe...@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) writes:
> When we first changed tmpfile() to call the traditional mkstemp(), standard
> conformance tests failed.
I would like to know what standard conformance tests those are. All BSD's
ship with tmpfile() calling mkstemp().
> >Some mktemp(3)'s still had one stat(3) in a place where they needed a
> >lstat(3) instead.
>
> Ah, but mktemp() is always raceble. As long as you combinme O_CREAT|O_EXCL
> [and your system does the right thing]
Whoops. I mean, mkstemp(3) had one stat(3) call left that was raceable.
> Yeah; and we found weird things when changing the underlying name
> generation with mktemp(), it now uses random to give a better spread;
> it's seeded with getpid(), so it's not to make racing it less feasible;
> previously pid N and N+1 would easily collide. One program assumed
> that the values returned by mktemp() only differed in one character.
> (I'd like to have it truely random, seeded with time so that lying in
> wait until someone runs some program becomes seriously infeasible;
> but using lstat() instead of access() already is a leap forward; you
> can no longer put 30000 links in /tmp and win. You need to actually
> race.
What we did was quite different; I felt that real random was a bad
choice in mktemp. The pattern we try to plop into the X buffer is
[A-Za-z0-9]*[A-Za-z][pid]. We use various tricks for dealing with
short X buffers. Mostly we have done a sweep of the source tree.
When you go to real random, you do actually increase the chances of
inadvertant mktemp() failures. Not an issue for mkstemp(), but for
mktemp() I do think more attempts should be made to ensure that
programs do not collide against each other.
Whenever a piece of source proved difficult to convert to mkstemp(),
we have used a stopgap measure of changing it to use 10 or so X's in
the buffer, instead of the old 6. As I previously described, this is
only used for a very small class of non-security related utilities.
Of course, I should note also that OpenBSD pid numbers are random..
Casper H.S. Dik - Network Security Engineer
[[ Reply by email or post, don't do both ]]
Theo de Raadt <der...@zeus.theos.com> writes:
>Caspe...@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) writes:
>> When we first changed tmpfile() to call the traditional mkstemp(), standard
>> conformance tests failed.
>I would like to know what standard conformance tests those are. All BSD's
>ship with tmpfile() calling mkstemp().
The test called was "VSX". I think the reasoning is like this:
tmpfile() opens a file like fopen(,"w+")
and I assumes it follows from there.
>When you go to real random, you do actually increase the chances of
>inadvertant mktemp() failures. Not an issue for mkstemp(), but for
>mktemp() I do think more attempts should be made to ensure that
>programs do not collide against each other.
How so? The collisions chances are quite slim; going from a pid
space of 30000 to a much bigger one does help.
>Of course, I should note also that OpenBSD pid numbers are random..
How does that help?
Tom Holub
In article <c2032o...@zeus.theos.com>,)nm...@cus.cam.ac.uk (Nick Maclaren) writes:
)
)> I don't really agree. The number of scripts that need to handle secret
)> information is very small, and they should be double-checked anyway.
)> After all, if the allocation is secure, a quick chmod is all you need;
)> the problem is getting the allocation secure in the first place.
)
)I really have no idea why you would think it is OK for temporary files
)to be public information.
If your umask makes your normal files public, why not?
)It's wrong. You should not be able to watch /tmp and see what anyone
)else is working on.
What difference does it make, if you can go into their directory and
see what they're working on?
-Tom
Theo de Raadt
Caspe...@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) writes:
> >Of course, I should note also that OpenBSD pid numbers are random..
>
> How does that help?
It helps a few things. It makes it very hard to guess what the filename
of the next mktemp will be.
There were a number of close calls which caused us to make this
change. RPC XID's for example. Of course those don't even depend on
getpid() either, they are stronger random now, too.
Nick Maclaren
>
>> I don't really agree. The number of scripts that need to handle secret
>
And I really have no idea why you think that it is not! Tom Holub has
it right - if those temporary files contain the sort of data that you
don't mind being read, then there is nothing against it.
But there is a security reason, too. Publicly readable files (both
permanent and temporary) mean that the administrators and support staff
do not need to become superuser to investigate problems. This means
BOTH that fewer people need the root password AND those that do need
spend less time privileged. And, as we all know, finger trouble by
root is one of the main causes of system problems (including security
ones).
>> >Hmm, I sure do love reading your cpp output files to see what you are
>> >working on.
>>
>> Precisely. I scanned every system script on two systems, and the only
>> ones that needed secret temporary files were the ones that updated the
>> password files. And those files were not in /tmp, anyway (/etc/ptmp
>> etc.) I am pretty sure that the same applies to the system programs.
>
>It's wrong. You should not be able to watch /tmp and see what anyone
>else is working on.
Sorry, but that is a matter of religion. I don't happen to worship at
the same shrine. Secrecy for secrecy's sake corrupts, as we know all
too well in the UK.
Peter Benie
In article <casper.8...@uk-usenet.uk.sun.com>,
Casper H.S. Dik - Network Security Engineer <Caspe...@Holland.Sun.Com> wrote:
>Ah, but mktemp() is always raceble. As long as you combinme O_CREAT|O_EXCL
>[and your system does the right thing]
The manpage for open(2) on Solaris 2.5.1 says the following about O_EXCL:
"The check for the existence of the file and the creation of the file
if it does not exist is atomic with respect to other processes
executing open() naming the same filename in the same directory with
O_EXCL and O_CREAT set."
In other words, you can use O_CREAT|O_EXCL to safely create new files
if all the programs involved also use O_CREAT|O_EXCL.
Is O_CREAT|O_EXCL safe with respect to processes calling link,
symlink, open O_CREAT without O_EXCL, etc. Is the behaviour documented
anywhere?
Peter Benie
Nick Maclaren
In article <5uuken$5k1$1...@lyra.csx.cam.ac.uk>,
Peter Benie <pjb...@cus.cam.ac.uk> wrote:
>In article <casper.8...@uk-usenet.uk.sun.com>,
>Casper H.S. Dik - Network Security Engineer <Caspe...@Holland.Sun.Com> wrote:
>>Ah, but mktemp() is always raceble. As long as you combinme O_CREAT|O_EXCL
>>[and your system does the right thing]
>
>The manpage for open(2) on Solaris 2.5.1 says the following about O_EXCL:
>"The check for the existence of the file and the creation of the file
>if it does not exist is atomic with respect to other processes
>executing open() naming the same filename in the same directory with
>O_EXCL and O_CREAT set."
>
>In other words, you can use O_CREAT|O_EXCL to safely create new files
>if all the programs involved also use O_CREAT|O_EXCL.
And none of the filesystems are remote (e.g. NFS)! Almost all bets are
off as soon as you are tainted by NFS.
>Is O_CREAT|O_EXCL safe with respect to processes calling link,
>symlink, open O_CREAT without O_EXCL, etc. Is the behaviour documented
>anywhere?
Provided that the system conforms to POSIX.1, those should be safe (but
remember that symlinks are not in POSIX yet, for good reasons). But I
know of systems where they aren't safe (usually ones where NFS-like
interfaces are used internally).
The ONLY decent specification of Unix is POSIX, and that is currently
very limited. Given the fact that the Open Group seems to have won out
politically, expect the specifications to get worse. However, to be
fair, I was impressed by the chown/chmod/symlink specification in the
X/Open CAE version 1 - pity that it flatly contradicted convention.
Scott Schwartz
Theo de Raadt <der...@zeus.theos.com> writes:
> > (And a safe chroot would be nice too :-)
> I don't see any way of getting close to this with the existing semantics.
So adopt Inferno's semantics.
Wietse Venema
Someone (Casper?) wrote:
> (And a safe chroot would be nice too :-)
Theo de Raadt:
> I don't see any way of getting close to this with the existing semantics.
Scott Schwartz:
>So adopt Inferno's semantics.
Right, if we're allowed to change semantics, replace UNIX by PLAN9,
and get rid of set-uid and other problems altogether.
Wietse
Nick Maclaren
In article <5v42en$2...@nuhou.aloha.net>, Tim Newsham <new...@aloha.net> wrote:
>Tom Holub (do...@best.com) wrote:
>: )I really have no idea why you would think it is OK for temporary files
>: )to be public information.
>:
>: If your umask makes your normal files public, why not?
>
>Temporary files are not meant for sharing. They are
>private to the program that created them.
That is not true under Unix. They have no defined scope (unlike MVS
temporary files), and it can be anything from the program, through
the process group and the user's processes, to the system as a whole.
> There may not be a great reason for keeping go+r bits off
> of the files, but there's even less reason to put setting the bits.
As I mentioned earlier, there is. It helps a great deal with getting
and giving advice, and reduces the amount of time people have to work
as the superuser. Paranoia can reduce security.
Tim Newsham
Tom Holub (do...@best.com) wrote:
: )I really have no idea why you would think it is OK for temporary files
: )to be public information.
:
: If your umask makes your normal files public, why not?
A umask giving others read permission facilitates sharing.
Temporary files are not meant for sharing. They are
private to the program that created them.
There may not be a great reason for keeping go+r bits off
of the files, but there's even less reason to put setting the bits.
: What difference does it make, if you can go into their directory and
: see what they're working on?
Perhaps they are working in a private directory?
moral: file permission bits are only half of the story.
There are also the permission bits on the directories
leading up to the file.
Perhaps they are working in a sgid directory?
moral: the file permissions of a file in /tmp are not
necessarily the same as the same file created elsewhere
in the filesystem.
: -Tom
Tim N.
Peter Benie
In article <slrn61bci...@char-star.rdist.org>,
Thomas H. Ptacek <tq...@enteract.com> wrote:
>9 Sep 1997 18:15:47 GMT nm...@cus.cam.ac.uk:
>>>Temporary files are not meant for sharing. They are
>>>private to the program that created them.
>
>
>private to the application (program or suite of cooperating programs)
>creating it? Where do you get "no defined scope" (reference, please) from?
I believe that nmm1's claim is that there are no references or
specifications, and that is why the scope is undefined. You can ask
for references to support this claim, but (by definition) you aren't
going to get any.
I don't understand what you mean by "suite of cooperating programs" in
this context. There is no mechanism to declare that a file is required
by a suite of programs. You could implement a filesystem that removed
the temporary file after the program the created the temporary file
died, and then your 'cooperating programs' would break. As far as I
know, such a filesystem would not break any standards.
Peter
Nick Maclaren
In article <slrn61bdr...@char-star.rdist.org>,>9 Sep 1997 20:47:22 GMT pjb...@cus.cam.ac.uk:
>>I believe that nmm1's claim is that there are no references or
>>specifications, and that is why the scope is undefined. You can ask
Peter is perfectly correct. You are apparently asking me for a reference
that states that there is no reference - well, I HAVE seen such things,
but not in this context. Would you like to provide a reference that
justifies your claim that temporary files have a defined scope under
Unix?
>I guess logic will need to suffice. In what case does a program ever
>publish a temporary file?
"Publish"? Well, if we ignore that irrelevance, consider the very common
situations where a compiler produces intermediate output on /tmp for later
use by another stage or a linker. Two programs - one temporary file.
And you are evidently not familiar with HP-UX, which creates files in /tmp
to handle local X connexions - which may come from processes owned by
different uids. There are also some applications that I have seen which
even document their use of /tmp, and get really unhappy when you autoclean
before they have finished with those files.
>>this context. There is no mechanism to declare that a file is required
>>by a suite of programs. You could implement a filesystem that removed
>
>A single program uses a temporary file internally and deletes it. A suite
>of programs may use a temporary file to communicate between themselves.
>Unrelated programs do not use each other's temporary files.
Is that meant to be a statement of fact, an article of dogma or wishful
thinking?
Quite a lot of programs put lock files in /tmp - not what I would choose,
but all that can be done if they can be called by multiple unprivileged
users. And, if they communicate information (such as process ids) using
that method, they CANNOT have access only to the owner. Other programs
leave diagnostic output in /tmp after a failure, so that the user (or
the support staff he asks for help) can investigate the cause.
>Mr. McClaren stated that, under "Unix", temporary files are not private to
>the program (or application) using them. I'm wondering if Mr. McClaren can
>come up with a case where temporary files are NOT private in this manner.
I claimed that they do not have a defined scope. If you say that I am
wrong, then I think that the onus is on you to find some justification
that they do have a defined scope.
Incidentally, I have pointed out to you before that you can look at my
signature for a correct spelling of my name - there is no clan Clarence.
I am beginning to suspect that you are being rather childish (for this
and other reasons).
Theo de Raadt
nm...@cus.cam.ac.uk (Nick Maclaren) writes:
> And you are evidently not familiar with HP-UX, which creates files in /tmp
> to handle local X connexions - which may come from processes owned by
> different uids. There are also some applications that I have seen which
> even document their use of /tmp, and get really unhappy when you autoclean
> before they have finished with those files.
I am really fascinated that your chosen example is part of a well
known class of security problems that has not been fixed even in the
latest versions of X11.
/tmp/.X11-unix/X0=, anyone?
Theo de Raadt
nm...@cus.cam.ac.uk (Nick Maclaren) writes:
> Incidentally, I have pointed out to you before that you can look at my
> signature for a correct spelling of my name - there is no clan Clarence.
> I am beginning to suspect that you are being rather childish (for this
> and other reasons).
No, that role is held only by the first person to change the topic
from "computer security" to "spelling" .... I wonder who has the
bigger daddy ;-)
Nick -- I am quite sure that you are wrong on this issue. I am fixing
OpenBSD so that applications do not accidentally expose a user's
private information in a world readable file. umasks need not apply
in cases where the umask isn't relevant.
I will persist in doing this so that even users who don't know about
"umask" don't give out their private information inadvertently.
Perhaps, and I positively cringe to say this, you should read up on B
and C secure systems and on something called a "covert channels".
This issue isn't exactly about covert channels. However the same
lessons learned from reading about "covert channels" can be applied
there, and in this case the user is just running "cc". He should not
know about umask's to ensure his secrecy!
If I run "cc" on my machine, I don't give a damn -- NOONE should be
reading my compiler's temporary files -- umask or no umask. And you
can argue all you like, but I very strongly believe in that issue, and
I am going to continue change programs in OpenBSD that incorrectly
create world readable /tmp files.
Thomas H. Ptacek
9 Sep 1997 21:37:45 GMT nm...@cus.cam.ac.uk:
>"Publish"? Well, if we ignore that irrelevance, consider the very common
>situations where a compiler produces intermediate output on /tmp for later
>use by another stage or a linker. Two programs - one temporary file.
You are either incapable of reading or are intentionally ignoring my
repeated assertion that temp files are used privately among suites of
related programs to communicate with persistant messages.
Either way, you are wrong.
--
----------------
Thomas Ptacek at the RDIST organization [tq...@rdist.org]
----------------
exit(main(kfp->kargc, argv, environ));
Tim Newsham
Nick Maclaren (nm...@cus.cam.ac.uk) wrote:
[... nothing interesting or relevant ...]
The discussion was about the permissions of files created
with mktemp.
Theo Deraadt said that such files should not be
world readable, and hence should not simply rely on
the users umask.
So back to the relevant question: Why is making mktemp
open files with secure permissions bad? Is there any
program that relies on mktemp files being world readable?
I've already listed two reasons why umask should not
be relied on (umask doesn't always do "the right thing"
in directories other than the current directory).
If you insist on going off on a tangent about irrelevant
information, I'm going to have to withdraw from the
conversation. This is *not* in any way related
to users sharing files in /tmp.
Tim N.
Nick Maclaren
In article <cafhlr...@zeus.theos.com>,
Theo de Raadt <der...@zeus.theos.com> wrote:
>nm...@cus.cam.ac.uk (Nick Maclaren) writes:
>
>Nick -- I am quite sure that you are wrong on this issue. I am fixing
>OpenBSD so that applications do not accidentally expose a user's
>private information in a world readable file. umasks need not apply
>in cases where the umask isn't relevant.
>
>I will persist in doing this so that even users who don't know about
>"umask" don't give out their private information inadvertently.
I think that you have missed my points. There are four:
1) I claim that nowhere is Unix gives temporary files a defined scope.
Thomas Ptacek claims that I am talking rubbish, but apparently believes
that abuse (from him) constitutes a reference. Please note that this DOES
NOT MEAN that I claim that they have indefinite scope.
2) I have given examples (some of which, I agree, are security disaster
areas) of where the scope is wider than the files owned by a single user.
This is a statement about what the situation ACTUALLY IS, and not what it
SHOULD BE.
3) I have pointed out advantages (security and otherwise) of treating
temporary files in the same way as permanent ones. This DOES NOT MEAN
that I necessarily disagree with a system making them more restricted. As
I said, I am familiar with MVS, and its temporary file handling has
considerable advantages.
4) I have stated that your claim that there is a One and Only True
Path is religious dogma, and not a technical assertion. There are
technical arguments both ways, and I happen to cost the risks differently
from you. Perhaps the environment I work in is slightly different?
However, I am not claiming that making temporary files world-unreadable
BY DEFAULT is wrong. In a Unix context, I believe that it would be wrong
to make it mandatory and unchangeable, but that is primarily because of
some sordid details.
Nick Maclaren
In article <5v59ea$7...@nuhou.aloha.net>, new...@aloha.net (Tim Newsham) writes:
|> Nick Maclaren (nm...@cus.cam.ac.uk) wrote:
|> [... nothing interesting or relevant ...]
|>
|> The discussion was about the permissions of files created
|> with mktemp.
Are you referring to the following posting? If not, could you please
quote enough so that readers can follow what you are on about?
In article <5v42...@nuhou.aloha.net>,
Tim Newsham <new...@aloha.net> wrote:
>Tom Holub (do...@best.com) wrote:
>: )I really have no idea why you would think it is OK for
>: )temporary files to be public information.
>:
>: If your umask makes your normal files public, why not?
>
>A umask giving others read permission facilitates sharing.
>Temporary files are not meant for sharing. They are
>private to the program that created them.
That is not true under Unix. They have no defined scope (unlike MVS
temporary files), and it can be anything from the program, through
the process group and the user's processes, to the system as a whole.
I don't see any reference to mktemp and, if you had read earlier items
in the thread, you would have realised that many people had commented
how many different ways there were to create temporary files in /tmp
and that it is necessary to consider them all.
Nick Maclaren
In article <slrn61dp9...@char-star.rdist.org>,>10 Sep 1997 08:05:05 GMT nm...@cus.cam.ac.uk:
>> 3) I have pointed out advantages (security and otherwise) of treating
>>temporary files in the same way as permanent ones. This DOES NOT MEAN
>
>specifically the security advantages of treating temporary files as
>regular files on modern Unix systems. Could you perhaps reiterate?
Because, when the user reports a problem or asks for advice with a
script that creates temporary files, it can be investigated without
becoming superuser. This means (a) that fewer people need to know
the root password and (b) those that do need spend less time as root.
And, the less work that is done as root, the fewer chances there are
for finger trouble and/or calling a booby-trapped program.
D. J. Bernstein
In article <5uruue$86k$1...@shell3.ba.best.com>, Tom Holub <do...@best.com> wrote:
> If your umask makes your normal files public, why not?
Because your umask is not the only thing protecting your files.
For example, many people operate with umask 022, and with essentially
all files mode 644 or 755, but with ~/Mail mode 700.
These people don't want their e-mail readable by other people. It is a
security problem for a mailer to create a file in /tmp obeying the
umask. One solution is to artificially use mode 600. A simpler solution
is to eliminate /tmp in favor of ~/tmp, mode 700 by default.
---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html
D. J. Bernstein
Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
> Because, when the user reports a problem or asks for advice with a
> script that creates temporary files, it can be investigated without
> becoming superuser.
This is also why MaclarenOS doesn't support pipes. It forces you to
store all intermediate results on disk and delete them manually if
you're satisfied with the output. That makes debugging much easier.
Thomas H. Ptacek
10 Sep 1997 08:05:05 GMT nm...@cus.cam.ac.uk:
> 3) I have pointed out advantages (security and otherwise) of treating
>temporary files in the same way as permanent ones. This DOES NOT MEAN
I am unable to find any point in this thread where you enumerated
specifically the security advantages of treating temporary files as
regular files on modern Unix systems. Could you perhaps reiterate?
--
Leslie Mikesell
In article <slrn61bko...@char-star.rdist.org>,
>>"Publish"? Well, if we ignore that irrelevance, consider the very common
>>situations where a compiler produces intermediate output on /tmp for later
>>use by another stage or a linker. Two programs - one temporary file.
>
>You are either incapable of reading or are intentionally ignoring my
>repeated assertion that temp files are used privately among suites of
>related programs to communicate with persistant messages.
>
I've always used /tmp as an intermediate holding spot to transfer files
between arbitrary users, neither of whom has both read and write access
to each other's directories (and perhaps neither). Isn't that what it
is for? If I want private files I'll keep them somewhere else.
Les Mikesell
l...@mcs.com
Thomas H. Ptacek
10 Sep 1997 15:55:50 -0500 l...@MCS.COM:
>I've always used /tmp as an intermediate holding spot to transfer files
>between arbitrary users, neither of whom has both read and write access
>to each other's directories (and perhaps neither). Isn't that what it
>is for? If I want private files I'll keep them somewhere else.
As much as some people would like to convince you that this is what the
argument is about, it isn't. Nobody's saying you can't share files via
/tmp. This discussion concerns temporary files generated by applications
(files that the vast majority of users probably don't even know exist),
and whether or not the application creating them should control what their
permissions are or whether they should obey the umask defined by the user.
Nick Maclaren
In article <1997Sep1021...@koobera.math.uic.edu>,
D. J. Bernstein <d...@koobera.math.uic.edu> wrote:
>Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>> Because, when the user reports a problem or asks for advice with a
>> script that creates temporary files, it can be investigated without
>> becoming superuser.
>
>This is also why MaclarenOS doesn't support pipes. It forces you to
>store all intermediate results on disk and delete them manually if
>you're satisfied with the output. That makes debugging much easier.
Grin :-) Have you ever read "Games People Play?" If not, you should.
When we first dabbled with Unix, I got an earful from some Unix freaks
about how the MVS model of temporary files (i.e. they are local to the
session or job - real job, not batch process) was terrible and the Unix
model was the Only Truth Path to Enlightenment. In particular, I was
told that the word "temporary" should mean "until the user explicitly
deletes it". I was not convinced.
You appear to be absolutely incapable of realising that there are people
in this world who can see more than one side to a question, and who are
prepared to admit that there may be more than one "correct" way of going
about things.
Chris Evans
On 6 Sep 1997, Nick Maclaren wrote:
> >I really have no idea why you would think it is OK for temporary files
> >to be public information.
>
> And I really have no idea why you think that it is not! Tom Holub has
> it right - if those temporary files contain the sort of data that you
> don't mind being read, then there is nothing against it.
>
> But there is a security reason, too. Publicly readable files (both
> permanent and temporary) mean that the administrators and support staff
> do not need to become superuser to investigate problems. This means
> BOTH that fewer people need the root password AND those that do need
> spend less time privileged. And, as we all know, finger trouble by
> root is one of the main causes of system problems (including security
> ones).
A good point, but I've always followed the habit of making a new group,
"config" or something, which has permission to read pertinent important
system configuration files. Membership of this group can be dished out to
whatever users you deem suitable.
I dislike the way a large amount of security sensitive files in /etc and
otherwise, are shipped readable by all users on many UNIX variants.
You can take one of two attitudes to system file security
1) Leave everything open, revoking read permission on only files you
configure with sensitive/unusual/nonstandard information
2) Only let users read files on a *needed* basis.
I fall into category 2)...
Cheers
Chris
Chris Evans
On Thu, 11 Sep 1997, Nick Maclaren wrote:
> > A good point, but I've always followed the habit of making a new group,
> > "config" or something, which has permission to read pertinent important
> > system configuration files. Membership of this group can be dished out to
> > whatever users you deem suitable.
>
> Actually, that doesn't work reliably. It depends on one particular group
> model and doesn't work on ones that use the 'newgrp' one.
Works fine here, Nick, thankyouverymuch :-)
I'm sure with minimal effort it can be made to work on other UNIX variants
too, if they don't support supplementary groups. Even better, the fine
access granularity provided by ACL's on the few UNIX boxes that have them,
could provide a suitable scheme.
> What we REALLY need is an identifier that would have superuser READ
> privilege, but not superuser WRITE (or the miscellaneous other privileges
> that are tacked onto root).
Agreed. After three, now, "POSIX to the rescue"...
POSIX.1e (formerly POSIX.6) splits root privs into a much better and more
finely grained set of privs. One such priv is "CAP_DAC_READ_SEARCH",
which, quote, "This capability overrides all DAC restrictions regarding
read and search on files and directories,
including ACL's."
No write though.. as required
I've seen (an initial implementation of) POSIX.1e going on my home Linux
box and it's very gratifying to see a non-suid ping work (CAP_NET_RAW) as
well as non-suid rlogin et al. (CAP_NET_BIND_SERVICE). These last two
privilege divisions are not yet defined by POSIX though.
Chris
D. J. Bernstein
Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
> You appear to be absolutely incapable of realising that there are people
> in this world who can see more than one side to a question,
On the contrary. I see both sides, and I have evaluated both sides, and
I have found that one side is vastly superior to the other. This may
seem ruthless, but that's how engineering works.
Several years ago I proposed splitting file creation into two syscalls:
(1) create a new open file given a writable directory; (2) link an open
file into a writable directory. Then tmpfile() would use #1. This avoids
the pointless game of selecting an unused file name and eliminates the
risk of interference from other users, even if $TMPDIR is still /tmp. It
also cleans up properly if the process crashes during tmpfile().
Nick Maclaren
In article <1997Sep1117...@koobera.math.uic.edu>,
>(1) create a new open file given a writable directory; (2) link an open
>file into a writable directory. Then tmpfile() would use #1. This avoids
>the pointless game of selecting an unused file name and eliminates the
>risk of interference from other users, even if $TMPDIR is still /tmp. It
>also cleans up properly if the process crashes during tmpfile().
That used to be available, though I cannot now remember in which
variants of Unix (System III?) It, however, does NOT clean up correctly
if the process crashes, because it tends to leave disconnected inodes
and associated data blocks hanging around. That is one reason that it
was abandoned. As far as I know, Unix never copied the MVS "passed
dataset list", which was a gruesome hack for exactly that problem.
Actually, it gets better. A directory created like that doesn't have a
parent until you link it in and, unless the system is VERY clever, you
can arrange to link it in to one of its children. The disconnected
vortex thus created used to be immune to many versions of fsck, which
led to the recommendation to reformat partitions every now and then to
recover the dead space.
TANSTAAFL.
Wietse Venema
D. J. Bernstein:
>On the contrary. I see both sides, and I have evaluated both sides, and
>I have found that one side is vastly superior to the other. This may
>seem ruthless, but that's how engineering works.
I would like to add that examples exist where engineering is the
art of finding the best compromise between conflicting requirements,
so that no universal `better' choice can be made. Take, for example,
the many different offerings for cars, houses, airplanes, computers,
and software.
Wietse
D. J. Bernstein
Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
> It, however, does NOT clean up correctly
> if the process crashes, because it tends to leave disconnected inodes
> and associated data blocks hanging around.
I don't know what ancient buggy system you were using. Nor do I care.
Every current UNIX filesystem supports unlinked open files, and deletes
them properly when the last reference disappears.
(Note that NFS is a poor imitation of a UNIX filesystem.)
> A directory created like that doesn't have a
> parent until you link it in
In case it wasn't clear: I am talking about creation of regular files,
not directories or block devices or anything else.
Andrew Josey
Casper H.S. Dik - Network Security Engineer (Caspe...@Holland.Sun.Com) wrote:
: [[ Reply by email or post, don't do both ]]
: Theo de Raadt <der...@zeus.theos.com> writes:
: >Caspe...@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) writes:
: >> When we first changed tmpfile() to call the traditional mkstemp(), standard
: >> conformance tests failed.
: >I would like to know what standard conformance tests those are. All BSD's
: >ship with tmpfile() calling mkstemp().
: The test called was "VSX". I think the reasoning is like this:
: tmpfile() opens a file like fopen(,"w+")
: and I assumes it follows from there.
The test was based on text in IEEE Std 1003.1/ IEEE Std 2003.1.
A recent 1003.1 interpretation backs up that this is what the .1 standard
says, and admits its probably wrong. VSX no longer requires the behaviour.
--
Andrew Josey, Email: ajosey(at)rdg.opengroup.org #include <std/disclaimer.h>
Theo de Raadt
Stefan Monnier
> > I really have no idea why you would think it is OK for
> > temporary files to be public information.
Because 99% of the programs are careless with tempfile creation.
Let's say your umask is 022 because you don't care in most cases whether other
users can read your files or not. Now you have one C source file that you want
to keep "secret" so you change it from 622 to 600. Do you think your compiler
will honor the permissions on the .c file when creating temporary files in /tmp
or will it simply use umask even though you explicitely said that this file
needs special care ?
Stefan
John R MacMillan
|... Do you think your compiler
|will honor the permissions on the .c file when creating temporary files in /tmp
|or will it simply use umask even though you explicitely said that this file
|needs special care ?
No, nor do I think it should, any more than it should with the output
object file, or "sort -o" should if sorting it, or the shell should
if you do "anyfilter < read_only_file > output", or some magic should
if you do "someprogram -o output < ro_file" or "prog ro_file > out"
(in the last example substitute "echo" and "cat" for prog and see if
you think output should have the same permissions).
The umask is what should be used to indicate how you want permissions
handled; programs should not have to, and cannot, guess based on the
permissions of one or more input files. If you're compiling (or
sorting, or anything) a sensitive file, change your umask first.