[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: untrusted translators
Re: untrusted translators
Mon, 21 Mar 2005 12:29:16 +0100
Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)
At 20 Mar 2005 20:15:03 -0800,
Thomas Bushnell BSG wrote:
> Marcus Brinkmann <address@hidden> 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
$ settrans /home/user/tmp/foobar/.../screw\'em /hurd/firmlink /root
$ [create some really big useless files in /home/user/tmp/foobar]
$ [go on vacation]
# [mmmh, why is there so little disk space...]
# rm -fR /home/user/tmp/foobar/
# [don't notice anything for a while...]
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
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
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.
Re: heads up, Alfred M. Szmidt, 2005/03/21