Re: [PATCH 0/9] Multiple devpts instances

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

"H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org> writes:

> Serge E. Hallyn wrote:
>>>
>>> If you want security and permission arguments get with Serge and finish
>>> the uid namespace.  The you will have a user that looks like root but
>>> does not have permissions to do most things.
>>
>> Right, and in particular the way it would partially solve this issue is
>> that the procsys limit file would be owned by root in the initial uid
>> namespace, so root in a child container would not be able to write to
>> it.
>>
>
> No, uid namespace is not the right thing for this.  If anything, it should be
> controlled by a capability flag.  This is a general issue for procfs and sysfs
> as used for controlling any kind of system resources, though.

Yes, it is a general issue.

The design we have on the table is actually a security credentials
namespace not a uid namespace.  It encompasses uids, gids,
capabilities, and keys.

One of the biggest design constraints is that it should be possible to
create a credentials namespace without permissions and not have to worry
about confusing suid root executables.  Which means in that context a suid
root executable needs to mean an executable from the perspective an observer
outside the credential namespace does not have elevated privileges.

Once we get there, whether it is a capability based resource check or
a uid based resource check there will be no access from inside of a
credentials namespace, because no processes will have permissions to
access the resource.  Which is what was asked for.

That neatly solves the proc and sysfs issues as well as many others such
as access to /etc/passwd.

Eric