From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 71FE813838B for ; Fri, 3 Oct 2014 03:01:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 179FBE08D5; Fri, 3 Oct 2014 03:01:25 +0000 (UTC) Received: from foo.stuge.se (foo.stuge.se [212.116.89.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id DB1B4E084B for ; Fri, 3 Oct 2014 03:01:23 +0000 (UTC) Received: (qmail 18351 invoked by uid 501); 3 Oct 2014 03:01:20 -0000 Message-ID: <20141003030120.18350.qmail@stuge.se> Date: Fri, 3 Oct 2014 05:01:20 +0200 From: Peter Stuge To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Looking for alternative to RESTRICT=userpriv Mail-Followup-To: gentoo-dev@lists.gentoo.org 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> <542AC392.6010009@gentoo.org> <20141003023237.GA1575@rathaus.eclipse.co.uk> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141003023237.GA1575@rathaus.eclipse.co.uk> X-Archives-Salt: 4b49a3f1-ab94-456b-87ac-2b7ce142eb0c X-Archives-Hash: d23b900f035a3fcf3027de5a209de59e Steven J. Long wrote: > On Tue, Sep 30, 2014 at 07:52:02AM -0700, Zac Medico wrote: > > 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. .. > I don't see how that's "more secure" It's a lot more secure to have a single well-defined privileged trust anchor (the privileged process) with a well-defined protocol, than to have built-in privilege escalation which allows arbitrary actions. > Not sure what a daemon buys you Not requiring built-in privilege escalation. //Peter