[Pkg-shadow-devel] [test] newuidmap/newgidmap]

[Philippe Grégoire]

On 3 juin 2014 18:30:46 HAE, ebiederm at xmission.com wrote:
>Philippe Grégoire <gregoirep at hotmail.com> writes:
>
>> Hi, I miswrote you address. Resending it to you in case you are not
>subscribed
>> to the mailing list.
>>
>> On 2014-06-03 20:02:12 (+0000), Serge Hallyn wrote:
>>> Quoting Eric W. Biederman (ebiederm at xmission.com):
>>> > Root should be documenting which uids root uses in containers in
>>> > /etc/subuid just like everyone else.  That will allow sysadmins
>>> > to figure out what is going on.
>>> > 
>>> > So if you document what is going on, the only case that will fail
>for
>>> > root are for uids that you did not intend to use.  I don't see
>that as a
>>> > bad thing, and certainly I don't see it impeding code reuse.
>>> > 
>>> > Why should root owned containers be special and not have to
>document
>>> > which uids they use?
>>> 
>>> Because root is special, and people expect that they can just do
>things
>>> as root, especially if the kernel doesn't prevent it.
>>> 
>>> I'm not saying this pursuades me.  I'm saying I consider this only
>as
>>> valid of an argument as the below.
>>> 
>>> > Why should root owned containers not have to worry
>>> > about using uids that someone is using for something else?
>>> 
>>> They very much do have to, which I've always said is the flipside
>>> argument.  That it is useful for protecting root from unpriv users.
>>> 
>>
>> Eric, you seem to place best practice first. Which is fine, but
>contradicts the
>> idea that root can do 'rm -rf /*'. And, why would root use containers
>in the
>> first place?
>
>Other than historic practice because root was the only one who had the
>permissions to?  I don't know.
>
Nobody's going to start a philosophical debate here. Let's just say that consistency is important as it frees the mind.

>> By leaving newuidmap unchanged and toolsets relying on it, they must
>bail out if
>> the administrator doesn't have subids defined. It follows best
>practice, but
>> root expects to have no restrictions. Also, the kernel doesn't care
>about policy
>> so if one tool follows best practice, another might not. Which goes
>against the
>> principle you are trying to enforce.
>>
>> If you really care about best practice, put /etc/sub*id in the kernel
>and have
>> roots be disciplined by allocating unique ranges. 
>
>I did put it in the kernel (effectivley).  newuidmap is the load
>mechanism.
>
I don't think you understand what I meant: /proc/sys/kernel/subuid -like file.
Not in userland, and read by the kernel.

>Furthermore uids are larger than the kernel.  uid policy is
>multimachine
>and multi-boot.  So this is not a policy that can ever live completely
>in the kernel.
>
>I agree we can't enforce it on root.  But as a tool to whose focuse is
>to allow things for non-root users I don't see how special casing root
>does anyone any favors.
>
>There could be a force option somewhere.  But shrug.
>
Force for who? Everyone? It cannot be serious...

>> If not, newuidmap could be
>> modified for SETUID users (so assumptions are respected), or else
>document the
>> exception in the manual (i.e.: no subuids, no mapping).
>
>How is that an exception.  That is what the tool does.  If there are no
>subuids no mapping is set up.
>
>The biggest argument for me is that adding an extra case to a setuid
>application is DANGEROUS.  Every little extra feature makes auditing
>the
>binary more difficult.
>
>So I just think this tiny little binary should do exactly one thing,
>and
>do it well.
>
>As for documentation that newuidmap will only do one thing.  That seems
>entirely reasonable.
>

After all, what I asked for was for a precision in
newuidmap(1) stating that it is not meant to be used by privileged users and advise to fallback on the kernel.

Now, writing to uid_map overrides sub*id and we are running in circles here. Someone with
authority has to decide... What is the recommendation for toolsets? Respect newuidmap? If so, no fallback and we are done
here.

Thanks.

P.G.