From mboxrd@z Thu Jan 1 00:00:00 1970 From: sbaugh@catern.com Subject: Re: Providing an alternative to setuid in GuixSD Date: Wed, 26 Oct 2016 10:40:49 -0400 Message-ID: <877f8vfa1a.fsf@catern.com> References: <87funnhz7h.fsf@catern.com> <878ttbti19.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56103) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzPOt-0004dx-EQ for guix-devel@gnu.org; Wed, 26 Oct 2016 10:41:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzPOp-00013N-HH for guix-devel@gnu.org; Wed, 26 Oct 2016 10:41:55 -0400 Received: from [195.159.176.226] (port=34294 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bzPOp-00013B-AH for guix-devel@gnu.org; Wed, 26 Oct 2016 10:41:51 -0400 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bzPOD-0007FE-En for guix-devel@gnu.org; Wed, 26 Oct 2016 16:41:13 +0200 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: guix-devel@gnu.org ludo@gnu.org (Ludovic Courtès) writes: > Well, the kernel Linux will forever support setuid binaries That can be selectively turned off per-mount, simply specify the nosuid option. And so eventually we can get to a point where setuid is a Linux build configuration option, which distros can turn off. > and thus, most likely, chroot(2) will forever be restricted to root. This too can be a configuration option. And it's entirely possible for distros to turn it on after setuid is turned off. These decisions about setuid and chroot are distribution decisions; distributions can and should make decisions and innovate independent of the Linux kernel's default configuration. (That's part of how the whole GNU/Linux ecosystem works) On another point, even if chroot is forever privileged, new syscalls can be developed which duplicate the functionality of chroot with more flexibility and less baggage. But they will certainly face the same issue as chroot if they wish to be made unprivileged. Mount namespaces, for example, (with a bit of tweaking of the API to make it actually useful unprivileged) could be made unprivileged without relying on user namespaces, but face the same problems as chroot. So by removing setuid we are laying the groundwork for innovation not just by allowing unprivileged chroot. >> I think also the ability to build a setuid-free system could make GuixSD >> a useful platform for innovation in the use of filesystem namespaces. (I >> myself certainly have plans in this area.) > > Our ‘linux-libre’ package has support for user namespaces and other > namespaces built in already (this is the default kernel config I think), > so one can already play with namespaces on GuixSD and on other distros > that enable it. :-) I mean new kernel features - I'm skeptical that user namespaces provide an intuitive or easy to use API, and I have some ideas on what would be better. But the features I want to develop rely on getting rid of setuid, so I'm starting there. :) >> The largest targets for elimination are sudo and su. Luckily there is >> already a ready alternative for those commands: ssh. We can augment lsh > > SSH is a complex protocol and its implementations are complex too. I > would find it unreasonable to replace ‘su’ and ‘sudo’ with something > this complex, that goes through the TCP/IP stack, etc. Yes, that is true. The sole virtue of ssh here is that it already exists and is used for this purpose. What if we adapted s6-sudod, or wrote something from scratch? Or perhaps patched sudo to work in some way over IPC? I think a generic solution is useful. Maybe something should be written specifically for GuixSD, configured with Guile? Or maybe something which makes use of the putative standard, PolicyKit, which is configured with Javascript?