Миф или реальность: SELinux может ограничивать пользователя root?

Я где-то читал или слышал (возможно, в курсе SELinux от LinuxCBT ; но я не уверен), что существуют онлайн-серверы Linux, для которых также указан пароль пользователя root. Сервер Linux защищен с использованием правил SELinux, так что каждый может войти в систему с привилегированным пользователем, но не может причинить какой-либо вред ОС.

Это кажется мне мифом, но я хотел убедиться: можно ли укрепить Linux-систему (возможно, с помощью SELinux), чтобы даже пользователь root не мог выполнять с ней определенные вредоносные действия? (Примеры: удаление системных файлов, очистка файлов журнала, остановка критически важных служб и т. Д.)

Такая коробка Linux будет отличной отправной точкой для создания honeypot .

Редактировать: Основываясь на ответе (теперь удаленном) и небольшом поиске, я получил по крайней мере две ссылки, которые указывали на такие усиленные серверы Linux. К сожалению, оба сервера не работают. Для записи я скопирую и вставлю описания здесь:

1) С http://www.coker.com.au/selinux/play.html :

Бесплатный root-доступ на машине SE Linux!

Чтобы получить доступ к моей игровой машине Debian ssh по адресу play.coker.com.au от имени root, введите пароль ...

Обратите внимание, что такие машины требуют больших навыков, если вы хотите их успешно запустить. Если вам нужно спросить, следует ли вам запустить один из них, ответ будет «нет».

Цель этого состоит в том, чтобы продемонстрировать, что SE Linux может обеспечить всю необходимую безопасность без каких-либо разрешений Unix (однако все же рекомендуется использовать разрешения Unix также для реальных серверов). Также это дает вам возможность войти в систему SE и посмотреть, что это такое.

Перед входом в игровой автомат SE Linux убедитесь, что вы используете опцию -x, чтобы отключить переадресацию X11, или установите ForwardX11 no в файле / etc / ssh / ssh_config перед входом в систему. Также убедитесь, что вы используете опцию -a, чтобы отключить переадресацию агента ssh, или установите ForwardAgent no в файле / etc / ssh / ssh_config перед входом в систему. Если вы неправильно отключите эти настройки, то вход на игровой автомат подвергнет вас риску атаки через ваш SSH-клиент.

Существует канал IRC для обсуждения этого, это #selinux на irc.freenode.net .

Вот быстрый FAQ

2) С http://www.osnews.com/comments/3731

Цель усиленной Gentoo - сделать Gentoo жизнеспособной для высоконадежных и высокостабильных сред производственных серверов. Этот проект не является отдельным проектом, отделенным от собственно Gentoo; Предполагается, что это будет команда разработчиков Gentoo, которые сосредоточены на предоставлении решений для Gentoo, которые обеспечивают высокую безопасность и стабильность. Эта машина является демонстрационной машиной SELinux от Hardened Gentoo . Основное использование - тестирование и аудит интеграции и политики SELinux.

Реальность: да, SELinux может ограничивать пользователя root.

Это возможно, потому что SELinux на самом деле не заботится о текущем пользователе Unix: все, что он видит, это дополнительные метаданные, называемые контекстом (который включает, помимо прочего, поле домена ), и который позволяет SELinux решать, может ли запрошенное действие быть авторизовано или не.

То, что обычно подразумевается как пользователь root, будет отображаться в SELinux как пользователь root Unix, работающий с доменами SELinux unconfined_tили sysadm_t. Это классический всемогущий всемогущий пользователь root.

Тем не менее, можно идеально настроить его систему для запуска корневой оболочки (я имею в виду корневую пользовательскую оболочку Unix), на которой работает user_tдомен SELinux с ограниченными правами . Согласно политикам SELinux, такая оболочка не будет отличаться от любых других оболочек для пользователей с ограниченными правами и не будет иметь особых привилегий в системе, таким образом, эффективно ограничивая пользователя root.

Appart с экспериментальной точки зрения, делать такие вещи буквально бесполезно, однако подобная практика находит свое применение в реальном мире. Классическим примером может быть администратор базы данных, которому нужно иметь возможность останавливать / запускать демоны базы данных, редактировать файлы конфигурации и т. Д. Без SELinux все эти действия потребуют от пользователя перехода к привилегиям root (даже если это обычно для одного пользователя). sudoнапример, через командную строку через инструмент, но даже это может привести к утечкам).

Благодаря SELinux мы могли бы предоставить этому пользователю подлинную корневую оболочку, но вместо запуска unconfined_tили sysadm_tдоменов он будет запускать dbadm_tдомен. Это означает, что он будет иметь больше привилегий, чем пользователь с ограниченными правами, но эти новые привилегии будут ограничены тем, что необходимо для администрирования сервера базы данных: этот пользователь не сможет вмешиваться в другие службы, файлы или выполнять другие административные команды, чем те, что строго обязан делать свою работу.

Таким же образом, администраторы веб-сервера и других служб могут также иметь другие корневые оболочки, работающие параллельно в одной и той же системе, каждый из которых увидит, что их текущий пользователь Unix является пользователем root , но благодаря SELinux у каждого будут фактически разные привилегии, ограниченные нужен для своих целей .

Да, это возможно. Но не очень полезно.

Теоретически вы можете запретить пользователю root запускать двоичные файлы, которые могут быть использованы в злонамеренных целях, применяя политики через что-то вроде SELinux. Тем не менее, это создает проблему, заключающуюся в том, что даже если пользователю root изначально было запрещено что-либо делать, он или она могли бы просто использовать другие методы для изменения или удаления политик SELinux. Из-за этой проблемы вам фактически придется запретить пользователю root выполнять какие-либо действия вообще, что делает его не очень полезным.

Можно ли укрепить коробку Linux (возможно, с помощью SELinux), чтобы даже пользователь root не мог выполнять с ней определенные вредоносные действия?

Это может звучать дешево, но это просто: измените uid пользователя root на ненулевой. Просто перейдите в / etc / passwd и / etc / shadow, измените существующие записи uid = 0 из «root» на что-то другое, а затем добавьте учетную запись с именем «root», чей uid не равен нулю и не используется.

Это достигает цели без. Это также способ заявить, что любой может иметь «root-доступ» без фактического предоставления расширенных привилегий.