On Mon, Apr 23, 2001 at 02:39:22PM +0930, matthewat_private 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.
This archive was generated by hypermail 2b30 : Mon Apr 23 2001 - 14:51:18 PDT