GSoC Idea: per-process filesystem namespaces for FreeBSD

[Martin Beran]

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