From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Providing an alternative to setuid in GuixSD Date: Fri, 28 Oct 2016 15:34:51 +0200 Message-ID: <87inscbnr8.fsf@gnu.org> References: <87funnhz7h.fsf@catern.com> <878ttbti19.fsf@gnu.org> <877f8vfa1a.fsf@catern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c07JB-0004xr-DX for guix-devel@gnu.org; Fri, 28 Oct 2016 09:35:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c07J8-0003LI-9m for guix-devel@gnu.org; Fri, 28 Oct 2016 09:34:57 -0400 In-Reply-To: <877f8vfa1a.fsf@catern.com> (sbaugh@catern.com's message of "Wed, 26 Oct 2016 10:40:49 -0400") 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: sbaugh@catern.com Cc: guix-devel@gnu.org Hi! sbaugh@catern.com skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) 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. Right. >> 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. Yes, I agree with this. I think we must just be clear that GuixSD will be the only one to benefit from a solution along the lines you wrote, at least for the foreseeable future. It seems to me that your proposal could be summarized as (1) replacing sudo with a sudo-that-uses-IPCs (fine), and (2) replacing other setuid programs by a wrapper that does =E2=80=9Csudo program=E2=80=9D. Item #2 is already possible, but it doesn=E2=80=99t look =E2=80=9Cbetter=E2= =80=9D to me that setuid programs from a security or configuration viewpoint. Note that GuixSD is different from other distros regarding setuid binaries: they exist only in /run/setuid-programs, which is recreated at boot time (unless of course root messes up with the system). >>> 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 =E2=80=98linux-libre=E2=80=99 package has support for user namespace= s 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. :) What features do you have in mind? Namespaces look like an improvement to me. If you want something less hacky, there=E2=80=99s always the Hurd. ;-) >>> 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 =E2=80=98su=E2=80=99 and =E2=80=98= sudo=E2=80=99 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? Polkit has its own sudo-like program, =E2=80=98pkexec=E2=80=99, that works = by talking to the polkit daemon over D-Bus. Ludo=E2=80=99.