From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/448 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: env vars in SUID/SGID programs (was: LD_PRELOAD and RTLD_NEXT support) Date: Mon, 22 Aug 2011 14:13:34 -0400 Message-ID: <20110822181334.GA132@brightrain.aerifal.cx> References: <20110816051715.GN132@brightrain.aerifal.cx> <20110816063410.GA4254@albatros> <20110816114730.GO132@brightrain.aerifal.cx> <20110816124600.GA15681@albatros> <20110822170206.GA16412@openwall.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1314036926 11474 80.91.229.12 (22 Aug 2011 18:15:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 22 Aug 2011 18:15:26 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-449-gllmg-musl=m.gmane.org@lists.openwall.com Mon Aug 22 20:15:23 2011 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1QvZ1u-000111-2c for gllmg-musl@lo.gmane.org; Mon, 22 Aug 2011 20:15:22 +0200 Original-Received: (qmail 1588 invoked by uid 550); 22 Aug 2011 18:15:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1446 invoked from network); 22 Aug 2011 18:15:18 -0000 Content-Disposition: inline In-Reply-To: <20110822170206.GA16412@openwall.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:448 Archived-At: On Mon, Aug 22, 2011 at 09:02:06PM +0400, Solar Designer wrote: > 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. The startup code (__libc_start_main) is the right place for this check, and to merge nik'a vdso support for static-linked programs we need auxv parsing here anyway, so it's minimal added cost. I just haven't done it yet, partly for some silly micro-opt reasons that are hard to explain -- basically there's some mildly ugly code I should remove at the same time because there will no longer be any cases where it could actually help, and I want to make sure that's cleaned up right. As for what specifically should be done, that's less clear to me. Surely any use of environment vars (TMP?) in musl itself should be conditional on !suid, but I don't see any allowance in the specification for environment variables to "disappear" when an suid/sgid program is exec'd. While unsetting them may help work around some buggy suid programs that exec other programs without sanitizing the environment, (1) it can't help with vars that libc doesn't know about, and (2) it prevents legitimate, correct suid programs from analyzing the environment and copying through or otherwise using some security-related variables they might want to be able to see. Especially for the normal suid behavior (just dropping privs and running as the real uid after performing a single privileged operation) it's desirable for the real user's environment (e.g. tmp file location) to have effect. Ultimately, suid programs that intend to invoke other programs which aren't aware of having elevated privileges MUST perform the equivalent of clearenv()/environ=0;, possibly after backing up the environment if they need to examine it themselves... Anything else is dangerous, whatever libc does. Rich