LINUX.ORG.RU
Форум — General  

Capabilities в контейнере

 , , , ,


0

1

1) Запускаю я значит контейнер командой (включаю все capabilities) 

docker run -ti --cap-add=DAC_READ_SEARCH --cap-add=LINUX_IMMUTABLE --cap-add=NET_BROADCAST --cap-add=SYS_RAWIO --cap-add=IPC_LOCK --cap-add=IPC_OWNER --cap-add=SYS_MODULE --cap-add=SYS_PACCT --cap-add=SYS_BOOT --cap-add=SYS_NICE --cap-add=SYS_RESOURCE --cap-add=SYS_TIME --cap-add=SYS_TTY_CONFIG --cap-add=LEASE --cap-add=AUDIT_CONTROL --cap-add=SETFCAP --cap-add=MAC_OVERRIDE --cap-add=MAC_ADMIN --cap-add=SYSLOG --cap-add=WAKE_ALARM --cap-add=BLOCK_SUSPEND --cap-add=SYS_ADMIN --cap-add=NET_ADMIN --cap-add=SYS_PTRACE --cap-add=BLOCK_SUSPEND  kdeneon/plasma
2) Проверяю capabilities процесса 1 и процесса bash в контейнере 
Capabilities for `12298': = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend+eip

Capabilities for `1': = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,37+ep

3) А дальше в контейнере: 

root@25c5d7ef2355:~# mount -obind /home /mnt
mount: /mnt: bind /home failed.

Почему не могу монтировать внутри контейнера ?

PS: я знаю, что можно добавить --privileged. Но хочется разобраться с конкретным поведением )



Последнее исправление: cyber_eagle (всего исправлений: 1)

🤦‍♂️

Запускаю я значит контейнер командой (включаю все capabilities)
docker run -ti --cap-add=DAC_READ_SEARCH --cap-add=LINUX_IMMUTABLE --cap-add=NET_BROADCAST --cap-add=SYS_RAWIO --cap-add=IPC_LOCK --cap-add=IPC_OWNER --cap-add=SYS_MODULE --cap-add=SYS_PACCT --cap-add=SYS_BOOT --cap-add=SYS_NICE --cap-add=SYS_RESOURCE --cap-add=SYS_TIME --cap-add=SYS_TTY_CONFIG --cap-add=LEASE --cap-add=AUDIT_CONTROL --cap-add=SETFCAP --cap-add=MAC_OVERRIDE --cap-add=MAC_ADMIN --cap-add=SYSLOG --cap-add=WAKE_ALARM --cap-add=BLOCK_SUSPEND --cap-add=SYS_ADMIN --cap-add=NET_ADMIN --cap-add=SYS_PTRACE --cap-add=BLOCK_SUSPEND kdeneon/plasma

🤦‍♂️ docker run -ti --cap-add=ALL kdeneon/plasma 🤦‍♂️

anonymous
()
Ответ на: 🤦‍♂️ от anonymous

Так, конечно, лучше) Но концептуально ничего не поменялось.

Монтировать все еще невозможно.

cyber_eagle
() автор топика

Заметил, что внутри контейнера можно монтировать.

Так же, если подключится к mnt namespace снаружи другим процессом, то монтировать можно. Значит дело не в дереве точек монтирования.

cyber_eagle
() автор топика

Воспроизвести в qemu с тем же ядром не полуилось. При таком же сценарии монтирование в контейнере работало нормально. Для него достаточно SYS_ADMIN.

Отличие было только в rootfs... Возможно подгружается модуль, изза которого возникает такое поведение.

Пока что непонятно, почему --privileged позволяет монтировать, а получение всех capabilities - нет... docker не такой уж и прозрачный(((

Попытаюсь запустить со своей rootfs в qemu.

cyber_eagle
() автор топика

Запустил свою rootfs в qemu. Монтировать не получилось.

Тоесть воспроизведение зависит не от ядра, а от rootfs:

- На debootstrap не воспроизвелось

- На kdeneon/plasma воспроизводится

Попытаюсь собрать ядро для отладки через gdb

cyber_eagle
() автор топика

Вообщем не стоит тратить на это время, ничего интересного нету:

поставил бряку на security_sb_mount, а там apparmor возвращает EPERM.

Проверяем apparmor: 

	root@PLOTVA:~# aa-status                              
	apparmor module is loaded.                            
	1 profiles are loaded.                                
	1 profiles are in enforce mode.                       
	   docker-default                                     
	0 profiles are in complain mode.                      
	1 processes have profiles defined.                    
	1 processes are in enforce mode.                      
	   docker-default (929)                               
	0 processes are in complain mode.                     
	0 processes are unconfined but have a profile defined.

И в который раз убеждаемся в том, что security модули для линукс - зло.

Почему не воспроизводился на debian? - потому, что там другая сборка докера, которая не конфигурила аппармор.

Как то так...

cyber_eagle
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
General