[1698] in linux-security and linux-alert archive
[linux-security] Re: Towards a solution of tmp-file problems
daemon@ATHENA.MIT.EDU (Rogier Wolff)
Wed Mar 11 04:37:32 1998
To: linux-security@redhat.com
Date: Wed, 11 Mar 1998 09:17:49 +0100 (MET)
From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
Hi everyone,
Thanks all for your feedback. Here is a reply to most of your
comments....
Roger.
Chris Evans wrote:
> On Mon, 9 Mar 1998, Rogier Wolff wrote:
> > not to give those rights away. A non-setuid program should not have to
> > worry about buffer overruns (you can crash the program, wow!). It
> Just a reminder, that in some cases, it _should_ worry. As a simple recent
> real-world example, someone's ftp client had an overrun that allowed
> malicious remote servers to send malformed directory listings, and thus
> gain access to the user running the client.
Right. Lets generalize this:
Anything that interacts with stuff that has lower-security clearance
should be "careful".
This includes:
passwd, lpr: setuid, interaction possible with normal users on
the system.
inetd, ftpd: network deamons, interaction with unauthenticated
remote users.
netscape, ftp: userprograms, interaction with unauthenticated
remote servers.
This does NOT include:
ls, cat: userprograms, interact only with system-local stuff.
Mark Whitis (whitis@dbd.com) wrote:
> > A /tmp that is a symlink to /.tmp/$euid would do the trick.
> However, there are some things which are broken by this. One case
> which was pointed out to me was the unix domain sockets used by X11.
Actually "X11" is broken. It is using /tmp not for temporary files,
but for a communications path. The cludge-fix is to have a traditional
symlink to a centralized place for all those that still want the
unix-domain socket in their private /tmp.
> There might also be problems with programs like lpr, in some
> situations. Any program or script which calls lpr with a file in
> /tmp using the untranslated pathname (this will happen often) might
> fail since lpr might interpret the pathname in a different context
> since it is suid.
If that's the case, then lpr has a large security hole. If it's
accessing my file as "root" then I can NOW trick it to print other
people's files.
William R. Ward (hermit@BayView.COM) wrote:
[WRW: Complexity.... Shell has many syntaxes for variable expansion
REW: just the "$variable" syntax will be supported. ]
> There are definitely situations where ${variable} would be needed.
> I strongly recommend you add it. In fact you could even do what
> make does and require it (and not support $variable).
Actually that's a very good idea. This way, not just a single
character ($) but a two character sequence (${) is used to trigger the
special case.
Andries Brower (Andries.Brouwer@cwi.nl) wrote:
> > How about allowing symlinks with "variable expansion"?
> What you describe is a new kind of object. Don't call it a symlink
> - POSIX will soon tell us precisely what the semantics of symlinks
> are (does the standard exist already?). Call it a varlink. New type
> of object in the filesystem, new semantics.
Good idea! Done.
Andries, I'm deliberately interpreting your suggestion a little
different than you intended. You probably meant that a new set of
"flags" (file, directory, symlink, pipe, block-dev, char-dev,
... varlink), on an file-system object would make it a varlink as
opposed to a symlink. That would require 1) all the filesystems to be
updated 2) And lots of tools.
I'm defining a "varlink" as a "symlink that has the "${" sequence
embedded.
Randolph Bentson (bentson@grieg.holmsjoen.com) wrote:
> The "link" operation is atomic and fails even for root if the
> destination exists. It's a rather simple matter to create a file in
> /tmp with an effectively unguessable name (using /dev/urandom and
> other such) before attempting a link to the desired file name.
1) This isn't as easy for things like shell scripts that need a
temporary file.
2) It doesn't follow the rule "what should be easy actually IS easy".
A program that doesn't interact cross-security boundary shouldn't need
to be written by a security expert.
Glynn Clements (glynn@sensei.co.uk) wrote:
> > Sometimes a program already checks for the existence of the file, and
> > creates it if its not there. This is not atomic, and cannot easily be
> > made secure.
> Well, you can open() it with [ O_CREAT| ] O_EXCL.
- Which will happily create a new file through a symlink...
- Which isn't easliy do-able for shell scripts.
> e.g. mkstemp(). Unfortunately the file is created with mode 0666, so
> you need to remember to fchown() it.
Which Casper Dik just noted is a Posix requirement. Don't you just
LOVE those Posix specs?
Grant Kaufmann (grant@intekom.com) wrote:
> I believe the solution should:
[...]
> - Require that the programmer conforms to some programming
> guidelines, be it the use of a new system call, checking environment
> variables, etc.
This is true and acceptable for setuid programs where the requirement
"the programmer needs to know about security issues" is a valid
one. But joe-user should be able to write a shell script that doesn't
open up his account to mis-use.
> > 4) A special "/tmp" directory, that's private for every userid.
> This is the same as option 3. It is also a new filesystem type with
> particular characteristics. This would be a problem in that users often
> use /tmp as a place to transfer files between each other.
So /tmp for two different users aren't the same anymore. So user2
will have to say: "cp /.tmp/user1/file ." when she gets
"/tmp/file: not found".
> The direct problem is that a security risk exists when programs
> write temporary files to a common location. Indirectly the problem
> is that programmers do not have the tools to get around this
> problem. Your solution does provide such a tool, but would
> respecting $TMPDIR not achieve the same result?
Yes. It would go a long way. However:
- fixing all applications is a lot of work. (e.g. try getting such a patch
into a LARGE package like gcc).
- The casual script isn't affected.
> There would need to be a way to identify what the value of the link
> is (/usr/cad/cad_$cad_version) as opposed to what it expands to
> (/usr/cad/cad_5.0). Without this, administering this would be
> difficult.
Right. I expect "readlink" to simply return "cad_${cad_version}",
without any modifications to ls and the like that would list as such.
Programs using explicit "readlink" and then opening "the result" will
break. Anybody know a good reason why you would want to do this? (*)
> One final question, if you can variable-expand symlinks, why not
> standard files as well? Imagine a system with 3 consoles, each using
> /dev/mouse, which is actually a link to /dev/mouse_$consolenbr.
YES! That's exactly what I had in mind: the "varlink" feature is not
only restricted to fixing a security problem related to /tmp. You're
perfectly welcome to use it for different purposes.
I also got reactions from the following people. An extremely short
summary follows:
Mike Johnson (Mike.Johnson@GSC.GTE.Com): good idea, I'll betatest.
Don Marti (dmarti@electriclichen.com): the varlink could point off the
root partition, working towards a read-only root.
Greg Alexander (gralexan@indiana.edu): good idea, I'll betatest.
Regards,
Roger Wolff.
(*) Web servers, when directed to selectively ignore symlinks will
probably fall under this category, right? instead of just opening a
file, to make sure you ignore the right symlinks, you'll have to
readlink and follow the link yourself. This is a case of "code
duplication" (kernel/web deamon) which can be expected to lead to
trouble.
--
If it's there and you can see it, it's REAL |___R.E.Wolff@BitWizard.nl |
If it's there and you can't see it, it's TRANSPARENT | Tel: +31-15-2137555 |
If it's not there and you can see it, it's VIRTUAL |__FAX:_+31-15-2138217 |
If it's not there and you can't see it, it's GONE! -- Roy Wilks, 1983 |_____|
--
----------------------------------------------------------------------
Please refer to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null
