OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: [RFC] environment sanitisation wrapper
From: Sean Hunter (seanuncarved.com)
Date: Mon May 29 2000 - 14:42:00 CDT

On Mon, May 29, 2000 at 09:13:11PM +0200, Cooper wrote:
> Sean Hunter wrote:
> >
> > As such, I have found it useful to alias "sudo" to set up a known
> > path, then run the real "sudo" from my safe_env wrapper. You could
> > just use "env -", but some environment vars are worth keeping IMO.
>
> I don't think this approach will work because once someone figures out
> which sudo is actually run you're still in for a rough ride. This
> approach looks to me like a plain security through obscurity thing which
> as many people know simply doesn't work in the end.

I think you're misunderstanding my intentions entirely. You probably
need to know a little more about aliases too. You can always see what
aliases are set in your shell by typing "alias". You can always avoid
an alias by preceding the command with a backslash. Anyone who has
"sudo" access on my box would know this. Thus there is no obscurity
at all here.

>
> Now from what little I know of SuDo I understand that you use it to
> allow users to run programs with root privilleges. What I would suggest
> is that you let sudo run the requested programs via the wrapper instead
> of the sudo binary itself. By doing that you can even tailor the
> environment to the specific service you intend to start...
>
> When replying, please keep in mind that I'm not familiar with SuDo...

The point of my change is not to prevent exploits in sudo. Its not
security through obscurity at all.

The problem is that trusted users (ie ones allowed to use sudo) may
have environment vars in their normal login environment that you don't
really want in the environment of programs running as root. "sudo"
allows them to run something as root, but they probably don't realise
that the program they are running as root is running with their
insecure env vars in its environment. Black hat can now more easily
attack the root binary started by the trusted user because it is
running with their env vars.

For example, I am an active developer, and so am using some
debugging/profiling libraries and glibc's malloc debugging options. I
am also on support. I get a call saying that apache has tanked, so I
restart it using "sudo /etc/rc.d/init.d/httpd start", or some such.
The webserver is now running with my LD_PRELOAD and my malloc
debugging env vars, but with root permissions. Nice.

Thus a trusted user may unwittingly compromise the security of
programs they run using sudo. That's not a very pretty picture.

My alias gets around this by seemlessly setting up a sane environment
for the binary to be run as root. This means that it automagically
helps my trusted users to run things safely using "sudo". Sure its
just an alias. My trusted users could easily disable it and
deliberately run binaries in a compromised fashion. But that would be
deliberately dumb. I don't have that problem here (my trusted users
aren't deliberately dumb), otherwise I would have to patch sudo or not
trust that user.

Sean