From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev+bounces-67965-garchives=archives.gentoo.org@lists.gentoo.org> Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 65F0B13838B for <garchives@archives.gentoo.org>; Tue, 30 Sep 2014 14:52:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 05693E0B75; Tue, 30 Sep 2014 14:52:06 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 08483E0B54 for <gentoo-dev@lists.gentoo.org>; Tue, 30 Sep 2014 14:52:04 +0000 (UTC) Received: from [192.168.1.5] (ip70-181-96-121.oc.oc.cox.net [70.181.96.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 4671F33BF4D for <gentoo-dev@lists.gentoo.org>; Tue, 30 Sep 2014 14:52:04 +0000 (UTC) Message-ID: <542AC392.6010009@gentoo.org> Date: Tue, 30 Sep 2014 07:52:02 -0700 From: Zac Medico <zmedico@gentoo.org> User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Re: Re: Looking for alternative to RESTRICT=userpriv References: <20140708152526.11d11e8b@pomiot.lan> <21435.64862.617761.35100@a1i15.kph.uni-mainz.de> <20140709161718.23beb044@pomiot.lan> <54239F53.50100@gentoo.org> <20140929042329.GB3867@rathaus.eclipse.co.uk> <5429A12B.9000204@gentoo.org> <20140929233118.GA3112@rathaus.eclipse.co.uk> In-Reply-To: <20140929233118.GA3112@rathaus.eclipse.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: dd5e36b2-24bf-4c4b-88f8-4301d20dd989 X-Archives-Hash: b9467d221d66d12803f4072ff10b76b1 On 09/29/2014 04:31 PM, Steven J. Long wrote: > On Mon, Sep 29, 2014, Zac Medico wrote: >> On 09/28/2014, Steven J. Long wrote: >>> On Wed, Sep 24, 2014, Zac Medico wrote: >>>> The environment doesn't necessarily have to be isolated, since we could >>>> extend the existing environment saving/loading support to be used for by >>>> esudo. The steps to implement the shared environment could be as follows: >>>> >>>> 1) When esudo is called, it saves the current (unprivileged) bash >>>> environment to a file. >>>> >>>> 2) esudo uses IPC to request that a process with elevated privileges be >>>> launched to run a specific command using the saved environment, and that >>>> the environment of the elevated process be saved to a file after the >>>> command completes. >>> >>> I don't think it's going to be quite that easy to get the output env, >>> certainly not from some random command; tbh I don't even see the need >>> for it, unless I'm missing something. From the "elevated process" after >>> it waits on the child, but not from the child unless you control the >>> code. >> >> We control the shell code that launches the requested command, so we can >> save the environment after the requested command completes (using a >> modified version of our existing environment persistence code). > > Yeah but think it through; the "elevated process" inherits its environment > from us (current state, as normal). It runs a child process: nothing in the > env of that child is going to affect our env, by definition. The command > completes, and we save back the same env we started with. > > Sure, the child inherits its env from us, but we don't need to do anything > to make that happen: it's standard. In fact we take efforts to clean the > env in some situations for that reason. > > I just can't see it working, apart from perhaps where a command outputs > settings which should be run through eval. In which case, eval them > in ebuild space after the command has output whatever under esudo. To > be flexible, you're going to want to save them anyway for later use, > which again implies that happening in the ebuild/eclass. You're thinking in terms of a SUID helper like sudo. The implementation that I've been suggesting does not involve a SUID helper. Instead, IPC would be used to request that the privileged parent process launch a new privileged process on behalf of esudo. In this context, unless the esudo implementation provides explicit support for environment inheritance, the new privileged process will not inherit any environment from the environment where esudo was called. >>> Other than that, I agree esudo is the best approach, and gives us >>> much better granularity over privilege escalation, as discussed in >>> the bug. >> >> Yeah, me too. > > Cool, glad we're on same page. > >>> Part of me thinks though, that it'd be much cleaner to give the >>> portage user access to sudo. Isn't that effectively the purpose >>> of the "suid helper"? In which case we get all the options for >>> env etc, of sudo, and the admin gets to configure it along with >>> the normal wheel setup. >> >> Depending on our goals, using sudo may or may not have advantages. It. >> really depends on whether or not we want esudo to interact with the >> local sudo configuration. If we want it to be independent of the local >> sudo configuration, then it makes sense for the package manager to use >> it's own privilege escalation mechanism. > > IDK; "independent of the local sudo configuration" /sounds/ good, but > what we are talking about is the configuration for *one* user, that to > run the package manager at the heart of our distro. Speaking as a uadmin > (a Gentoo user who's a defacto admin, not what I think of as an "admin", > which would be a net-admin) I'd much rather configure that in the same > place I configure everything else. > > It's not like I don't see the portage user in /etc/passwd et al, or it's > little-known. We set perms for it on /var/tmp/portage so that userpriv > can work, at least we did last time I set that up. /usr/portage is > set like that too, here. So we already have to deal with the user part > of userpriv, as admins. > > On the implementation side, it makes a lot of sense: we delegate the > worry to a package used cross-distro for this specific purpose. In fact > this conversation has made me understand ubuntu a bit more, where I > always used to smile at the overuse of sudo. I certainly wouldn't > want the implementation headache of maintaining a secure clone. The IPC implementation that I've suggested does not involve an SUID helper, so it is much more secure. Security would rely on the permission bits of the named pipes that are used to implement IPC. > AFAICT functional wrapping can be used for the capability side, but > I'd be interested to read otherwise, ie the ins and outs of why not. > > Regards, > igli > -- Thanks, Zac