On Mon, 20 Nov 2000, Wolfgang Solfrank wrote:

> Hmm, so to get things straight:
> 
> You want to introduce a new feature (HOSTALIAS.  And before you ask,
> I don't care how long this has been available previously; it isn't
> available for setuid programs currently.) into some library routine.

You've entered this discussion in entirely the wrong tone. Your tone comes
across very much as, "this is what I see, and don't try to tell me
different."

> This new feature introduces a security concern.  So you think the

Many of us do not consider this a new feature. This change (to just
disable HOSTAILASES iff issetugid()) was made last April, so 1.5 (which is
not yet out the door) will be the first release with this change. Thus it
strikes me (and others, from the discussions we've had) that we are now
actually loosing something. I/We think that a security fix which results
in loosing functionality when there are other (secure) ways of fixing it
is broken. :-)

> correct solution to this problem is to tweak the OS in some obscure
> way in order to make this new feature safe even for some old users
> of this library routine, since they might call the library routine
> in a way that makes its now introduced security risk explotiable.
> 
> This seems quite backwards to me.

Of course. You've painted the situation in such a manner that the only
"reasonable" conclusion matches yours. :-)

> IMHO the correct solution is to document the routines as requiring
> a specific ID level, and by default switch off the new feature for
> setuid programs.  If you really think that the new feature is worthwhile
> (and it seems you do), then allow for new code to enable it via some
> flag argument or some external flag settable by a caller of the routine
> (either directly or through some other library routine) which tells
> the routine that you know what you are doing.
> 
> Wouldn't that work better?

I don't think so. I think it would be a lot more work. First off, we want
old code to be safe too - tcpdump and ping for example. Second off, it is
a solution which does not scale. It means modifying many programs, each to
make sure that privilege levels are correct. The idea with the O_REG_ONLY
change and the open-twice dance is to make one change (in two parts) to
make all of the callers safe.

Also, everyone is focusing quite strongly on HOSTALIASES. But it is NOT
the only thing which needs the ability for a library to open a file passed
in by an untrusted source. Pretty much EVERY library routine which opens
files whose names can come in via environment varialbes needs this
protection.

So we have a problem where lots of routines called by many programs need
to be able to to open a file without worrying that the program/library
routine has just been tricked into doing something at higher privilege.

We can either change a lot of programs, or we can make a simple kernel
change and add a new library routine which does the right magic dance. I
think the latter will represent a lot less work and fix a number of
security holes all at once.

Take care,

Bill