[1075] in linux-security and linux-alert archive
Re: [linux-security] Re: RESOLV_HOST_CONF
daemon@ATHENA.MIT.EDU (Daniel Bromberg)
Mon Aug 26 07:24:46 1996
To: Joshua Cowan <jcowan@jcowan.reslife.okstate.edu>
cc: linux-security@tarsier.cv.nrao.edu
In-reply-to: Your message of Sun, 25 Aug 1996 14:32:03 -0500.
<199608251932.OAA12207@jcowan.reslife.okstate.edu>
Date: Sun, 25 Aug 1996 17:46:05 PDT
From: Daniel Bromberg <ddaniel@furlong.jpl.nasa.gov>
> REW> I'd suggest either dropping priviliges before opening the file
> REW> or simply refusing to use the environment variables when euid
> REW> != uid (like the LD_LIBRARY_xx family).
>
> I've done this. The patch to ld.so 1.8.2 is included below; of course,
> it won't help if your `ping', `traceroute', `rsh', etc., are statically
> linked....
On and on we go with little hacks to plug all these holes...It seems
to be a step needs to be taken back so we can look at a fundamental
problem with *all* setuid programs: they blithely take lots of
environment variables from the user's environment and just use
them. But let's consider what setuid progams are really for: as a
proxy for the system admin so users can perform certain tasks without
having a privileged human sitting with them all the time. Thus we're
on *root's* turf now. As a favor for the user. Thus we should have
root's environment, or at least a highly limited, controlled
environment.
I propose a blanket solution: have the kernel manipulate the
environment passed to the setuid program in a safe manner. Thus only
pass through a few, if any, env variables to any setuid program,
statically linked or not. (Off the top of my head, all I think one
needs is USER, HOME, possibly HOSTALIASES). Given the splitvt type of
attack, we'd also need to 'clean up' the ones we do pass through, by
removing non-printable content and limiting the length. There is more
configuration needed: so there could be some file like
/etc/default/root.env which contains the environment that the sysadmin
deems adequate for proper operation of all setuid programs. (like
PATH, HOSTNAME, etc.) Such a file could also specify which user's env
variables were safe to pass through.
I know generally that "blanket" solutions are bad: they tend to cover
up problems rather than addressing them, but it seems to me this is a
good size blanket that addresses the general environment problem at
the right place. Think of how many past, present, and future security
problems this would solve!
My point is: a user environment is totally untrustable, obviously. The
general environment variable attack should be stopped at the source.
I can't think of all the technical ramifications right now of my
solution, and I have a nasty feeling there's a bunchy of stickly
issues left, but I think it's worth looking into.
[REW: The kernel is not equipped to mess with environment variables.
The kernel can't really go about reading config files.
Originally "environment variables" was a userlevel hack. I don't think
that this is a good solution. It prohibits general solutions.
You are correct in the "service to the user". The setuid programs
should then take care not to trust the environment they run in too
much. The problems start coming when the library starts doing that.]
Mis dos centavos,
Daniel Bromberg, Co-op
ddaniel@mit.edu
M/S 171-300 (818) 393-3872
Jet Propulsion Laboratory
4800 Oak Grove Dr.
Pasadena, CA 91109
