Re: untrusted translators

[Marcus Brinkmann]

At 20 Mar 2005 20:15:03 -0800,
Thomas Bushnell BSG wrote:
> 
> Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> 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