On Mon, Apr 23, 2001 at 02:39:22PM +0930, matthewdatadeliverance.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.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]