[Devel] questions on capabilities (PSBM-40837)

[Konstantin Khorenko]

On 11/11/2015 03:30 PM, Konstantin Khorenko wrote:
> https://jira.sw.ru/browse/PSBM-40837
>
> Evgenii Shatokhin added a comment - 09/Nov/15 5:13 PM
>   > Here are the results for the capabilities in the containers.
>   > ...
>   > The following ones do not work (or work only partially) for the users in the container, including root:
>   > * sys_module: loading/unloading of a kernel module fails.
> We had usecases for that (loading iptables modules), but currently i don't know if anybody use this functionality.
> (Because we've implemented autoload feature for that particular usecase)
>
> ======================
>   > * setfcap: setting file capabilities fails.
> Let's don't allow this in order to make harder cracking system,
> otherwise if a process can get out of ns, it will execute CT-owned precreated file with max security.capabilities set
> and get the control other the system.
>
> ======================
>   > * fsetid: root can set/remove setuid flag for any executables but changing a setuid binary results in the dropped setuid flag.
> It makes sense to change it into ve_capable() in cap_bprm_set_creds(), but only after we enable setfcap which we are not going to now.
> => leave as is.
>
> ======================
>   > * linux_immutable: "chattr +i {file}" does not work in the container but works on the host.
> Well, it seems it's safe to enable this in a Container running on a ploop,
> but it's inconvenient in case of a shared fs between Containers, which is going to be simfs in vz7
> (because if someone set immutable attr inside a CT, prctl won't be able to destroy the CT when needed,
> need to remove the immutable attr first).
>
> => i'll add a dev task for the future: if someone needs support for file attrs inside a CT,
> need to enable it for ploop case only, and prohibit in case simfs (any shared fs) is used (some flag on superblock?).

https://bugs.openvz.org/browse/OVZ-6573
https://openvz.org/Kernel_TODO

> ======================
>   > * sys_nice (decreasing niceness does not work).
> Let's don't allow it.
>
> ======================
>   > * sys_resource: ulimit allows to increase some of the limits (core file size, stack size, ...) but not all.
>   > For example, it cannot increase "max user processes" limit.
> do_prlimit():
> ...
>                   /* Keep the capable check against init_user_ns until
>                      cgroups can contain all limits */
>                   if (new_rlim->rlim_max > rlim->rlim_max &&
>                                   !capable(CAP_SYS_RESOURCE))
>                           retval = -EPERM;
>
> Let it be as is.
>
> ======================
>   > * sys_pacct - I sent a simple patch to make it work (https://jira.sw.ru/browse/PSBM-40587).
> Good, will apply.
>
> ======================
>   > * audit_write, but it makes little sense without CAP_AUDIT_CONTROL (turn audit on/off and adjust its rules).
> It's ok, will enable in case there is a demand.
>
>
> Evgenii, thank you.
>
> --
> Konstantin
>
> On 11/09/2015 05:37 PM, Evgenii Shatokhin wrote:
>> Ещё раз добрый день, Константин!
>>
>> По PSBM-40837. Я пересмотрел capabilities, написал там, в баге, какие
>> работают, а какие нет.
>>
>> Есть сомнения по 4 из capabilities.
>>
>> Стоит ли давать процессам в контейнере возможность:
>>
>> 1) уменьшать их 'nice number' (CAP_SYS_NICE capability)?
>>
>> 2) увеличивать лимит "max user processes" для процесса (CAP_SYS_RESOURCE
>> capability)?
>>
>> 3) запрещать изменения в каких-то файлах с помощью "chattr +i {file}"
>> или чего-то аналогичного (CAP_LINUX_IMMUTABLE capability)?
>>
>> 4) задавать и убирать capabilities для исполняемых файлов (CAP_SETFCAP
>> capability)?
>>
>> Эти вещи сейчас не работают в контейнерах.
>>
>> (3), (4), на мой взгляд, контейнерам не нужны, но мало ли.
>> Насчёт (1) и (2) - безопаснее бы не давать, но возможно, есть какие-то
>> ситуации, когда это нужно?
>>
>> Остальные capabilities, на мой взгляд, можно оставить как есть и в
>> контейнеры не "пробрасывать".
>>
>> Евгений