6393635 2001-04-20 22:28 +0930 /39 rader/ Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-21 17:52 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: matthew@DATADELIVERANCE.COM
Mottagare: Bugtraq (import) <16689>
Ärende: Linux patches to solve /tmp race problem
------------------------------------------------------------
From: "Donaldson, Matthew" <matthew@DATADELIVERANCE.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <15072.12895.627024.191687@localhost.localdomain>
Hi all,
I have recently developed some patches to the Linux 2.2 kernels which
solve the /tmp race problem without needing to define environment
variables - useful particularly for naive applications and scripts
which dont use TMPDIR and friends.
The patch creates "dynamic" symlinks, which point to different paths
depending on the user accessing them (for example, including the UID
in the path name). Such a link can be placed instead of /tmp and/or
/var/tmp, and any other similar directories. More usefully, these
links can be configured to automatically create the directory they
refer to if it does not exist.
This means you can create a directory such as /tmp_files, for
example, and have the /tmp link automatically create user directories
in it on demand. Default permissions and ownership can be specified.
The patches are available from http://www.datadeliverance.com in the
Linux Patches section, along with a full discussion of the issues
involved. Your comments on the scheme are invited.
Cheers
-Matthew
--
+--------------------------------------------------------------------------+
| Matthew Donaldson http://www.datadeliverance.com |
| Data Deliverance Pty. Ltd. Email: matthew@datadeliverance.com |
| 30 Musgrave Ave. Phone: +61 8 8265 7976 _ |
| Banksia Park Fax: +61 8 8265 0032 John / \/ |
| South Australia 5091 3:16 \_/\ |
+--------------------------------------------------------------------------+
(6393635) /Donaldson, Matthew <matthew@DATADELIVERANCE.COM>/(Ombruten)
Kommentar i text 6396864 av Christoph Hellwig <hch@CALDERA.DE>
Kommentar i text 6409506 av Chris Wright <chris@WIREX.COM>
6396864 2001-04-22 15:12 +0200 /66 rader/ Christoph Hellwig <hch@CALDERA.DE>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-22 20:01 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: hch@CALDERA.DE
Mottagare: Bugtraq (import) <16697>
Kommentar till text 6393635 av Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
From: Christoph Hellwig <hch@CALDERA.DE>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010422151202.A7880@caldera.de>
Hi Matthew,
In article <15072.12895.627024.191687@localhost.localdomain> you wrote:
> I have recently developed some patches to the Linux 2.2 kernels which solve
> the /tmp race problem without needing to define environment variables -
> useful particularly for naive applications and scripts which dont use
> TMPDIR and friends.
>
> The patch creates "dynamic" symlinks, which point to different paths
> depending on the user accessing them (for example, including the UID in the
> path name). Such a link can be placed instead of /tmp and/or /var/tmp, and
> any other similar directories. More usefully, these links can be configured
> to automatically create the directory they refer to if it does not exist.
>
> This means you can create a directory such as /tmp_files, for example, and
> have the /tmp link automatically create user directories in it on demand.
> Default permissions and ownership can be specified.
I think your proposal is a really kludgy hack. While the idea of
user-specific namespaces in gerneral is a very good idea, your patch
is far to ungeneric.
An sane implementation of the same concept can easily be done using
Al Viro's namespace patches for Linux 2.4 (Latest version is
namespaces-b-S3-pre8.gz in ftp.math.psu.edu:/pub/viro) - this patch
allows an additional parameter (CLONE_NEWNS) to be passed to
clone(2), Linux's syscall for the creation of rfork-style
variable-weight processes which will setup an completly different
mount table (copied from the parent).
In this particular case the login process would create the users
login shell's process using CLONE_NEWS and use the Linux 2.4+ of
namespace bindings to create a private temp directory. The following
code sequence (untested and simplified) should give a hint how to
implement the private tmpdir binding after the clone(...,
CLONE_NEWNS):
>> pw = getpwent();
>> if (pw) {
>> strlcpy(tmpdir, pw->pw_dir, MAXTMPDIR);
>> strlcat(tmpdir, "/tmp", MAXTMPDIR);
>> createifdoesnotexist(tmpdir);
>> mount(tmpdir, "/tmp", "dontcare", MS_BIND, NULL);
>> }
Besides the general conceptual flaws your patch also has some
implementation problems. First your tmpdir-creation is implemented
in the filesystem specific kernel code and not in the VFS. What does
your patch with /tmp on nfs or reiserfs? - nothing. Secondly you are
checking against an effective userid of zero in your code - as Linux
2.2 uses an Posix 1003.1e (draft, whitedrawn) capability model and
the old Unix model of comparing against the zero user id is
considered legacy this is a very bad idea.
An better implementation of context-sensitive directories is Malcolm
Beattie mlsfs. It's implemented as it's own filesystem so it is
completly independand of the undelying phsical filesystem. It's home
on the web is at http://users.ox.ac.uk/~mbeattie/linux-kernel.html.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
(6396864) /Christoph Hellwig <hch@CALDERA.DE>/(Ombruten)
Kommentar i text 6402991 av Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
6402991 2001-04-23 14:39 +0930 /170 rader/ Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-23 21:57 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: matthew@DATADELIVERANCE.COM
Mottagare: Bugtraq (import) <16720>
Kommentar till text 6396864 av Christoph Hellwig <hch@CALDERA.DE>
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
From: "Donaldson, Matthew" <matthew@DATADELIVERANCE.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <15075.47362.362351.404030@localhost.localdomain>
Christoph Hellwig writes:
>
>Hi Matthew,
>
[...]
>
Hi Christoph,
Thanks for your input. You have raised a number of interesting
points, which are addressed in more detail inline. Some of these I
should probably have included in the documentation in the first place.
I should perhaps note here first that the implementation of these
symlinks is a work in progress - I have done it the way I have to get
it going, and am not entirely happy with it as it stands. I am sure
there are better ways of implenting them, and am interested in
technical Linux implementation comments about that offline.
However, regardless of the implementation details, I think that there
is a lot to be said for the concept of these symlinks, and I am
interested in feedback on what people think of their level of
usefulness and scope. Also of interest would be feedback about the
various security implications that relate to them.
It should be noted that the concept of symlinks with dynamically
calculated path names is not a new one - various Unices have
implemented them at one time or another with various variables and
syntaxes. What makes this version perhaps a bit unusual is the
combination of dynamically calculated path names with automatically
creating the target if it does not exist.
I have aimed with this patch to do one thing - dynamic symlinks -
with the aim of solving a particular (perhaps small in scope, but
widely occuring) set of problems, revolving around /tmp races. There
are other solutions that do a whole lot more as well, like turning a
machine into a series of independent compartments. This is great for
those who need that, but introduces more complexity (and potentially
bugs) for those who don't.
More comments inline...
>I think your proposal is a really kludgy hack. While the idea of
>user-specific namespaces in gerneral is a very good idea, your patch is far
>to ungeneric.
Yes, I agree. It would be nice to be able to have a user-extensible
syntax for these symlinks. This is one of the major problems I have
with the current implementation. Though it does solve the /tmp race
problem, you can't add new dynamic symlink types of your own.
Perhaps some trickery with loadable modules might help.
From a security perspective, one could argue that the less
configurable it is the better - particularly for something like a
firewall. Nevertheless, from an architectural standpoint I agree
that there would be better ways of implementing this.
>
>An sane implementation of the same concept can easily be done using Al Viro's
>namespace patches for Linux 2.4 (Latest version is namespaces-b-S3-pre8.gz in
>ftp.math.psu.edu:/pub/viro) - this patch allows an additional parameter
>(CLONE_NEWNS) to be passed to clone(2), Linux's syscall for the creation of
>rfork-style variable-weight processes which will setup an completly different
>mount table (copied from the parent).
>
>In this particular case the login process would create the users login
>shell's process using CLONE_NEWS and use the Linux 2.4+ of namespace
>bindings to create a private temp directory. The following code sequence
>(untested and simplified) should give a hint how to implement the private
>tmpdir binding after the clone(..., CLONE_NEWNS):
>
>>> pw = getpwent();
>>> if (pw) {
>>> strlcpy(tmpdir, pw->pw_dir, MAXTMPDIR);
>>> strlcat(tmpdir, "/tmp", MAXTMPDIR);
>>> createifdoesnotexist(tmpdir);
>>> mount(tmpdir, "/tmp", "dontcare", MS_BIND, NULL);
>>> }
>
Yes, this is another way of doing something similar. Notice however
that it requires the modification of programs such as login (or
in.rshd or in.sshd or X scripts or any other way that exists to get
into the system, or that will be created later to get into the
system) to set up these things. (Also, I think you will find not
many people run 2.4 kernels at the moment...)
There are plenty of solutions around which require modification of
programs. These symlinks allow programs to run as normal, making the
kernel do the work. Once the kernel is replaced and the symlinks are
created, the problem is solved.
>Besides the general conceptual flaws your patch also has some implementation
>problems. First your tmpdir-creation is implemented in the filesystem
>specific kernel code and not in the VFS. What does your patch with /tmp
Yes, I should have mentioned this in the docco. My 2.4 patches do
this more generically, but in 2.2 they are for ext2 only. My
apologies for the omission - the docco has been updated. The 2.4
patches are not yet ready to be released, but I hope to get around to
finishing them in the next couple of weeks.
[Technical discussion] The reason that the 2.2 patches are ext2-only
is that under 2.2, all you get in the do_follow_link entry point is
the dentry structs. These do not (necessarily) include the name of
the link. Getting this generically in 2.2 does not appear to be easy
- it is documented that calling readlink (which would be the generic
way of getting the symlink value out) may yield different results
from what follow_link gets. 2.4 has functions which deal with the
path names directly, which make life easier. So I chose to just deal
with ext2 for the 2.2 case for now.
If you want to discuss this further I'd be glad to do so offline.
[End technical discussion]
>on nfs or reiserfs? - nothing. Secondly you are checking against an
>effective userid of zero in your code - as Linux 2.2 uses an Posix 1003.1e
>(draft, whitedrawn) capability model and the old Unix model of comparing
>against the zero user id is considered legacy this is a very bad idea.
Yes, I am well aware of the capability model and the legacy zero user
id. I assume you are referring to my "root" symbolic link type.
This is not part of the code for the uid-based symlinks that form the
basis of the /tmp race solution.
For those who haven't had a look, the patch includes another symlink
type, as well as the uid-based one, that points to one place if the
UID is 0, and another if it is non-zero. This was included more as a
demonstration of the sort of things that could be done with these
links, rather than anything else.
The uid-based symlink code is capability-aware, and the discussion
refers to the issues involved with capabilities in the current
implementation.
>
>An better implementation of context-sensitive directories is Malcolm Beattie
>mlsfs. It's implemented as it's own filesystem so it is completly
>independand of the undelying phsical filesystem. It's home on the web is at
>http://users.ox.ac.uk/~mbeattie/linux-kernel.html.
A most interesting product - great for people looking for B2 Linux
systems, but one that is a "very early alpha release". I'm taking a
different approach and providing a solution for one specific problem:
the /tmp race hole and problems like it. Because this is easier, I
have something with less features, but that is up and going today.
I did consider using a filesystem instead of symlinks to solve this
problem, but the method I chose seemed easier, simpler to use and
just as useful for most purposes. Under 2.4 this is done generically,
without reference to the underlying filesystem. Perhaps the main
advantage of using a filesystem is to allow this to work inside
filesystems that do not support symlinks. For the purpose in hand, I
think if /tmp were mounted on a filesystem not supporting symlinks,
many things would break.
Thanks again for your comments
Cheers
-Matthew
--
+--------------------------------------------------------------------------+
| Matthew Donaldson http://www.datadeliverance.com |
| Data Deliverance Pty. Ltd. Email: matthew@datadeliverance.com |
| 30 Musgrave Ave. Phone: +61 8 8265 7976 _ |
| Banksia Park Fax: +61 8 8265 0032 John / \/ |
| South Australia 5091 3:16 \_/\ |
+--------------------------------------------------------------------------+
(6402991) /Donaldson, Matthew <matthew@DATADELIVERANCE.COM>/(Ombruten)
Kommentar i text 6403722 av Christoph Hellwig <hch@CALDERA.DE>
6403722 2001-04-23 12:02 +0200 /82 rader/ Christoph Hellwig <hch@CALDERA.DE>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-23 23:47 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: hch@CALDERA.DE
Mottagare: Bugtraq (import) <16725>
Kommentar till text 6402991 av Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
From: Christoph Hellwig <hch@CALDERA.DE>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010423120228.A8943@caldera.de>
On Mon, Apr 23, 2001 at 02:39:22PM +0930, matthew@datadeliverance.com wrote:
> >I think your proposal is a really kludgy hack. While the idea of
> >user-specific namespaces in gerneral is a very good idea, your patch is far
> >to ungeneric.
>
> Yes, I agree. It would be nice to be able to have a user-extensible syntax
> for these symlinks. This is one of the major problems I have with the
> current implementation. Though it does solve the /tmp race problem, you
> can't add new dynamic symlink types of your own. Perhaps some trickery with
> loadable modules might help.
>
> From a security perspective, one could argue that the less configurable it is
> the better - particularly for something like a firewall. Nevertheless, from
> an architectural standpoint I agree that there would be better ways of
> implementing this.
The real problem is the missing design behind it. Sure your problem
solves one particular probem (tmpfile races), but it's nothing that
seems to have a chance of ever getting integrated into an official
kernel - for a good reason.
While you might say that it's not a point I think as such a patch it
worth most for the people that don't really care a lot for their
system security - people that don't upgrade evey single package on a
advisotory, etc...
> Yes, this is another way of doing something similar. Notice however that it
> requires the modification of programs such as login (or in.rshd or in.sshd or
> X scripts or any other way that exists to get into the system, or that will
> be created later to get into the system) to set up these things. (Also, I
> think you will find not many people run 2.4 kernels at the moment...)
Correct.
> There are plenty of solutions around which require modification of programs.
> These symlinks allow programs to run as normal, making the kernel do the
> work. Once the kernel is replaced and the symlinks are created, the problem
> is solved.
Do you really think realcing login is so much more work than replacing
a kernel?
> Yes, I should have mentioned this in the docco. My 2.4 patches do this more
> generically, but in 2.2 they are for ext2 only. My apologies for the
> omission - the docco has been updated. The 2.4 patches are not yet ready to
> be released, but I hope to get around to finishing them in the next couple of
> weeks.
Good.
> A most interesting product - great for people looking for B2 Linux systems,
> but one that is a "very early alpha release". I'm taking a different
> approach and providing a solution for one specific problem: the /tmp race
> hole and problems like it. Because this is easier, I have something with
> less features, but that is up and going today.
Yes. I didn't want to compare the whole implementation of Mandatory
Access Comtrolls to your work - instead I think you should take a
look at the mlsfs as it implements a functionality similar to your
dynamic symlinks (the multilevel directories) but is implemented as
one fs instead of requiring filesystem specific changes.
> I did consider using a filesystem instead of symlinks to solve this problem,
> but the method I chose seemed easier, simpler to use and just as useful for
> most purposes. Under 2.4 this is done generically, without reference to the
> underlying filesystem. Perhaps the main advantage of using a filesystem is
> to allow this to work inside filesystems that do not support symlinks. For
> the purpose in hand, I think if /tmp were mounted on a filesystem not
> supporting symlinks, many things would break.
I think the greatest advantage of the filesystem appropeach is that
it doesn not require changes to the kernel at all but can be a
loadable module instead.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
(6403722) /Christoph Hellwig <hch@CALDERA.DE>/(Ombruten)
Kommentar i text 6403582 av Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
6403582 2001-04-23 22:55 +0930 /129 rader/ Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-23 23:22 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: matthew@DATADELIVERANCE.COM
Mottagare: Bugtraq (import) <16723>
Kommentar till text 6403722 av Christoph Hellwig <hch@CALDERA.DE>
Sänt: 2001-04-23 23:47
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
From: "Donaldson, Matthew" <matthew@DATADELIVERANCE.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <15076.11581.958469.19090@localhost.localdomain>
Christoph Hellwig writes:
>> Yes, I agree. It would be nice to be able to have a user-extensible syntax
>> for these symlinks. This is one of the major problems I have with the
>> current implementation. Though it does solve the /tmp race problem, you
>> can't add new dynamic symlink types of your own. Perhaps some trickery with
>> loadable modules might help.
>>
>> From a security perspective, one could argue that the less configurable it is
>> the better - particularly for something like a firewall. Nevertheless, from
>> an architectural standpoint I agree that there would be better ways of
>> implementing this.
>
>The real problem is the missing design behind it. Sure your problem solves
I disagree. You might not like the design behind it, but that does
not mean there isn't any. Just because it is not in a kernel module
doesn't mean it is inherently un-designed and bad. In fact, a lot of
thought has gone into its design.
>one particular probem (tmpfile races), but it's nothing that seems to have
>a chance of ever getting integrated into an official kernel - for a good
>reason.
Well, that's an issue for the maintainers (of which perhaps you are
one), and ultimately for Linus I suppose. As I mentioned before,
dynamic symlinks (though without auto-creation of targets) are not
new, and have existed in various forms over the years. They have
been used to select appropriate binary directories depending on OS
type for example. (Yes I know you'll probably say "amd can do that
better", but that is just one example of how they were used. You can
use them for other things too - e.g. .profile files selected based on
which host/arch type you are on).
Ordinary symlinks are part of the kernel too, yet nobody calls them
missing in design! If people consider that these dynamic symlinks
(presumably with more types and selectors than the few that I have
put in) are something that they want in the kernel (which is not
unheard-of in Unices before now), because there are enough uses for
them, then presumably they will go in. If not, they won't. Or they
might be incorporated in some very modified form. This is not a call
you or I can make by ourselves.
One potential use, for example, might be a student handin system,
where there is a symlink pointing to a uid-based file name in an
unwritable directory. Students (via an unprivileged program perhaps)
write their assignments tar file to this file (yes dynamic symlinks
work for files as well as directories), which is created if needed.
Students can't create files in there themselves, or touch other
people's files.
I have presented this stuff as a possible solution to a problem, and
one which might have wider uses. People will either like it or not.
If not, there are clearly other ways to go about it, which will have
their own drawbacks and advantages.
>
>While you might say that it's not a point I think as such a patch it worth
>most for the people that don't really care a lot for their system security -
>people that don't upgrade evey single package on a advisotory, etc...
I agree, though for things like firewalls it could be a good thing
too (even if you patch after every advisory, the holes are there
before they are announced...) This is a catch-all, like stack
guarding software. Obviously it would be nicer to fix all the buffer
overflows, but...
[...]
>> There are plenty of solutions around which require modification of programs.
>> These symlinks allow programs to run as normal, making the kernel do the
>> work. Once the kernel is replaced and the symlinks are created, the problem
>> is solved.
>
>Do you really think realcing login is so much more work than replacing
>a kernel?
If it were just replacing login, I would agree with you. But not
everything coming into a Unix system comes via login. There are a
number of daemons, X-window systems and so forth that do their own
thing. On top of the existing ones, someone might decide to compile
some ssh version or some other daemon, and put that up. Anything
that creates a process on a Unix system and runs things is a
potential entry point. It need not be even be related to loggin in.
Cron, for example, runs processes as different users, but doesn't run
login.
Changing the binaries requires:
1. Finding all the ways that the system can initiate process trees for people
2. Patching each one
3. Making sure that all new ways into the system are patched before they are
installed
I think the single action of replacing the kernel (which is not very
hard if you have the kernel binary) is much easier, and also much
more likely to catch all cases.
[...]
>
>Yes. I didn't want to compare the whole implementation of Mandatory Access
>Comtrolls to your work - instead I think you should take a look at the mlsfs
>as it implements a functionality similar to your dynamic symlinks (the
>multilevel directories) but is implemented as one fs instead of requiring
>filesystem specific changes.
[...]
>I think the greatest advantage of the filesystem appropeach is that it doesn
>not require changes to the kernel at all but can be a loadable module instead.
This is indeed a big advantage - I agree. However using symlinks
(whilst it does mean a kernel change) has advantages too. For
example, normal users can create these links, without having to worry
about priveleges needed to mount things (and have them automatically
remounted at boot time) and without cluttering up the mount table.
Mounting filesystems in various places is one solution to the
problem; dynamic symlinks are another. Each has advantages and
disadvantages.
Cheers
-Matthew
--
+--------------------------------------------------------------------------+
| Matthew Donaldson http://www.datadeliverance.com |
| Data Deliverance Pty. Ltd. Email: matthew@datadeliverance.com |
| 30 Musgrave Ave. Phone: +61 8 8265 7976 _ |
| Banksia Park Fax: +61 8 8265 0032 John / \/ |
| South Australia 5091 3:16 \_/\ |
+--------------------------------------------------------------------------+
(6403582) /Donaldson, Matthew <matthew@DATADELIVERANCE.COM>/(Ombruten)
Kommentar i text 6409023 av Tollef Fog Heen <tollef@ADD.NO>
Kommentar i text 6409112 av Crispin Cowan <crispin@WIREX.COM>
6409023 2001-04-24 10:15 +0200 /28 rader/ Tollef Fog Heen <tollef@ADD.NO>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-25 07:18 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: tollef@ADD.NO
Mottagare: Bugtraq (import) <16757>
Kommentar till text 6403582 av Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
From: Tollef Fog Heen <tollef@ADD.NO>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <87u23esohm.fsf@arabella.intern.opera.no>
* "Donaldson, Matthew"
| If it were just replacing login, I would agree with you. But not everything
| coming into a Unix system comes via login. There are a number of daemons,
| X-window systems and so forth that do their own thing. On top of the
| existing ones, someone might decide to compile some ssh version or some other
| daemon, and put that up. Anything that creates a process on a Unix system
| and runs things is a potential entry point. It need not be even be related
| to loggin in. Cron, for example, runs processes as different users, but
| doesn't run login.
PAM handles this quite nicely.
I've hacked together a PAM module which sets TMPDIR (and TMP) to
/tmp/user/uid, which I could probably make available (mail me if you
are interested). Fixing programs to use TMP and TMPDIR is the correct
solution.
--
Tollef Fog Heen Unix _IS_ user friendly... It's just selective about
who its friends are.
(6409023) /Tollef Fog Heen <tollef@ADD.NO>/(Ombruten)
Kommentar i text 6409324 av Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Kommentar i text 6412575 av Kurt Seifried <bugtraq@SEIFRIED.ORG>
6409324 2001-04-24 20:13 +0930 /53 rader/ Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-25 09:17 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: matthew@DATADELIVERANCE.COM
Mottagare: Bugtraq (import) <16763>
Kommentar till text 6409023 av Tollef Fog Heen <tollef@ADD.NO>
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
From: "Donaldson, Matthew" <matthew@DATADELIVERANCE.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <15077.22738.538531.577231@localhost.localdomain>
Tollef Fog Heen writes:
>* "Donaldson, Matthew"
>
>| If it were just replacing login, I would agree with you. But not everything
>| coming into a Unix system comes via login. There are a number of daemons,
>| X-window systems and so forth that do their own thing. On top of the
>| existing ones, someone might decide to compile some ssh version or some other
>| daemon, and put that up. Anything that creates a process on a Unix system
>| and runs things is a potential entry point. It need not be even be related
>| to loggin in. Cron, for example, runs processes as different users, but
>| doesn't run login.
>
>PAM handles this quite nicely.
>
>I've hacked together a PAM module which sets TMPDIR (and TMP) to
>/tmp/user/uid, which I could probably make available (mail me if you
Yes please - I'm interested in other viable solutions.
>are interested). Fixing programs to use TMP and TMPDIR is the correct
>solution.
Fixing programs is the _ideal_ solution, as is fixing software to
eliminate buffer overruns. However there is stack guarding software
because not all software is fixed, and not all vulnerabilities are
known. Similar principle applies here. We live in a non-ideal world.
You may argue that /tmp bugs are more obvious in the code than buffer
overruns, and they may be to some degree, but even so, someone's got
to look over the source code for everthing that's out there. Most
admins don't have time to do that for every piece of software they're
running, or can't (e.g. because it's non open-source). Having
something like this gives them the security that even if someone is
doing the Wrong Thing(tm), it does not put them at risk.
Cheers
-Matthew
--
+--------------------------------------------------------------------------+
| Matthew Donaldson http://www.datadeliverance.com |
| Data Deliverance Pty. Ltd. Email: matthew@datadeliverance.com |
| 30 Musgrave Ave. Phone: +61 8 8265 7976 _ |
| Banksia Park Fax: +61 8 8265 0032 John / \/ |
| South Australia 5091 3:16 \_/\ |
+--------------------------------------------------------------------------+
(6409324) /Donaldson, Matthew <matthew@DATADELIVERANCE.COM>/(Ombruten)
Kommentar i text 6409407 av Tollef Fog Heen <tollef@ADD.NO>
Kommentar i text 6414263 av Valdis Kletnieks <Valdis.Kletnieks@VT.EDU>
6409407 2001-04-24 15:34 +0200 /21 rader/ Tollef Fog Heen <tollef@ADD.NO>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-25 09:29 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: tollef@ADD.NO
Mottagare: Bugtraq (import) <16764>
Kommentar till text 6409324 av Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
From: Tollef Fog Heen <tollef@ADD.NO>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <87n196to9r.fsf@arabella.pvv.ntnu.no>
* Matthew Donaldson
| Tollef Fog Heen writes:
|
| >I've hacked together a PAM module which sets TMPDIR (and TMP) to
| >/tmp/user/uid, which I could probably make available (mail me if you
|
| Yes please - I'm interested in other viable solutions.
take a look at http://www.add.no/~tollef/software/pam_tmpdir.tgz .
--
Tollef Fog Heen Unix _IS_ user friendly... It's just selective about
who its friends are.
(6409407) /Tollef Fog Heen <tollef@ADD.NO>/(Ombruten)
6414263 2001-04-25 10:05 -0400 /18 rader/ Valdis Kletnieks <Valdis.Kletnieks@VT.EDU>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-26 03:09 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: Valdis.Kletnieks@VT.EDU
Mottagare: Bugtraq (import) <16775>
Kommentar till text 6409324 av Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
On Tue, 24 Apr 2001 20:13:30 +0930, "Donaldson, Matthew" <matthew@DATADELIVERANCE.COM> said:
> (e.g. because it's non open-source). Having something like this gives them
> the security that even if someone is doing the Wrong Thing(tm), it does not
> put them at risk.
Puts them at much less risk. The risk is still non-zero. (Consider
- does the patch fix race conditions that happen to involve both /tmp
*and* '..' in the pathname? What *other* end conditions are there?
Remember that "non executable stack" patches don't stop all buffer
overflows, they just make them a LOT harder to exploit.....
--
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
(6414263) /Valdis Kletnieks <Valdis.Kletnieks@VT.EDU>/(Ombruten)
Bilaga (application/pgp-signature) i text 6414264
Kommentar i text 6414359 av Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
6414264 2001-04-25 10:05 -0400 /10 rader/ Valdis Kletnieks <Valdis.Kletnieks@VT.EDU>
Importerad: 2001-04-26 03:09 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: Valdis.Kletnieks@VT.EDU
Mottagare: Bugtraq (import) <16776>
Bilaga (text/plain) till text 6414263
Ärende: Bilaga till: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
Comment: Exmh version 2.2 06/16/2000
iQA/AwUBOubZxnAt5Vm009ewEQLaXgCeI9yGP9CZJwFjEfX2XsJ7jc3XAp0AoKEN
oTlf6I78EWlIUKU+coM2liXP
=CIrY
-----END PGP SIGNATURE-----
(6414264) /Valdis Kletnieks <Valdis.Kletnieks@VT.EDU>/
6414359 2001-04-26 01:14 +0930 /49 rader/ Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-26 06:57 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: matthew@DATADELIVERANCE.COM
Mottagare: Bugtraq (import) <16780>
Kommentar till text 6414263 av Valdis Kletnieks <Valdis.Kletnieks@VT.EDU>
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
From: "Donaldson, Matthew" <matthew@DATADELIVERANCE.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <15078.61650.196935.160361@localhost.localdomain>
Valdis.Kletnieks@vt.edu writes:
>On Tue, 24 Apr 2001 20:13:30 +0930, "Donaldson, Matthew" <matthew@DATADELIVERANCE.COM> said:
>> (e.g. because it's non open-source). Having something like this gives them
>> the security that even if someone is doing the Wrong Thing(tm), it does not
>> put them at risk.
>
>Puts them at much less risk. The risk is still non-zero. (Consider - does
>the patch fix race conditions that happen to involve both /tmp *and* '..'
>in the pathname? What *other* end conditions are there? Remember that
>"non executable stack" patches don't stop all buffer overflows, they just
>make them a LOT harder to exploit.....
I see your point about buffer overflows, but I'm not sure that the
same applies to /tmp races: maybe I'm missing something, but my
perception of the the essence of /tmp races is this: someone sticks a
symlink in /tmp just before a privileged user (e.g. root) is about to
create a file with that name. Privileged user doesn't check
properly, and writes stuff to the file the non-privileged user
selected.
If each user has a separate /tmp directory, unwritable by anyone
else, this is no longer possible, so far as I can see. Now maybe I'm
overlooking things here - I'd be most interested to hear of types of
/tmp races not solved by this proposal, and how using '..' in the
path name might make things trickier.
Now of course the price you pay is that if things are designed to
cooperate using files in /tmp, and they run as different users, you
have to make them agree on somewhere else to put files, or use a
different communication mechanism. More on that in my reply to Chris
Wright (tomorrow - it's getting late here), who raised that issue. X
is a particularly bad offender in this category, but there are some
fairly simple workarounds.
Cheers
-Matthew
--
+--------------------------------------------------------------------------+
| Matthew Donaldson http://www.datadeliverance.com |
| Data Deliverance Pty. Ltd. Email: matthew@datadeliverance.com |
| 30 Musgrave Ave. Phone: +61 8 8265 7976 _ |
| Banksia Park Fax: +61 8 8265 0032 John / \/ |
| South Australia 5091 3:16 \_/\ |
+--------------------------------------------------------------------------+
(6414359) /Donaldson, Matthew <matthew@DATADELIVERANCE.COM>/(Ombruten)
Kommentar i text 6414384 av Valdis Kletnieks <Valdis.Kletnieks@VT.EDU>
Kommentar i text 6419172 av Michal Zalewski <lcamtuf@BOS.BINDVIEW.COM>
6414384 2001-04-25 11:58 -0400 /36 rader/ Valdis Kletnieks <Valdis.Kletnieks@VT.EDU>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-26 07:14 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: Valdis.Kletnieks@VT.EDU
Mottagare: Bugtraq (import) <16781>
Kommentar till text 6414359 av Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
On Thu, 26 Apr 2001 01:14:18 +0930, matthew@datadeliverance.com said:
> I see your point about buffer overflows, but I'm not sure that the same
> applies to /tmp races: maybe I'm missing something, but my perception of the
> the essence of /tmp races is this: someone sticks a symlink in /tmp just
> before a privileged user (e.g. root) is about to create a file with that
> name. Privileged user doesn't check properly, and writes stuff to the
> file the non-privileged user selected.
Wasn't there a *LONG* thread a while ago about how to properly clean
a /tmp on a *secure* regular basis? (the problem being that a
malicious user could drop something into /tmp that ended up causing
the /tmp cleaner to clean the wrong thing....)
Remember - there's *two* race conditions - one for creating a file
(causing the victim to create a file other than where he thought),
and one for de-referencing a filename (causing the victim to read an
existing file other than the one he intended). /tmp cleaners are in
the second category....
Of course, there's still people out there getting burnt by a simple
find /tmp -mtime -7 -type f | xargs rm
Lots of joy to be found here - (like this:
mkdir /tmp/foo\n; touch /tmp/foo\n/vmunix
Wait a week,and watch the next reboot fail. Note that *this* little
gem will work even with separate per-user /tmp directories - this is
why GNU find/xargs have a -0 option.
--
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
(6414384) /Valdis Kletnieks <Valdis.Kletnieks@VT.EDU>/(Ombruten)
Bilaga (application/pgp-signature) i text 6414385
Kommentar i text 6418270 av Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
6414385 2001-04-25 11:58 -0400 /10 rader/ Valdis Kletnieks <Valdis.Kletnieks@VT.EDU>
Importerad: 2001-04-26 07:14 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: Valdis.Kletnieks@VT.EDU
Mottagare: Bugtraq (import) <16782>
Bilaga (text/plain) till text 6414384
Ärende: Bilaga till: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
Comment: Exmh version 2.2 06/16/2000
iQA/AwUBOub0OXAt5Vm009ewEQLPmACbB/os3Y1tBTuJkmwVeu7630u99mAAnj1f
x3aCl18qYYhQ3CV6wlFf+tb7
=/6Fi
-----END PGP SIGNATURE-----
(6414385) /Valdis Kletnieks <Valdis.Kletnieks@VT.EDU>/
6418270 2001-04-26 23:10 +0930 /70 rader/ Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-26 19:31 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: matthew@DATADELIVERANCE.COM
Mottagare: Bugtraq (import) <16801>
Kommentar till text 6414384 av Valdis Kletnieks <Valdis.Kletnieks@VT.EDU>
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
From: "Donaldson, Matthew" <matthew@DATADELIVERANCE.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <15080.9557.644885.172449@localhost.localdomain>
Valdis Kletnieks writes:
>On Thu, 26 Apr 2001 01:14:18 +0930, matthew@datadeliverance.com said:
>Wasn't there a *LONG* thread a while ago about how to properly clean a /tmp
>on a *secure* regular basis? (the problem being that a malicious user could
>drop something into /tmp that ended up causing the /tmp cleaner to clean
>the wrong thing....)
Yes, I remember that.
>
>Remember - there's *two* race conditions - one for creating a file (causing
>the victim to create a file other than where he thought), and one for
>de-referencing a filename (causing the victim to read an existing file other
>than the one he intended). /tmp cleaners are in the second category....
Yes you are right, this category could claim the title of /tmp race
condition as well. Having separate /tmp directories might help even
here though - see below.
>
>Of course, there's still people out there getting burnt by a simple
>
>find /tmp -mtime -7 -type f | xargs rm
>
>Lots of joy to be found here - (like this:
> mkdir /tmp/foo\n; touch /tmp/foo\n/vmunix
>Wait a week,and watch the next reboot fail. Note that *this* little
>gem will work even with separate per-user /tmp directories - this is
>why GNU find/xargs have a -0 option.
Because /tmp looks different for each user, one thing you could do to
increase safety (and I'm not necessarily recommending this, just
putting it up as an idea) is to run the cleanup code (e.g. tmpwatch)
once for each user.
e.g. (naively, ignoring NIS etc.)
for user in `cat /etc/passwd | cut -d: -f1`; do
su - $user -c cleanup_command
done
Cleanup programs (like tmpwatch) could be replaced by a wrapper that
calls the real cleanup program for each user. The above find command
executed as the normal user would not cause any problems. It seems
to me that under those circumstances the worst the user could do
would be to make booby traps that remove his/her own files.
One cost would be that presumably the cleanup would take longer,
being run for each user, but perhaps not so very much longer for a
non-enormous number of users. After all, the amount of files to be
scanned should be roughly the same.
Cheers
-Matthew
--
+--------------------------------------------------------------------------+
| Matthew Donaldson http://www.datadeliverance.com |
| Data Deliverance Pty. Ltd. Email: matthew@datadeliverance.com |
| 30 Musgrave Ave. Phone: +61 8 8265 7976 _ |
| Banksia Park Fax: +61 8 8265 0032 John / \/ |
| South Australia 5091 3:16 \_/\ |
+--------------------------------------------------------------------------+
(6418270) /Donaldson, Matthew <matthew@DATADELIVERANCE.COM>/(Ombruten)
6419172 2001-04-26 06:08 -0400 /46 rader/ Michal Zalewski <lcamtuf@BOS.BINDVIEW.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-27 01:52 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: lcamtuf@BOS.BINDVIEW.COM
Mottagare: Bugtraq (import) <16807>
Kommentar till text 6414359 av Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
From: Michal Zalewski <lcamtuf@BOS.BINDVIEW.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.21.0104260555400.15740-100000@nimue.bos.bindview.com>
On Thu, 26 Apr 2001, Donaldson, Matthew wrote:
> If each user has a separate /tmp directory, unwritable by anyone else,
> this is no longer possible, so far as I can see.
Just to let you know, there were a discussion about context-sensitive
/tmp solutions something approx. two years ago on BUGTRAQ, with two
suggested solutions (well, or "workarounds", as the solution is not
to use /tmp in insecure way):
- euid-sensitive /tmp pseudo-filesystem, redirected e.g. to ~/tmp
(do not know if there were any implementations, but that is
actually pretty neat idea to use fs driver similar to /proc)
- euid-sensitive operations to redirect /tmp in the same manner
(I even made some Linux 2.0 module do implement it; it was
called redtmp and should be somewhere in archives)
Both of them would break many programs, like X server-client
connectivity, as mentioned in this thread. One of suggested
workarounds was to redirect any operations that involve creating fs
objects in per-user /tmp space, and handle all others (namely
attempts to open w/o O_CREAT, connect etc) by doing lookup in
per-user /tmp space, and, if not found there, in root /tmp space. It
causes some risk that can be avoided by properly setting umask for
root.
There are some possible issues with using ~/tmp, as well - not every
user has to have writable ~ directory, sometimes user home dirs are
mounted via nfs and that would cause additional load, and so on.
Moreover, it is hard to choose between using euid or uid for
switching. Using euid would probably break even more setuid
programs. But using uid would allow user to run setuid applications
with /tmp redirected to a directory which has no sticky bit, and to
perform nasty attacks.
--
_______________________________________________________
Michal Zalewski [lcamtuf@bos.bindview.com] | [security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=--=> Did you know that clones never use mirrors? <=--=
(6419172) /Michal Zalewski <lcamtuf@BOS.BINDVIEW.COM>/(Ombruten)
6412575 2001-04-25 00:04 -0600 /25 rader/ Kurt Seifried <bugtraq@SEIFRIED.ORG>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-25 18:10 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: bugtraq@SEIFRIED.ORG
Mottagare: Bugtraq (import) <16768>
Kommentar till text 6409023 av Tollef Fog Heen <tollef@ADD.NO>
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
From: Kurt Seifried <bugtraq@SEIFRIED.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <008601c0cd4d$87cb5700$3200030a@seifried.org>
> PAM handles this quite nicely.
>
> I've hacked together a PAM module which sets TMPDIR (and TMP) to
> /tmp/user/uid, which I could probably make available (mail me if you
> are interested). Fixing programs to use TMP and TMPDIR is the correct
> solution.
>
> --
>
> Tollef Fog Heen
No need for that when we have "pam_env". From the docs "This module
allows the (un)setting of environment variables. Supported is the use
of previously set environment variables as well as PAM_ITEMs such as
PAM_RHOST."
/etc/security/pam_env.conf
Kurt Seifried, seifried@securityportal.com
Securityportal - your focal point for security on the 'net
(6412575) /Kurt Seifried <bugtraq@SEIFRIED.ORG>/(Ombruten)
Kommentar i text 6414590 av Tollef Fog Heen <tollef@ADD.NO>
6414590 2001-04-25 18:25 +0200 /33 rader/ Tollef Fog Heen <tollef@ADD.NO>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-26 08:51 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: tollef@ADD.NO
Mottagare: Bugtraq (import) <16789>
Kommentar till text 6412575 av Kurt Seifried <bugtraq@SEIFRIED.ORG>
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
From: Tollef Fog Heen <tollef@ADD.NO>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <87k849aqvv.fsf@arabella.pvv.ntnu.no>
* Kurt Seifried
| > PAM handles this quite nicely.
| >
| > I've hacked together a PAM module which sets TMPDIR (and TMP) to
| > /tmp/user/uid, which I could probably make available (mail me if you
| > are interested). Fixing programs to use TMP and TMPDIR is the correct
| > solution.
|
| No need for that when we have "pam_env". From the docs "This module allows the
| (un)setting of environment variables. Supported is the use of previously set
| environment variables as well as PAM_ITEMs such as PAM_RHOST."
|
| /etc/security/pam_env.conf
I couldn't get it to set TMP to something which was per-user (which is
probably easy, but it wouldn't cooperate with me), and it doesn't (and
shouldn't) create the tmpdir for you. This is implemented in a nicer
(imho) way in pam_tmpdir which removes the need for world writable
/tmp/user/ . An alternative which would be able to do the exact same
thing is get pam_env to set TMP and TMPDIR and have a suid
create-tmpdir-program which creates the /tmp/user/$UID .
--
Tollef Fog Heen Unix _IS_ user friendly... It's just selective about
who its friends are.
(6414590) /Tollef Fog Heen <tollef@ADD.NO>/(Ombruten)
6409112 2001-04-23 17:50 -0700 /33 rader/ Crispin Cowan <crispin@WIREX.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-25 08:05 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: crispin@WIREX.COM
Mottagare: Bugtraq (import) <16760>
Kommentar till text 6403582 av Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
From: Crispin Cowan <crispin@WIREX.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3AE4CDDF.107CD954@wirex.com>
"Donaldson, Matthew" wrote:
> I disagree. You might not like the design behind it, but that does not mean
> there isn't any. Just because it is not in a kernel module doesn't mean it
> is inherently un-designed and bad. In fact, a lot of thought has gone into
> its design.
Perhaps instead of battling to get the kernel maintainers to accept
this patch, you'd consider actually making it a module. We're
working on a Linux Security Module (LSM) extension to the existing
module interface, precisely so that the kernel maintainers don't have
to wrangle with whether or not to accept a given security patch.
If you're interested in modularizing your work, then we need your
input on what hooks the LSM should provide to modules. E.g. some
discussion today came up about whether we have sufficient hooks in
place to support Solar Designer's "don't let suid programs follow
symlinks in stickbit dirs" patch. We need your input on the LSM
interface if it is to support your enhancement.
Subscribe here
http://mail.wirex.com/mailman/listinfo/linux-security-module
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution: http://immunix.org
(6409112) /Crispin Cowan <crispin@WIREX.COM>/(Ombruten)
6409506 2001-04-23 15:30 -0700 /33 rader/ Chris Wright <chris@WIREX.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-25 09:47 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: chris@WIREX.COM
Mottagare: Bugtraq (import) <16765>
Kommentar till text 6393635 av Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
From: Chris Wright <chris@WIREX.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010423153042.A17422@figure1.int.wirex.com>
* Donaldson, Matthew (matthew@DATADELIVERANCE.COM) wrote:
> Hi all,
>
> I have recently developed some patches to the Linux 2.2 kernels which solve
> the /tmp race problem without needing to define environment variables -
> useful particularly for naive applications and scripts which dont use
> TMPDIR and friends.
>
> The patch creates "dynamic" symlinks, which point to different paths
> depending on the user accessing them (for example, including the UID in the
> path name). Such a link can be placed instead of /tmp and/or /var/tmp, and
> any other similar directories. More usefully, these links can be configured
> to automatically create the directory they refer to if it does not exist.
>
> This means you can create a directory such as /tmp_files, for example, and
> have the /tmp link automatically create user directories in it on demand.
> Default permissions and ownership can be specified.
>
> The patches are available from http://www.datadeliverance.com in the Linux
> Patches section, along with a full discussion of the issues involved. Your
> comments on the scheme are invited.
After reading the explanation of your work, I missed how you can
actually have global data in the /tmp directory. For example,
/tmp/.font-unix or /tmp/.X11-unix.
-chris
(6409506) /Chris Wright <chris@WIREX.COM>/(Ombruten)
Kommentar i text 6414609 av Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
6414609 2001-04-26 14:05 +0930 /87 rader/ Donaldson, Matthew <matthew@DATADELIVERANCE.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-04-26 08:55 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: matthew@DATADELIVERANCE.COM
Mottagare: Bugtraq (import) <16790>
Kommentar till text 6409506 av Chris Wright <chris@WIREX.COM>
Ärende: Re: Linux patches to solve /tmp race problem
------------------------------------------------------------
From: "Donaldson, Matthew" <matthew@DATADELIVERANCE.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <15079.42384.548967.740904@localhost.localdomain>
Chris Wright writes:
>
>After reading the explanation of your work, I missed how you can actually have
>global data in the /tmp directory. For example, /tmp/.font-unix or
>/tmp/.X11-unix.
>
Currently, there is no way to have global /tmp data. This may prove
to be a problem - I'd be interested to know how many programs out
there actually require /tmp data shared between users. IMHO, sharing
files via /tmp between users is not good practice anyway, and
encourages security holes, but that's another story.
For things that honour TMP or TMPDIR, you may be able to get away
with setting these variables to a new /tmp-link shared directory,
before running the program(s) that need it. For things like X that
make directories in /tmp, you can use symlinks to point to this
shared directory. More on that later for X specifically.
Now you might say, "hey you're making a shared directory - now we've
got our tmp race problem back again". Which is true in a way, but
with the following (important) improvements:
1. we know which programs are using it, because we made them use it
2. we may have the opportunity of setting permissions so that only the two
users involved can use it
#2 could be done using a shared group, or ACLs at such time as they are
incorporated into the kernel. If root and another program need to share
a directory, you could even go further, particularly if it involved root
writing to the directory, then the normal user reading it. In that case
you can write a wrapper that does this:
* chowns the shared dir to root and stops the other user writing to it
* runs the real program
* chowns the shared dir to the normal user
I'm not saying any of these solutions are particularly nice, but
(hopefully) the number of programs needing such things is small. The
big benefit is that you know that no programs are going to be
creating files in a shared /tmp directory unless you have
specifically organised for it to happen.
Note that as root you can portably make links in other people's /tmp
using something like this:
su - $user -c 'ln -s file1 file2'
You can copy stuff from root's /tmp to a user's using either
tar cfP - $dir | su - $user -c 'tar xfP -'
or even for a file (if you don't care about permissions etc)
cat $file | su -c $user -c 'cat > $file'
Anyway, getting back to X, you can fix the /tmp/.X11-unix problem by
creating a new directory for the socket, and creating symlinks in the
/tmp directories of users that want it, called .X11-unix, and
pointing to this directory. If you are running xdm or gdm or the
like, a good place to do this is the GiveConsole (a.k.a. gdm's
PreSession/Default) script. You can also get away with making this
.X11-unix directory mode 700 and chowning it to the user that is
logging in, in the same manner as /dev/console is chowned. The
.font-unix stuff can be fixed by using localhost:7100 as a font path
instead of unix:-1. Using this doesn't seem to lead to any
noticeable performance hit.
For a detailed description of how I got X going, look at
http://www.datadeliverance.com/docs/symlink-X11.html
Cheers
-Matthew
--
+--------------------------------------------------------------------------+
| Matthew Donaldson http://www.datadeliverance.com |
| Data Deliverance Pty. Ltd. Email: matthew@datadeliverance.com |
| 30 Musgrave Ave. Phone: +61 8 8265 7976 _ |
| Banksia Park Fax: +61 8 8265 0032 John / \/ |
| South Australia 5091 3:16 \_/\ |
+--------------------------------------------------------------------------+
(6414609) /Donaldson, Matthew <matthew@DATADELIVERANCE.COM>/(Ombruten)