The OpenNET Project
 
Search (keywords):  SOFT ARTICLES TIPS & TRICKS SECURITY
LINKS NEWS MAN DOCUMENTATION


/tmp system shortcomings


<< Previous INDEX Search src Set bookmark Go to bookmark Next >>
X-RDate: Wed, 11 Mar 1998 15:16:15 +0500 (ESK)
Date: Sun, 8 Mar 1998 10:02:59 -0800
From: Kill9 <kill9@SUCCEED.NET>
To: BUGTRAQ@NETSPACE.ORG
Subject: /tmp system shortcomings

> All this complexity of trivial things (just open a temp file) is one
> of the reasons I think the whole idea of /tmp is a fundamental
> misdesign and eventually one should be able to chmod it to 755 (while
> programs should use per-user TMPDIRs).


Maybe I'm a little off this morning, but even per-user TMPDIR's aren't a
very good solution.  So you make a tmp directory somewhere for each user
(technically I don't think it matters where) and set the directory
permissions so that only that user has read/write/execute.  Yes, that will
stop other users from creating symlinks and such and waiting to trap
innocent users.

But,

If all the programs Joe user runs now creates files in /usr/home/joe/tmp and
one of the programs is suid root and is vulnerable to a symlink attack then
no other users can abuse that program... except Joe.  Joe can still symlink
attack programs because he controls all the files in his tmp directory.  I
suppose he could even do a pipe attack against himself (as described in the
gcc post earlier),  but for that to be worth while it would have to be a
suid program thinking it was a trusted pipe it was reading trusted data
from...anyway

If programs create files in their effective user id tmp space (ie Joe runs a
suid root program so it creates files in /root/tmp)
then Joe couldn't abuse the symlinks, but now we are forcing programs to
open and write to files as root, rather than at least trying to convince
authors to give away permissions and open and write as the user.  I think
this would be a very bad thing.


Perhaps there should be a new Temp Filesystem that creates temp files off in
an untouchable area like the proc filesystem.  Only programs that call
mktemp get a filehandle in there, no symlinks allowed. Of course, this would
have to be handled at the kernel level... but done properly it could
eliminate a gob of poorly written code.

Pro's con's caveats?

Kill9

(ducking for cover)

<< Previous INDEX Search src Set bookmark Go to bookmark Next >>



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру