capabilities

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

capabilities

Alex Efros-4
Hi!

А что нынче происходит с capabilities(7) - что является рекомендованной
best practice?

Теоретически включить в ядре поддержку FS_SECURITY должно быть хорошей
идеей, т.к. позволит заменить suid-в-root бинарники на обычные с setcap.
Но практически сейчас в портаж (в моей системе) из 23 пакетов с suid/root
бинарниками только 3 (wireshark, qemu и cdrtools) поддерживают capabilities,
да и то cdrtools всё-равно один бинарник оставляет suid-ным.

В результате получается, что от включения FS_SECURITY эффект скорее
отрицательный: suid-ных бинарников заметно меньше не становится, зато
появляется необходимость контролировать не только suid-ные бинарники, но и
бинарники с capabilities.


P.S. Последний раз я эту ситуацию проверял несколько лет назад, и картина
была примерно такая же. Иными словами никто системно не занимается
переводом ebuild-ов с suid на capabilities.

--
                        WBR, Alex.

Reply | Threaded
Open this post in threaded view
|

Re: capabilities

Pavel Labushev-4
On Mon, 30 Sep 2013 13:22:19 +0300
Alex Efros <[hidden email]> wrote:

> В результате получается, что от включения FS_SECURITY эффект скорее
> отрицательный: suid-ных бинарников заметно меньше не становится, зато
> появляется необходимость контролировать не только suid-ные бинарники, но и
> бинарники с capabilities.

Так и есть. Практика показала, что вместо возни с suidctl.conf,
патчами и DAC-разрешениями на setuid-бинарники, гораздо надёжнее и
почти так же просто написать простые разрешительные правила RBAC,
жёстко ограничивая только привилегированные процессы, включая
гадость вроде consolekit и policykit. К тому же, потом эти правила
можно дополнять всем, к чему душа ляжет.

У меня есть одна десктопная машина, на которой только два setuid-root
бинарника: sudo и сэндбокс хромиума. Оба разрешены на выполнение только
отдельным группам пользователей (то есть без o+x). Сэндбокс хромиума
ограничен через разрешения на директорию, в которой он лежит. В принципе
этим можно пользоваться без RBAC, если не лень ходить в консоль от
рута для запуска того же cdrecord и не работать в тяжёлых
десктоп-окружениях.

> P.S. Последний раз я эту ситуацию проверял несколько лет назад, и картина
> была примерно такая же. Иными словами никто системно не занимается
> переводом ebuild-ов с suid на capabilities.

Сейчасть также и едва ли изменится. У Hardened herd не хватает
ресурсов и желания для решения гораздо более простых и важных задач,
чем написание и проталкивание патчей на setuid-ный зоопарк из того,
что есть в portage.

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: capabilities

Alex Efros-4
In reply to this post by Alex Efros-4
Hi!

On Mon, Sep 30, 2013 at 07:38:51PM +0800, Pavel Labushev wrote:
> Так и есть. Практика показала, что вместо возни с suidctl.conf,
> патчами и DAC-разрешениями на setuid-бинарники, гораздо надёжнее и
> почти так же просто написать простые разрешительные правила RBAC,
> жёстко ограничивая только привилегированные процессы, включая
> гадость вроде consolekit и policykit. К тому же, потом эти правила
> можно дополнять всем, к чему душа ляжет.

Да, звучит разумно. Я так и не добрался до GrSec's RBAC/RSBAC/SeLinux.
SeLinux слишком переусложнён, RSBAC несовместим с GrSecurity, на AppArmor
я не смотрел. Самым привлекательным вариантом выглядит RBAC из GrSecurity,
но когда я много лет назад пытался с ним разобраться правила
сгенерированные режимом обучения были во-первых слишком большие и сложные,
а во-вторых нерабочие (много приложений глючило/падало и в каждом случае
уходило довольно много времени на то, чтобы выяснить что виноват RBAC и
поправить его правила).

Идея использовать вместо режима обучения простые разрешительные правила по
умолчанию и постепенно их дополнять ручными ограничениями отдельных
приложений выглядит соблазнительно в плане сложность/безопасность.
Этот подход где-то документирован (статьи, примеры, etc.)? Можете выложить
свои правила в качестве примера/стартовой точки?

--
                        WBR, Alex.

attachment0 (197 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: capabilities

Pavel Labushev-4
On Mon, 30 Sep 2013 15:56:09 +0300
Alex Efros <[hidden email]> wrote:

> Идея использовать вместо режима обучения простые разрешительные правила по
> умолчанию и постепенно их дополнять ручными ограничениями отдельных
> приложений выглядит соблазнительно в плане сложность/безопасность.
> Этот подход где-то документирован (статьи, примеры, etc.)? Можете выложить
> свои правила в качестве примера/стартовой точки?

Нет, свои правила выложить не могу из параноидальных соображний. ;)
Специальных статей и примеров не встречал, но и не искал. Всё было легко
постигнуто методом проб и ошибок вкупе с чтением базовой документации
на RBAC.

Основные правила - чтобы работала авторизация в gradm, включение и
отключение RBAC, произвольный доступ для субъектов пользователя root и
базовые ограничения для default - можно обкатать в виртуалке, запустив
там копию своей системы. Я так и сделал в своё время, а глобальным
режимом обучения даже ни разу не пользовался. Дальше можно задавать
ограничения уже на живой системе вручную или через обучение по
отдельным субъектам.

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: capabilities

Alexander Tiurin-2
In reply to this post by Alex Efros-4
Сейчас режим обучения RBAC я не назвал бы продвинутым,  хотя ранее я с
ним не работал.  Прмерно %30-50 он генерит верно. Хотя еще от
приложения зависит. У меня в топе по занудству это postfix. Примерно
более недели создавал для него правила как методом обучения так и
простым просмотром логов и создания правил вручную.

30 сентября 2013 г., 16:56 пользователь Alex Efros
<[hidden email]> написал:

> Hi!
>
> On Mon, Sep 30, 2013 at 07:38:51PM +0800, Pavel Labushev wrote:
>> Так и есть. Практика показала, что вместо возни с suidctl.conf,
>> патчами и DAC-разрешениями на setuid-бинарники, гораздо надёжнее и
>> почти так же просто написать простые разрешительные правила RBAC,
>> жёстко ограничивая только привилегированные процессы, включая
>> гадость вроде consolekit и policykit. К тому же, потом эти правила
>> можно дополнять всем, к чему душа ляжет.
>
> Да, звучит разумно. Я так и не добрался до GrSec's RBAC/RSBAC/SeLinux.
> SeLinux слишком переусложнён, RSBAC несовместим с GrSecurity, на AppArmor
> я не смотрел. Самым привлекательным вариантом выглядит RBAC из GrSecurity,
> но когда я много лет назад пытался с ним разобраться правила
> сгенерированные режимом обучения были во-первых слишком большие и сложные,
> а во-вторых нерабочие (много приложений глючило/падало и в каждом случае
> уходило довольно много времени на то, чтобы выяснить что виноват RBAC и
> поправить его правила).
>
> Идея использовать вместо режима обучения простые разрешительные правила по
> умолчанию и постепенно их дополнять ручными ограничениями отдельных
> приложений выглядит соблазнительно в плане сложность/безопасность.
> Этот подход где-то документирован (статьи, примеры, etc.)? Можете выложить
> свои правила в качестве примера/стартовой точки?
>
> --
>                         WBR, Alex.