From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Craven Subject: Re: Add murmur. Date: Sun, 12 Feb 2017 15:37:14 +0100 Message-ID: References: <20170209182030.ngn2dsdfbzsmymdj@wasp> <87efz7asit.fsf@gnu.org> <20170210213959.on6psfta6jcbjv2b@wasp> <877f4x1zle.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> <20170210221536.iv5rktzx43b6xddv@wasp> <87wpcw3iks.fsf@gnu.org> <20170211143934.oo5loexp4pbpovpk@wasp> <87y3xbwmvi.fsf@gnu.org> <20170212135319.4exfnaq3oov3p6de@wasp> <20170212140234.xno3tzpzgvndirt3@wasp> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35932) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ccvHD-0003gS-2R for guix-devel@gnu.org; Sun, 12 Feb 2017 09:37:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ccvH9-0004KC-Vm for guix-devel@gnu.org; Sun, 12 Feb 2017 09:37:19 -0500 Received: from mail-qt0-x22d.google.com ([2607:f8b0:400d:c0d::22d]:33105) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ccvH9-0004K3-QG for guix-devel@gnu.org; Sun, 12 Feb 2017 09:37:15 -0500 Received: by mail-qt0-x22d.google.com with SMTP id v23so67317171qtb.0 for ; Sun, 12 Feb 2017 06:37:15 -0800 (PST) In-Reply-To: <20170212140234.xno3tzpzgvndirt3@wasp> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: David Craven , =?UTF-8?Q?Ludovic_Court=C3=A8s?= , Marius Bakke , guix-devel > You read too much between the lines in my words. > I'm not counting on the certifications of Harmut. I simply agree with > the reasoning that no client and server should be combined if possible > to limit the attack surface. That's all. That may be true. It was my intention to back Ludo. I think that it is a minor issue at best, since anything that isn't accessible over the network or running with any sort of privileges is not very useful. An attack usually involves exploiting a service for remote code execution, followed by privilege escalation and finally securing access to the system and cleaning up traces. This is an unprivileged binary on a server, and it isn't even running. Exploiting any bugs in the client would require starting the client first. This means that an attacker has already gained physical access or is able to perform remote code execution. This hypothetical attacker is trying to escalate privileges. I don't see how starting an unprivileged process would help with that. But then again - I'm not an expert and don't have any credentials - so I'd be interested to know if there is a way of exploiting this.