|
Message-ID: <20110816125917.GP132@brightrain.aerifal.cx> Date: Tue, 16 Aug 2011 08:59:17 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: LD_PRELOAD and RTLD_NEXT support 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.