Как сопоставить системные вызовы Linux с возможностями

Question

Я хочу запустить контейнер в непривилегированном режиме. Это попытка сохранить его более безопасным и для лучшего контроля. Я записал несколько системных вызовов из своего контейнера. Ниже приведены системные вызовы:

recvfrom

ММАП

записывать

читать

fstat

recvmsg

mprotect

munmap

разъем

Fcntl

io_submit

io_getevents

Выбрать

epoll_ctl

lseek

sendmsg

IOCTL

стат

Отправить

sched_yield

sysdigevent

rt_sigaction

Как мне сопоставить вышеуказанные системные вызовы с возможностями? Я хочу добавить эти возможности во время работы моего контейнера

Answer 1

Помимо sysdigevent, который я не могу определить, остальные выглядят как основные системные вызовы. Если вы не работаете с привилегированными сокетами, необработанными блочными устройствами или чем-то еще по своей сути привилегированным, вам не нужны какие-либо возможности.

Answer 2

Вы можете просмотреть справочные страницы на наличие упоминаний о CAP_, что, конечно, не будет окончательным.

      LIST="epoll_ctl fcntl fstat io_getevents io_submit ioctl lseek mmap mprotect munmap read recvfrom recvmsg rt_sigaction sched_yield select sendmsg sendto socket stat sysdigevent write"
$ for S in $LIST ; do  \
   echo "syscall: $S" ; \
   man $S 2>/dev/null | grep "CAP_[A-Z]" | tr -s ' ' ;  \
done | grep -B 1 CAP

дает

      syscall: epoll_ctl
    If EPOLLONESHOT and EPOLLET are clear and the process has the CAP_BLOCK_SUSPEND capability, ensure that the system does not enter "suspend" or
    If EPOLLWAKEUP is specified in flags, but the caller does not have the CAP_BLOCK_SUSPEND capability, then the EPOLLWAKEUP flag is silently ignored.
    of the EPOLLWAKEUP with a check that caused the call to fail if the caller did not have the CAP_BLOCK_SUSPEND capability caused a breakage in at least
    it has the CAP_BLOCK_SUSPEND capability if attempting to use the EPOLLWAKEUP flag.
syscall: fcntl
    of the process. A process with the CAP_LEASE capability may take out leases on arbitrary files.
    /proc/sys/fs/pipe-max-size yield the error EPERM; a privileged process (CAP_SYS_RESOURCE) can override the limit.
syscall: io_submit
    EPERM The aio_reqprio field is set with the class IOPRIO_CLASS_RT, but the submitting context does not have the CAP_SYS_ADMIN capability.