[20392] in bugtraq
Re: Linux patches to solve /tmp race problem
daemon@ATHENA.MIT.EDU (Christoph Hellwig)
Mon Apr 23 17:49:51 2001
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <20010423120228.A8943@caldera.de>
Date: Mon, 23 Apr 2001 12:02:28 +0200
Reply-To: Christoph Hellwig <hch@CALDERA.DE>
From: Christoph Hellwig <hch@CALDERA.DE>
X-To: matthew@datadeliverance.com
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <15075.47362.362351.404030@localhost.localdomain>; from
matthew@datadeliverance.com on Mon, Apr 23,
2001 at 02:39:22PM +0930
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.
