From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/445 Path: news.gmane.org!not-for-mail From: Solar Designer Newsgroups: gmane.linux.lib.musl.general Subject: env vars in SUID/SGID programs (was: LD_PRELOAD and RTLD_NEXT support) Date: Mon, 22 Aug 2011 21:02:06 +0400 Message-ID: <20110822170206.GA16412@openwall.com> References: <20110816051715.GN132@brightrain.aerifal.cx> <20110816063410.GA4254@albatros> <20110816114730.GO132@brightrain.aerifal.cx> <20110816124600.GA15681@albatros> 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 1314032533 13671 80.91.229.12 (22 Aug 2011 17:02:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 22 Aug 2011 17:02:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-446-gllmg-musl=m.gmane.org@lists.openwall.com Mon Aug 22 19:02:10 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 1QvXt3-0003ho-P4 for gllmg-musl@lo.gmane.org; Mon, 22 Aug 2011 19:02:09 +0200 Original-Received: (qmail 18344 invoked by uid 550); 22 Aug 2011 17:02:09 -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 18336 invoked from network); 22 Aug 2011 17:02:08 -0000 Content-Disposition: inline In-Reply-To: <20110816124600.GA15681@albatros> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:445 Archived-At: 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