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: matthewat_private | | 30 Musgrave Ave. Phone: +61 8 8265 7976 _ | | Banksia Park Fax: +61 8 8265 0032 John / \/ | | South Australia 5091 3:16 \_/\ | +--------------------------------------------------------------------------+
This archive was generated by hypermail 2b30 : Mon Apr 23 2001 - 14:21:18 PDT