Почему не все разрешенные возможности процесса linux эффективны постоянно?

К сожалению, единственный способ решить эту проблему - переустановить Windows 10 в режиме UEFI, а затем переустановить Fedora в режиме UEFI. Потом немного повозились с порядком загрузки. Наконец, у меня работают обе системы.

Какой беспорядок ...: (

4
29.07.2016, 01:48
2 ответа

Быстрая гипотеза, где это может быть полезно: Вы хотите, чтобы пользователь мог копировать (читать) любой файл в системе, но не изменять (записывать) их. У вас может быть программа, имеющая CAP_DAC_OVERRIDE (чтобы игнорировать проверку разрешений), которая работает как cp. Но чтобы убедиться, что он не позволяет пользователю резервного копирования перезаписывать произвольные файлы, он может удалить CAP_DAC_OVERRIDE из эффективного набора перед открытием каждого выходного файла.

Что касается вашего бонусного вопроса: Ничто не мешает вернуть их в эффективное состояние, если можно запустить произвольный код. Но это может быть полезно в случае другой компрометации (например, вы убеждаете программу попытаться перезаписать произвольный файл через атаку symlink).

3
27.01.2020, 20:52

Разница между эффективными / разрешенными возможностями аналогична разнице между действительными / эффективными UID в программах с setuid. Идея состоит не в том, чтобы помешать мошенническому приложению увеличивать привилегии (вы бы не предоставляли им привилегии в первую очередь, так же, как вы не устанавливали бы их), а чтобы позволить программе работать с минимальными привилегиями и повышать уровень только там, где это необходимо. .Это помогает свести к минимуму влияние ошибок.

Очень надуманный пример: я хочу иметь программу, которая позволит мне отправлять SIGHUP процессам, принадлежащим пользователю или , чтобы позволить пользователю God отправлять SIGHUP на init .

Эта программа имеет возможность CAP_KILL, установленную для файла.

Псевдокод может выглядеть примерно так:

drop_effective CAP_KILL
repeat forever:
  get_process_id_from user
  if process_id==1 and user_is_God:
    set_effective CAP_KILL
    kill(-1,1)
    drop_effective CAP_KILL
 else:
   kill(-1,process_id)

Очевидная ошибка заключается в том, что я не проверяю, разрешено ли пользователю отправлять сигнал. Поскольку я отказался от эффективного разрешения CAP_KILL, я не позволю пользователю убивать процессы, кроме их собственных.

Конечно, очень надумано! Но идея состоит в том, чтобы работать как можно дальше с «наименьшими привилегиями» и разрешать привилегии только при необходимости.

Теперь это не обязательно защитит от атак переполнения буфера, потому что внедренный код может разрешить разрешенные привилегии, поэтому код, учитывающий возможности, должен также отбрасывать разрешенные привилегии, когда они больше не нужны; например, веб-сервер может сбросить CAP_NET_BIND_SERVICE после того, как он привязан к порту 80. Вы не можете включить что-то, не входящее в разрешенный набор!

4
27.01.2020, 20:52

Теги

Похожие вопросы