Линус Торвальдс одобрил внедрение функции ограничения прав суперпользователя Lockdown в версии ядра 5.4 ОС Linux

[Evengard]

UAC — теперь и в Linux…
А кстати как защищается эта штука от отключения из-под суперюзера? На крайняк суперюзер может, наверное, поменять настройки на диске и просто отправить машину в ребут. У суперюзера всё равно же остаётся полный доступ к диску. SecureBoot тут врядли спасёт — он просто может подсунуть "ванильное" ядро где эта штука выключена, и при этом подписана стандартными ключами...

[ValdikSS]

SecureBoot тут врядли спасёт — он просто может подсунуть «ванильное» ядро где эта штука выключена, и при этом подписана стандартными ключами...

В популярных дистрибутивах эти патчи используются уже много лет, придётся поискать подписанное ядро и подписанный загрузчик к нему.
Спойлер: сложно, но возможно.

[firk]

UAC — теперь и в Linux…

Это не UAC, это стырили kern.securelevel из BSD который там нативно всегда был. Но стырили в каком-то обрезанном варианте, впрочем как всегда у линукса.

А кстати как защищается эта штука от отключения из-под суперюзера?

Никак, это не её зона ответственности. Это не "готовое решение" а просто одна из настроек. В комплексе с другими возможно можно построить систему защиты.
В нормальных системах (BSD) это естественно давно уже есть в удобном виде.

[qw1]

То как-то администраторы могут устанавливать новые драйверы?
Или драйверы должны быть подписаны, но тогда кто центр доверия?

[atbuhw]

Я надеюсь (описание ограниченных функций в статье создаёт такое впечатление), что все эти ограничения относятся только к доступу к уже работающему ядру. Тогда они не должны мешать смонитровать /boot, записать туда то, что нужно и перезагрузиться.

[ValdikSS]

Да, по умолчанию insmod неподписанных модулей блокируется, если включён Secure Boot. Однако, в этих дистрибутивах есть механизмы автоматической(!) генерации и добавления своего локального ключа в ~Secure Boot (в Shim MOK на самом деле, но неважно), которые применяются, например, для DKMS-модулей. Пользователю нужно только единожды подтвердить добавление ключа при первой перезагрузке после генерации локального ключа.
Такое уже много лет в Ubuntu, например.

[monah_tuk]

Мы так подписываем свой драйвер после "отстройки" на пользовательской машине. Если честно, то смысла реагировать на неподписанные модули в таком раскладе не вижу никакого. Т.е. на защищённой машине не должно быть DKMS и все сторонние драйвера подписывать в удостоверяющем центре (но тогда беда с обновлениями самого ядра). В противном случае вся эта защита — это стальная дверь в бумажных стенах.

[qw1]

Да всегда сетевые сервисы крутились под своим юзером типа www, и никаких прав не требовали. Скорее всего, сабжевая проблема возникла на десктопных сценариях, когда юзер всегда сидит с правами root и не желает делать лишние телодвижения ради безопасности.

[qw1]

Сколько видел конфигураций, веб-сервер никто под рутом не пускает. Проблема с портами как-то решается, через тот же inetd

[andreymal]

Где можно посмотреть такие конфигурации? Сколько видел конфигураций — везде веб-серверы от рута работают. Как минимум во всех дебианах веб-серверы из коробки настроены на работу от рута.

А для apache2 работа от рута зачастую вообще категорически обязательна, потому что всяким разным модулям нужно делать su в разных пользователей.

[qw1]

А, вот оно в чём дело. Всякие php и прочие cgi уже работают не от рута. Я думал, они наследуют права сервера.

[andreymal]

То, что всякие php и прочие cgi работают не от рута, это, конечно, хорошо, но возможные уязвимости в мастер-процессах apache2/nginx к сожалению тоже никто не отменял (из последних CVE-2019-0211 например)

[atbuhw]

Где можно посмотреть такие конфигурации?

Если su не нужно (например, сайт без регистрации пользователей на VPS), то проблема самого приёма подключений на порт 80 или 443 решается с помощью iptables и REDIRECT/DNAT.

[qw1]

а вот про inetd ничего не слышал

Например, сервер firebird так работает: inetd слушает порт 3050, а процессы fb_inet_server запускаются из inetd не с рутом. Я думал, это стандартная практика для сетевых сервисов.

[Prototik]

Для приёма соединений нужен CAP_NET_BIND_SERVICE, а не рут права. Да и есть куча методов обхода этого (если по каким-то причинам не смогли в capabilities).

[monah_tuk]

Это если совсем без root. Если нет, то вполне можно использовать классический подход с запуском от root, созданием сокета, началом слушания его и последующим сбросом прав. Но так да, CAP_NET_BIND_SERVICE ставится на бинарь один раз и всё, дальше только не забыть переустанавливать по обновлению.

[Prototik]

Не обязательно на бинарь, его можно прописать в юнит systems, и тогда обновления нормально проходят.

[monah_tuk]

Да, точно, такой вариант в голову не пришёл.

[monah_tuk]

del

[RH215]

Ну очень далеко не всегда это делается. Особенно если сервис работает не через веб-сервер. В контейнерах так вообще редко процессы запускаются не от рута.

[Victor_koly]

через /dev/kmem, /dev/kmem и /dev/port

Беглое гугление незнакомой темы (а точнее — глянул ссылку) предполагает, что одним из «устройств» здесь было /dev/mem.

[Alex_ME]

А что мешает выполнить insmod и загрузить модуль, который делает что хочешь?

[Prototik]

Подписи модулей?

[ValdikSS]

habr.com/ru/news/t/470249/#comment_20720235

[Andrey_Rogovsky]

GrSecurity плавно мигрирует в main ветку.

[SamsonovAnton]

Кто готов пожертвовать свободой ради безопасности, не достоин ни свободы, ни безопасности.

Зашёл сюда увидеть эту расхожую на Хабре цитату, но почему-то не увидел. Как можно променять пьянящий дух свободы невозбранно отстрелить себе ногу на уютненький островок безопасности посреди болотца?

[atbuhw]

К чему здесь эта цитата? Как я понимаю, конфигурировать ядро я могу любым способом: так, что при следующей загрузке я получу либо полный рут, либо «урезанный». При этом даже в режиме «урезанного» рута ничего не мешает мне пересобрать ядро ещё раз, с новыми, неурезаннанными параметрами, и после следующей перезагрузки я получу снова полный рут. Какую свободу я теряю? Это всё равно что утверждать, что при логине под обычным пользователем я не достоин ни свободы, ни безопасности.