Date: Wed, 14 Mar 2018 09:23:02 +0100 From: Martin Beran <martin@mber.cz> To: freebsd-hackers@freebsd.org Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD Message-ID: <25bb803d-5d60-c8e0-f9a1-aaf0f5aa4d4e@mber.cz> In-Reply-To: <1f8fc07b-9bf0-f9b2-ae7e-7cb0919722d0@gmail.com> References: <d7621074-acb4-c5b6-1efd-dc55b51586b1@gmail.com> <201803132055.aa28780@berenice.pkmab.se> <CANCZdfoU1B4228RpwfupvdVN9RPCCug4p283xmkNwW7t-M9CjA@mail.gmail.com> <20180313222344.2929E156E812@mail.bitblocks.com> <1f8fc07b-9bf0-f9b2-ae7e-7cb0919722d0@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25bb803d-5d60-c8e0-f9a1-aaf0f5aa4d4e>