At 20 Mar 2005 20:15:03 -0800, Thomas Bushnell BSG wrote: > > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > > Following untrusted translators in the filesystem is a real security > > hazard. > > Can you say more about a specific losing scenario? I did my level > best to make sure that following translators doesn't give away any > privs. What's the problem?
It's not about giving away privileges, it is about tricking the user into doing something he doesn't want. Here is one particularly nasty example. User: $ settrans /home/user/tmp/foobar/.../screw\'em /hurd/firmlink /root $ [create some really big useless files in /home/user/tmp/foobar] $ [go on vacation] Administrator: # [mmmh, why is there so little disk space...] # rm -fR /home/user/tmp/foobar/ # [don't notice anything for a while...] # ARGH! Or just create some really deep (infinite) virtual directories and let the find operation of the location database go run mad on it in a cron job. Now, we have our own temp reaper. And a tmp reaper would be trivial if you would hack rm to have a "--do-not-follow-translator" option. But I believe that is not good enough. The reason is that 1) It is unfeasible to change all programs that traverse filesystems, or just follow untrusted paths. It may not even be possible to easily find out which programs do that. You would have to audit each and every package, and modify it either to be safe by default or to allow safeness options to be set via the environment or command line options. A huge task, given the number of software out there. 2) Even if you were to undertake it, it would _still_ be wrong. Programs should be secure by default, not insecure by default. This is especially true because: 3) This is the POSIX personality of the Hurd, and people will have certain expectations about how to be secure. It's already difficult enough to make people security-aware. Complicate the attack scenarios, and you will quickly lose people's attention. Unix security is already difficult enough without the Hurd's extensions. But then there is: 4) There is just a huge amount of literature that says how POSIX like system work, starting with something like Richard Stevens, and ending with web-tutorials, training programs, etc. This literature describes what you can expect and what you don't need to expect, but it is usually not Hurd-aware (and realistically, that's not going to change. Even if the Hurd were an instant success it would take decades to replace all books in all libraries etc). Millions of people are teached according to this literature, and if they'd start to use the Hurd they wouldn't know what had hit them. Everything would look like they know it, but what we see as useful extensions would appear to them _first_ as horrible invisible pit falls. In other words: The "insecure by default" is like setting a trap. It just begs for someone to forget about our extensions and do a wrong command that would be perfectly fine on Unix, but wrecks havoc with your files or other things on the Hurd. I have posted a suggestion to fix this a long time ago, but can't find the mail right now (maybe I never sent it?). The solution would be to always open nodes with O_NOTRANS, and if the translator bit is set, there is a user ID check. If the user ID belongs to a trusted set, which by default is "0-XXX,myself" where 0-XXX is the range of system user IDs (this would be 0-999 on my system, I think), then the translator is followed. Otherwise it is not followed, unless the user explicitely specifies a new flag O_TRANS. The set of trusted user IDs could be set via an environment variable, which would work very much like LD_LIBRARY_PATH. This variable would be cleared for suid programs. Thanks, Marcus _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
