From owner-freebsd-hackers@freebsd.org Wed Mar 14 08:23:07 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44870F2F0F3 for ; Wed, 14 Mar 2018 08:23:07 +0000 (UTC) (envelope-from mber2015@gmail.com) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ADD83746AD for ; Wed, 14 Mar 2018 08:23:06 +0000 (UTC) (envelope-from mber2015@gmail.com) Received: by mail-wr0-x230.google.com with SMTP id o1so3749811wro.10 for ; Wed, 14 Mar 2018 01:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=UzubT5Q2OHkp/kxl6km9InzyuSRxnFE3XdaP8XY1yyg=; b=D1tv4gtq/TaYgumvGxc0xyWQr0bV2xYrqEvRQakAZG/D613LYNNgeUIUMLCmz2rzzP k96DzL+scaZylMN/F/dqnwZogNWvA1becg/JYuZIPJP6dnOXlLza0GogI6iP0Li4wHcp rinU6eNVaJrL5FKfV694uUXal0zGWLituolPI6jhI5mzeX8VbZzvtQlKbH2NKm5J2ZRX oWvQ9V2Z3Z12VNLStecAWNJzYhb25z8O59a+dn+tsrniw2TTT4dNS1Ftthm4e/lUsoiD 4W5gLGTPlJQtTkgZRiSACIKFbuAHSgjofJVm1tndgTvgfbgkw/5WXHkQHeQNAZHTs4TR aCqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UzubT5Q2OHkp/kxl6km9InzyuSRxnFE3XdaP8XY1yyg=; b=ueEPyavhD9G/mxPEex5R/CXvjj3JkNwf8g+WAhr0Dm/QxUBbVWbmiHEk2zNnBpMCmi 3wC5Rb0R+7uBh7xALNgZe1OLGMf5lJZOWQ6LQl9NiWHKOLSCBdcUEAMFrZqFzf0dw7qW cZ9+rv+8lA2cUscwZ4KxFtoZM6GKJPO1v8jUMknkAOGsxzKKxCjy4wW/OrpEVtNooQCC MZ7ftznE+8LN+fzKDl297OKYRalLz+cpTUb3BB+kbN7oCCfYV2xUolEW+jO/q33xiXON /ZLjUPL5r27FIjXuSGh9pRD2l3iFCX7xKkGJ4d/IKNkoSoGdnhgIFwGF02rkSOApVm3t 3jUA== X-Gm-Message-State: AElRT7Fwy1Ibmup+Bps5QHcKnd8RUPokCoTscAkMFyo3VPWZPmMICXqp mDrk4Uv92qxgDTSvnLRH3thZbw== X-Google-Smtp-Source: AG47ELsFoRL1LGF1OkAtjq0qHftUhR/fT5MY2ACdXWovNrBXvH2zjhFMw2b69bfDBTj7fqY8SJjRCw== X-Received: by 10.223.134.210 with SMTP id 18mr904491wry.232.1521015785106; Wed, 14 Mar 2018 01:23:05 -0700 (PDT) Received: from mb.tns.cz ([2001:470:6f:ca1:ae2b:6eff:fe6a:b6cf]) by smtp.gmail.com with ESMTPSA id g25sm1002534wmc.0.2018.03.14.01.23.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Mar 2018 01:23:04 -0700 (PDT) Sender: Martin Beran Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD To: freebsd-hackers@freebsd.org References: <201803132055.aa28780@berenice.pkmab.se> <20180313222344.2929E156E812@mail.bitblocks.com> <1f8fc07b-9bf0-f9b2-ae7e-7cb0919722d0@gmail.com> From: Martin Beran Message-ID: <25bb803d-5d60-c8e0-f9a1-aaf0f5aa4d4e@mber.cz> Date: Wed, 14 Mar 2018 09:23:02 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1f8fc07b-9bf0-f9b2-ae7e-7cb0919722d0@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 08:23:07 -0000 On 03/14/18 01:16, Theron Tarigo wrote: > On 03/13/18 18:23, Bakul Shah wrote: >> Plan9 has no root (superuser) or setuid.  You can mangle >> anything in your namespace but it affects only *your* own >> process and its future descendents. >> > Although it would limit the usefulness of it, ignoring any and all file > suid bits for any process with a non-empty mount table should in theory > prevent exploitation of setuid.  Allowing safe setuid in combination > with ("trusted" ?) namespaces would be something to add support for much > later if someone decides it would be useful. > > By focusing on a narrowed case, that of allowing an unprivileged process > to alter its view into the vfs in a way which is only preserved through > execve() in specific safe circumstances, I hoped to avoid the > insurmountable complexity of implementing the feature in the full > generality that is available on Plan9. Another possibility would be to decouple security related decisions from the file system namespaces. What I mean is that, for example, /etc/master.passwd should not be trusted by su because of the file name. Instead, it could bear some attribute assigned by root denoting it as a valid passwd database. If su accessed a file without this attribute, the kernel would withdraw its capability to switch user identity, regardless of its setuid. If any processes without a relevant privilege modifies /etc/master.passwd, the kernel would automatically remove the "passwd db" attribute from the file. Naturally, a password file installed by an ordinary user via altering the file system namespace would not have the attribute. Such security (in fact, integrity-defining) attributes would be attached to the files and possibly other system objects themselves, not to their names. I understand that implementing such security mechanism would require much much larger effort than the above mentioned ad-hoc solution. But I think it has the potential to solve many other security-related problems. -- Martin Beran