[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: untrusted translators

From: Marcus Brinkmann
Subject: Re: untrusted translators
Date: Mon, 21 Mar 2005 20:26:29 +0100
User-agent: 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 21 Mar 2005 06:39:31 -0800,
Thomas Bushnell BSG wrote:
> > 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.
> Yes, that works; having it done through an environment variable makes
> it fairly easy for users to overcome it when they want.  

One could always have a special value like "@all" mean that all uids
are acceptable.  This would be what the current default is.
> I'm not sure this is the right fix, but it looks like it would work
> well.

Independent of any argument about what a reasonable default is, I
think that being able to configure which translators to follow based
on the user id of the underlying node is a pretty basic security
feature that's quite desirable.  And an environment variable that is
understood by the glibc core seems to be the appropriate mechanism for

I don't fancy the fact that my suggested default includes a "system
range" of user IDs.  One idea is to have the default (without any
environment variable set) to be "@all"[1], and then just make sure that
distributions ship with an appropriate default environment set up (ie,
Debian would set it to 0-999,@myself) in /etc/profile or whatever.
You would still have to ensure that programs running early at boot
time would also see such an environment.  For suid exec's, they could
inherit this variable from their parent filesystem, which will provide
them with what they consider to be a secure default (usually its own).

This seems to be slightly more flexible than what I proposed in my
last mail.  For example, if you set up an active filesystem, it will
inherit your "friend list", and pass it on to suid binaries started
from that filesystem.  Sounds fine to me.


[1] Such a solution would have the problem that if you mess up your
configuration, ie something wents wrong with setting up the
environment, you get an insecure default.  So, if you are paranoid,
like me, you would want to default to "root=0,@myself", and nothing
else, instead of "@all".  The important part of the proposal is that
it does rely on the distribution and system administrator to figure
out the range of system UIDs.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]