On 11/11/2015 03:30 PM, Konstantin Khorenko wrote:
https://jira.sw.ru/browse/PSBM-40837Evgenii 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, на мой взгляд, можно оставить как есть и в контейнеры не "пробрасывать". Евгений
_______________________________________________ Devel mailing list [email protected] https://lists.openvz.org/mailman/listinfo/devel
