From owner-freebsd-hackers@freebsd.org Tue Mar 13 21:41:32 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 3A61EF52D8B for ; Tue, 13 Mar 2018 21:41:32 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 C217677793 for ; Tue, 13 Mar 2018 21:41:31 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: by mail-qt0-x22b.google.com with SMTP id g60so1311678qtd.11 for ; Tue, 13 Mar 2018 14:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=44pBDOhOO5UU0k0l8RoLcmzPLTRE0Ddf13xNc0xYcvs=; b=dfqheE9bIAQrMilVrPvdMaCNNSmYnWkpN31blrTg0JpNE3B2dCZWKp+KLTTBagdf9O j5kruaz/AJZ6uzzUlKch5SQZt64P+RvepEbJBkx0XFX/IqlZix1YyBU8UvShbdoni+fS kbqeAc7Vx/vSnSnt+SH8wt5sUoWtdHpoL1pgGkPSR3CfiAouAMY44MoAP4XUatjvy/wz LfN9m/5agHNmeSbkvVgtedpu4xIT8si/PgvrBHyjEbbxWVGLvHQG/hbbXaVDZ9HZ2yWF PQtHLUTB5/BQ96w2i/HB92nSnByoLprrxhzb0C/jzt/3KsX9eXbNdP17cnwi2RTvQii1 YKuA== 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:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=44pBDOhOO5UU0k0l8RoLcmzPLTRE0Ddf13xNc0xYcvs=; b=BwbWhLTmbWX5M2pkfpHafZkJuIBLDIiG62qTJm+tSGdXKutPrJAJbCbNEmxMOy5tG4 ncXJOEuzxAhY2+wYGptZE7rPh/BK9zfkqjNhMOaUbmls4Kv4pul/XU+34ZjfqkAufhpg cKvea0p7Qwekf9dJ3IgetWm7+FfXIDlNSzvYlcxwxOxvnDjHp1LayvKkFGxy/1kozXWC 1nuk2SCyh4ctftMbtdOubTTf5WmPm6NStLP57pzyV3TdITSY/2+c5rxglKQWCxwmgiv1 WO9fAWJvpqHhsD7Ijo/Q97aNpTDQfo3P+iErV2QIfAK+pR/yM6mfIyc+nXJxmXlSn6wM rswQ== X-Gm-Message-State: AElRT7F94/o+3SsXk9TX6Paznba1q0Uz72FXDldXHNPDgihhhaIW5/mq g1LgmbloSfvba68w2Z+KrTPVX+wG X-Google-Smtp-Source: AG47ELv4xp6515rSZjcnu+evc52BRyCq1rNwDkgBHiW/cGYZBtV24AHJOAwFMvFonyRfucvF28ujcA== X-Received: by 10.200.51.215 with SMTP id d23mr1104935qtb.338.1520977290846; Tue, 13 Mar 2018 14:41:30 -0700 (PDT) Received: from [155.41.26.230] (dhcp-wifi-8021x-155-41-26-230.bu.edu. [155.41.26.230]) by smtp.gmail.com with ESMTPSA id s184sm470367qke.55.2018.03.13.14.41.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 14:41:30 -0700 (PDT) Sender: Theron Tarigo Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD To: Kristoffer Eriksson Cc: freebsd-hackers@freebsd.org References: <201803132055.aa28780@berenice.pkmab.se> From: Theron Tarigo Message-ID: Date: Tue, 13 Mar 2018 17:41:28 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <201803132055.aa28780@berenice.pkmab.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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: Tue, 13 Mar 2018 21:41:32 -0000 Hi Kristoffer, That will of course need to be worked out, since it is the classic safety problem  of chroot.  The first idea I can think of is that any user-switching (i.e. executing setuid files) resets the namespace, similarly to "su - " resetting the environment variables by way of simulating a new login.  Maybe it will not work out to be so simple, as I can see there will be a lot of research ahead for me, but I feel strongly that it will not be insurmountable.  If I implement this as a special filesystem rather than as a modification to the vfs, it can be as simple as not allowing any setuid, as with the "nosuid" option of existing filesystems. As I understand it, Plan9 uses namespaces so thoroughly that a superuser is not needed and all restrictions of privilege are accomplished through launching "unprivileged" processes into a namespace that contains only the resources that user should have access to.  While this may make sense within Plan9, it is sufficiently alien to the Unix ways of handling security that I don't think it makes any sense to try to do things this way on FreeBSD.  There will probably always be security risks associated with anything running as uid 0 regardless of restrictions to its environment.*  What I am trying to accomplish is to stay roughly within the Unix model but to provide a layer of flexibility appropriate for addressing a specific need, and the solution I have in mind happens to parallel a Plan9 concept. Theron * """      In addition, there are several ways in which an unprivileged user outside      the jail can cooperate with a privileged user inside the jail and thereby      obtain elevated privileges in the host environment. """ - JAIL(8) manual On 03/13/18 15:55, Kristoffer Eriksson wrote: > On 13 Mar 2018 12:53:18, Theron wrote: >> For those unfamiliar with Plan9, here is a rough explanation of the >> namespace feature: unlike in Unix, where all processes share the same >> virtual filesystem, each process instead has its own view of the >> filesystem according to what has been mounted ... > What if I mount a new /etc with a passwd file where root has no > password, and then run "su"? > > (How does Plan9 handle that?) > > Regards/Kristoffer Eriksson