[lxc-devel] [PATCH RFC] introduce lxc.cap.keep

[Qiang Huang]

On 2013/7/3 13:19, Serge Hallyn wrote:
> Quoting Qiang Huang (h.huangqiang at huawei.com):
>> On 2013/7/3 11:23, Serge Hallyn wrote:
>>> Quoting Serge Hallyn (serge.hallyn at ubuntu.com):
>>>> The lxc configuration file currently supports 'lxc.cap.drop', a list of
>>>> capabilities to be dropped (using the bounding set) from the container.
>>>> The problem with this is that over time new capabilities are added.  So
>>>> an older container configuration file may, over time, become insecure.
>>>>
>>>> Walter has in the past suggested replacing lxc.cap.drop with
>>>> lxc.cap.preserve, which would have the inverse sense - any capabilities
>>>> in that set would be kept, any others would be dropped.
>>>>
>>>> Realistically both have the same problem - the sendmail capabilities
>>>> bug proved that running code with unexpectedly dropped privilege can be
>>>> dangerous.  This patch gives the admin a choice:  You can use either
>>>> lxc.cap.keep or lxc.cap.drop, not both.
>>
>> What if someone use them both?
> 
> Then you get
> 
> 	ERROR("Simultaneously requested dropping and keeping caps");

Looks familiar with lxc.cgroup.devices.deny and lxc.cgroup.device.allow,
and this seems useful for Walter, if we have this kind of obvious hints for
use them both, there will be no objection from me :)

> 
>> I don't see too much help from this patch, and this introduce some
>> confusion :(
> 
> Walter's idea was that if you want to give a container only
> CAP_SYS_TIME, so you explicitly blacklist all the others, and then you
> update to a new kernel which introduces a new capability, then you'll
> end up with more capabilities in the container than you'd wanted.
> 
> The idea has both merits and flaws.  But if noone else actually wants
> to use this, then I prefer not to add it, as it's one more code path
> to risk getting stale and buggy over time.
> 
> thanks,
> -serge
> 
>