[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110822170206.GA16412@openwall.com>
Date: Mon, 22 Aug 2011 21:02:06 +0400
From: Solar Designer <solar@...nwall.com>
To: musl@...ts.openwall.com
Subject: env vars in SUID/SGID programs (was: LD_PRELOAD and RTLD_NEXT support)
Rich, Vasiliy -
On Tue, Aug 16, 2011 at 04:46:00PM +0400, Vasiliy Kulikov wrote:
> ...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 = ...
I just took a look at recent musl, and I don't see any safety from env
vars used elsewhere in musl.
If a SUID/SGID program uses execvp(3), what do we want to happen?
Also, for env vars that musl ignores because of SUID/SGID'ness of the
current program, shouldn't it also unset them? This is what we're doing
in glibc on Owl, because of sudo-like programs (where another program is
invoked next - still privileged, but no longer detected as such by libc).
I think these potential precautions I am talking about above should
apply for both static and dynamic binaries. That is, they should be in
musl's program startup code that is used in both cases.
What do you think?
Alexander
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.
