> Да, это не костыльная система, запускать все приложения от отдельного пользователя…прикинь: не костыльная. тут ссылка проскакивала на slated, так вот ещё одна: http://slated.org/the_straw_that_broke_the_penguins_hat
процитирую оттуда пару фраз: «These technologies are «solutions» to entirely fictitious problems, and the former in particular is closely related to the same issues surrounding the PackageKit scandal. If unprivileged users are never given elevated privileges in the first place, then there simply isn't any need for mandatory access controls - standard UNIX security methods are sufficient.»
просто рассматривай пользователей и группы как механизм для security.
> Правильный подход к конфигурированию подсистемы, это когда для изменения
> одного из её параметров (например, запрета отправки пакета на заданный порт
> для заданного приложения) нужно добавить опцию только в одном месте.
ага. а тут мне вдруг захотелось странного: вот сейчас этой программе доступ дать (на один запуск). а вот той — не давать (на один запуск). что я делаю в случае использования вышеприведённого? запускаю «эту» программу от пользователя, которому можно, а «ту» — от пользователя, которому нельзя. а что я делаю, если «всё в одном месте»? правильно: сначала переконфигурирую систему, потом запускаю софты, потом опять переконфигурирую систему. очень удобно и очень защищено от ошибок (например, от ситуации, когда я забыл всё переконфигурировать назад «как было»).
проблема всяких MAC, отделённых от механизма user/group в том, что они тупо добавляют новую сущность вместо использования старых там, где это вполне вписывается в логику.