From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Providing an alternative to setuid in GuixSD Date: Sun, 23 Oct 2016 17:09:31 -0700 Message-ID: <878tteli9w.fsf@gmail.com> References: <87funnhz7h.fsf@catern.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54401) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bySpv-0004Z4-8G for guix-devel@gnu.org; Sun, 23 Oct 2016 20:09:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bySpq-00020n-Vx for guix-devel@gnu.org; Sun, 23 Oct 2016 20:09:55 -0400 Received: from mail-pf0-x22c.google.com ([2607:f8b0:400e:c00::22c]:34858) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bySpq-00020R-K2 for guix-devel@gnu.org; Sun, 23 Oct 2016 20:09:50 -0400 Received: by mail-pf0-x22c.google.com with SMTP id s8so87271344pfj.2 for ; Sun, 23 Oct 2016 17:09:50 -0700 (PDT) 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 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, I don't think I have all the answers, but this is an interesting topic, so I'll chime in with what I can. I'm sure others will have more thoughts to share, too. sbaugh@catern.com writes: > 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. When you say "filesystem namespacing functionality," are you referring to the Linux feature known as "user namespaces"? There is an article on LWN that discusses some of the security issues surrounding this: Filesystem mounts in user namespaces https://lwn.net/Articles/652468/ I admittedly don't know a lot about this feature, but it sounds like it is not currently designed to let a user escalate privilege in a way that would enable malicious modification of system files such as /etc/passwd. Can you clarify your second concern a little more to help me understand? You might already know, but there appears to be prior work on the general topic of eliminating setuid programs. For example, see the following paper, which surveys some of the programs and problems, and even proposes a solution they call "Protego": Practical Techniques to Obviate Setuid-to-Root Binaries https://www3.cs.stonybrook.edu/%7Eporter/pubs/jain-setuid.pdf > 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. It would be nice if the Guix daemon could create chroots for building packages even when it runs as a non-privileged user. That is definitely a limitation (see the comment about "--disable-chroot" in (guix) Build Environment Setup). However, I don't understand how eliminating setuid binaries would enable unprivileged access to root. Can you clarify why the latter follows from the former? > =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 > with the rich access controls of sudo, add any extra missing features, > and then replace sudo/su with wrappers around ssh. (A wrapper would be > needed just for sheer familiarity of the system to a user.) sshd runs > and performs access controls in a fixed environment, so this is not > vulnerable to the chroot attack I mentioned above. > > Once we have a solid replacement for sudo, we can take a generic > approach to eliminating other setuid binaries: just replace them with > wrappers which call 'sudo command "$@"', and make sure the > sudo-replacement is appropriately configured to allow running that > command without authentication. > > I believe we could do this with all binaries, though there may be some > issues I'm not yet aware of yet. > > In the longer term I'm not sure if we would want to individually > replace setuid binaries with IPC-performing commands. The only real > benefit is maybe elegance... That's an interesting idea. Some questions come to mind: * How would we allow one user to run a program as a different user? * How would we allow a user to update their own entries in shared databases like /etc/passwd? * Could this approach work with any kernel, not just Linux? * Because the daemon must have enough privileges to take any potential action that might be requested, does this solution fail to enforce the principle of least privilege in basically the same way that many setuid programs do (because they start with more privileges than they need)? * Do you know of any prior art in this area which is similar to what you are proposing? I saw some interesting-looking references in the Protego paper linked above, but I didn't go down the rabbit hole. For what it's worth, the Nix/NixOS people have not (to my knowledge) solved this problem, either. They didn't mention any setuid alternatives in any of the papers I checked here: http://nixos.org/docs/papers.html Best regards, =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYDVFJAAoJEN1AmhXYIkad9d8QALytejNdjYjY1anxbo0tZt8i Lg92UiIXr2wMMA5uefzyW36yN2WaNXF6W5XuZ7zRFyOAHWZUHE+dV+L2MhoywxP4 eiOlBLeHY0cxiL+xMZ/RsGhAUVziLHtgu7JY4AD2tLWZPaQjlUSHn7+LjI4KLmTc ITc34bAa/avlhW215BHN6exFaG3925r4e05YpD+hqQxWY5qBGglpFeAyCMWYRulZ Bj0dzVWgHNJXr8/2CR6IaBKCUqvPYanC2CD73T19oXWc5cDM8dLWgekonNBGX+Vr 8IDVl3uQFvVEvqawpNMbg8nZrVNddqwbnyjwPUBKr4aSDCWLjumc5KK8s2B8fxd3 JcVTIoaod4NTln1Piufz1u9ewhMn3t57kaACKD1H7lTHQ4D/CTRIhniD5/Mn7S0t 6JcwxEK+EN7qLhnG0XRGmNdsfjtkXxzgNcEfi1aYnhl6PUgOtsNUXgx9w06gJEiD ty0ubZE+5MUuFTRhhntN/plU2a36Om7j4xsHlsozeL/6SboXXBlgElCS1LWF6snw 9dJ/E7KQW4vccNawAps4ECxhNX1zJXjVmnslWNN2wxi3IsTRi0jzAWihr4tBAVuD hfA8PH5Pr5Oi8vZoxuu3d/Vk5tlc1SUH27LRimXgVizKEk5psxIQBypsZymrXm9K uhBvHE6bjIn5/8WdfYbp =xfAV -----END PGP SIGNATURE----- --=-=-=--