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: Wed, 26 Oct 2016 14:24:18 +0200 Message-ID: <878ttbti19.fsf@gnu.org> References: <87funnhz7h.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]:50546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzNFo-0006yC-9i for guix-devel@gnu.org; Wed, 26 Oct 2016 08:24:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzNFl-0004a5-73 for guix-devel@gnu.org; Wed, 26 Oct 2016 08:24:24 -0400 In-Reply-To: <87funnhz7h.fsf@catern.com> (sbaugh@catern.com's message of "Sun, 23 Oct 2016 11:17:22 -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 Hello! sbaugh@catern.com skribis: > =3D=3D Why remove setuid binaries? =3D=3D > > setuid binaries are problematic for two reasons: > > 1. Each binary is an attack surface which is frequently exploited by > attackers for local privilege escalation. So getting rid of them > would improve security. > > 2. setuid binaries make access control decisions in an environment > controlled by the user running them, by looking at files at absolute > paths in that environment, such as /etc/passwd. Thus, if unprivileged > users had access to chroot or other filesystem namespacing > functionality, those users could escalate privileges by manipulating > /etc/passwd, /etc/shadow, /etc/sudoers, and then running a setuid > binary. So unprivileged chroot is not possible. > > Issue 2 is a matter near and dear to our hearts here in guix-land, and > is my primary motivation. My understanding is that if we eliminated > all setuid binaries, we could with some confidence begin to allow > unprivileged access to chroot/filesystem namespaces, without first > going through user namespaces (which have their own issues). Please > correct me if you believe this is wrong. > > Unprivileged access to chroot would of course greatly aid unprivileged > installation of guix. Well, the kernel Linux will forever support setuid binaries and thus, most likely, chroot(2) will forever be restricted to root. So I think removing setuid binaries on GuixSD is helpful for GuixSD itself, but not for other distros (at least not directly so). > 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 namespaces a= nd 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. :-) > =3D=3D How to do it =3D=3D > > Most (all?) setuid binaries can be replaced with a non-setuid binary > which performs local IPC to a privileged daemon. > > 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=98sud= o=E2=80=99 with something this complex, that goes through the TCP/IP stack, etc. > Does this plan makes sense in the context of GuixSD? Am I leaving out > anything? I don=E2=80=99t know, I=E2=80=99m skeptical! :-) However, I agree that GuixSD has more latitude as to how it deals with privileges, notably because the set of users, setuid binaries, and other relevant bits is all described in =E2=80=98operating-system=E2=80=99. Ludo=E2=80=99.