From mboxrd@z Thu Jan 1 00:00:00 1970 From: sbaugh@catern.com Subject: Providing an alternative to setuid in GuixSD Date: Sun, 23 Oct 2016 11:17:22 -0400 Message-ID: <87funnhz7h.fsf@catern.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byKWr-0006V2-RS for guix-devel@gnu.org; Sun, 23 Oct 2016 11:17:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byKWo-0005r3-Mv for guix-devel@gnu.org; Sun, 23 Oct 2016 11:17:41 -0400 Received: from [195.159.176.226] (port=53619 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1byKWo-0005qx-Fb for guix-devel@gnu.org; Sun, 23 Oct 2016 11:17:38 -0400 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1byKWg-0002Cz-Th for guix-devel@gnu.org; Sun, 23 Oct 2016 17:17:30 +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 Hi guix-devel, Has any effort been put into eliminating the need for setuid binaries from GuixSD? I would be interested in working on that. == Why remove setuid binaries? == 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. So I think it only right that we should take the necessary steps to support it in GuixSD. Then maybe (in a decade or so...) it'll be picked up by Debian and other large distributions. 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.) == How to do it == 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... Does this plan makes sense in the context of GuixSD? Am I leaving out anything? Thanks!