Theo, I'm sorry but I did not say that /tmp is to be of mode 644.
Normally I do not use these permissions on any directories. Rather,
I said that `good old 1777 /tmp is still necessary in Unix
environments.' (Necessary for setgid programs and for programs
setuid to users who cannot write to their home, like nobody or
daemon.)
I didn't understand what problem uid swaparounds constitute. If the
code is executing at some point with egid=gid and euid=uid why not
just let it write to egid's home. If it had any privs it is not
going to have them back.
The scheme that I proposed is in my opinion
(A) little bit more reliable (for third party user level
programs that no-one ever audits for possible security quirks
because no-one has the resources necessary for this);
(B) more flexible than /tmp, because if the partition /tmp
resides on is [almost] full users can continue to use userland
applications if there is any disk space on the machine they
can use (and of course if a site's security policy is strict
you'll probably disable TMPDIR environment variable
processing altogether `just to make sure').
You are doing a very fine job at fixing flawed code. It is
impossible to believe that you really managed to have a reasonably
secure Unix system and keep it Unix. This success is admired by all
the security conscious people. However, what you are doing is just
making _your_ code correct. I don't see that it's anything
specifically related to security: it's just that the programs work as
they are supposed to (in particular, setuid root programs are not
supposed to spawn root shell on any input, so in their correct
implementation they should not, etc.).
A good and secure system of course has only one non-system user: its
admin. But some people really have users. And those users need to
run various programs, not just passwd, vi, elm, and grep. They want
to compile that converter from gif to ascii that replaces girl's
picture with verbal description or whatnot. They also may want to
run this automatically. Unix provides a lot of ways for users to run
their own programs, traditionally. This either has to be disabled
(so, setuid removed from crontab, at, batch; a kernel patch to forbid
listening on tcp/ip sockets for users; simplistic mail delivery (no
[programs in] .forward, no procmail, no qmail advanced features; no
CGI; user processes being killed if they are not logged on; and a lot
of other stuff), or one has to at least attempt to make all this more
secure. And, as disabling stuff never will truly work (what about an
expect script at their home machine being run from crontab that just
uses ssh and executes commands?) one just has to not provide too easy
ways to compromise user's own security.
If a lot of third party programs mktemp() and then fopen (..., "w")
and it is easy to make mktemp() work more securily (i.e., securily
for non-setgid programs) _why_ not do it? It's no trick, it will
work as it did earlier. It is not going to break anything. It does
not contradict to any standards, I guess, too.
Respectfully yours, --Stanislav
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:44:37 PDT