Re: LD_PRELOAD and RTLD_NEXT support

[Rich Felker <dalias@aerifal.cx>]

On Tue, Aug 16, 2011 at 04:46:00PM +0400, Vasiliy Kulikov wrote:
> On Tue, Aug 16, 2011 at 07:47 -0400, Rich Felker wrote:
> > > 1) This check should be extended to support AT_SECURE (dumpable flag,
> > > any LSM security domains, capabilities).
> > 
> > Indeed, I'll add this. Do I just check for aux[AT_SECURE] != 0?
> 
> Looks like so.
> 
> glibc has some crazy dance with these flags and get*id() values, which
> we patch in Owl ;-)

Well glibc tries to be clever and let you use LD_PRELOAD with suid as
long as the library is in a "trusted" path and has the sgid bit set.
To me this seems really misguided; the valid use cases are very few,
and it seems impossible to predict all the future kernel
"enhancements" that might create gaping holes in whatever method you
use to validate... In my opinion, the only safe thing to do when
running with elevated privileges is to completely ignore anything the
user controls in the initial environment.

> ....btw, I feel it would be cleaner if you check for untrusted environment
> at the time of initializing env_* variables.  Currently there is not
> much code between env_X assignment and zeroing, but it might be in the
> future (with addition of ld features, etc.).
> 
>     for (p = argv+i; ... ) {
>         if (is_secure_env)
>             env_path = ...

Notice the problem is that this code is in the loop that's responsible
for *finding* auxv. For now I've just moved the code closer together,
but if you think it would help, I might first load the env vars into
temp variables and switch the conditionals for secure mode, so that
env_* would never get loaded in the suid/sgid/caps case.

Rich