Информационная безопасность

Зачем это нужно?


Например, на вашем сервере есть несколько сервисов, и вам хотелось бы изолировать их друг от друга и от основной системы, чтобы спать спокойнее - ведь не бывает идеальных программ, и всегда найдется уязвимость, которую решит использовать злобный взломщик или просто скучающий script kiddie с новым эксплоитом. Ситуация с множеством сервисов на одной Linux-машине чрезвычайно распространена в небольших сетях - там сервер, изначально задумывавшийся как просто пограничный маршрутизатор локальной сети, постепенно обрастает функциями - на него свешивают почту, веб-сервер, базу данных, FTP-сервер, файловый сервер - благо, при небольшой нагрузке это все благополучно может работать на одной-единственной железке скромной конфигурации...

Если сервис, работающий в CE, окажется скомпрометированным, это принесет в общем случае вам меньше проблем, чем, если бы все происходило в рамках основной файловой системы. Если вы не беспокоитесь о безопасности и не являетесь системным администратором, которому дороги его подшефные сервера, то эта статья вряд ли будет вам интересна. Однако, согласно классической фразе: "если у вас паранойя, это еще не значит, что за вами не следят"...

Кстати, некоторые сервисы изначально подразумевают запуск в CE - например, распространенный DNS-сервер BIND создатели рекомендуют эксплуатировать в CE (создание окружения для нормальной работы этого сервиса подробно описано в официальной документации на BIND), при этом сам демон совершает системный вызов chroot(), если ему указать в качестве аргумента расположение корневого каталога CE. Аналогичная ситуация с MySQL - в конфигурационном файле указывается расположение подготовленного окружения для сервиса, демон при запуске помимо смены UID/GID, также вызывает chroot(). Те сервисы, в которых не предусмотрена работа в CE "из коробки", можно запускать с помощью уже упоминавшейся утилиты chroot.



Содержание раздела