Почему chroot считается небезопасным?

Я играл с CentOS Box уже пару лет. Так что я довольно удобен с терминалом. Тем не менее, я прочитал много постов в блоге, утверждая, что chroot небезопасен и количество этих постов пугает. Это действительно так? Почему?

Я использую chroot для блокировки пользователей только SFTP в определенном контексте, без какой-либо оболочки или команд вообще. Так что на самом деле, в чем проблема безопасности?

Вопрос выслан из StackOverflow .

— Александр Маков
источник

Во-первых: вопрос не был закрыт / перенесен при переполнении стека , но это явно ОТ. Надлежащим действием будет подождать, пока он будет перенесен, или пометить его и попросить мод сделать это, а не размещать перекрестную публикацию на другом сайте. Но второе: если вы «играете с CentOS», вы и здесь ошибаетесь. Этот сайт предназначен для профессиональных системных администраторов, а не любителей. Пожалуйста, смотрите наш FAQ .

— Свен

@SvenW спасибо, я учту твой совет на будущее. А насчет «второго», ну извините, но я не вижу, как мой вопрос нарушает FAQ. Теперь, прочитав его дважды, я могу сказать, что это не так. Что касается фразы «поиграйся с CentOS», я подумал, что совершенно очевидно, что пользователи, использующие chroot и SFTP, а также вопросы безопасности - это очень серьезная тема, от которой профессионалы могут извлечь выгоду как в своей корпоративной, так и в любой другой ». профессиональная "среда.

— Александр Маков

@sven в случае, если вы не знали, SF был удален из списка миграции SO из-за того, что нам присылают плохие вопросы.

— MDMarra

Ответы:

Потому что в большинстве случаев корневой процесс может легко выйти из chroot. Это сделано специально, так как chroot никогда не предназначался для защиты.

Алан Кокс несколько классно обругал разработчика, который представил исправление ядра, чтобы «исправить» это поведение, утверждая, что chroot использовался как средство защиты, но никогда не предназначался для него.

— MDMarra
источник

Отлично! Большое спасибо. Так что это вопрос корневых процессов, которые присутствуют в корне или доступны из него. Благодарю.

— Александр Маков

Я только что подтвердил, что, запустив программу C, показанную на unixwiz.net/techtips/mirror/chroot-break.html от имени root в Linux 4.18, можно избежать chroot.

— очко

Так что не раздавайте привилегии root. Даже обычные «безопасные» системы имеют учетные записи root.

— Сис Тиммерман

Я знаю, по крайней мере, один пример того, почему это считается небезопасным. Среда chroot /procне изолирована, поэтому довольно легко получить доступ к ресурсам, не принадлежащим процессам, запущенным в вашем chroot.

Использование chrooted окружения для SFTP прекрасно и значительно повышает уровень безопасности. Только не используйте это как виртуализацию на основе контейнеров, которая обеспечивает более высокий уровень безопасности. В этом я подчеркиваю, что в ответе @ MDMarra.

— gertvdijk
источник

Спасибо. Так что теперь стало более ясно, что сам chroot не плох в безопасности, а, скорее, его безопасность зависит от среды, в которой он установлен.

— Александр Маков

На самом деле, chroot не плох в безопасности, потому что он никогда не предназначался для защиты. Он должен был быть средством разработки для одновременного запуска нескольких версий одних и тех же двоичных файлов с различными зависимостями. Это не замена для надлежащей защиты услуг - хотя это может быть полезно в определенных обстоятельствах, если вы понимаете, что это такое, а что нет.

— MDMarra

MDMarra, по сути, chroot не предназначен для захвата SSH-соединений. Тогда, по вашему мнению, "хромирование входящих SSH-соединений" звучит для вас несколько непрофессионально и этого следует избегать?

— Александр Маков

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

— MDMarra