Vesselin Kolev wrote:
Благодаря за информацията. С Debian работя от 3-4 години и съм свикнал с него.Tsvetin Vasilev wrote:
Бтв съществува ... но дали съществува в chroot обвивката ? ;-)Защо си мисля, че не си чел внимателно "BIND9 Configuration Reference"....
Ако отговорът е не има две възможности или да ги направиш най-просто с mkdir
или да използваш mount -o bind
Та там хората са го написали хипер ясно:
*** *pid-file*
The pathname of the file the server writes its process ID in. If not specified, the default is /var/run/named.pid. The pid-file is used by programs that want to send signals to the running name server. Specifying *pid-file none* disables the use of a PID file — no file will be written and any existing one will be removed. Note that *none* is a keyword, not a file name, and therefore is not enclosed in double quotes.
***
Тази декларация се подава в структурата options на конфигурационния файл named.conf. Тя може да отмени компилационно зададения път до pid файла.
Какво значи това в контекста на chroot? Това значи, че ако в named.conf се направи декларация от вида:
options { ... pid-file "/var/run/bind/run/named.pid"; ... };
то ако chroot директорията е /var/named/chroot, то pid файла ще е /var/named/chroot/var/run/bind/run/named.pid. Т.е. правиш в chroot директорията следното:
# cd /var/named/chroot # mkdir -p var/run/bind/run
после правиш създадената с втория ред писаема за потребителя, с чиито права се изпълняват процесите на демона named.
Аз бях силно потресен от това, което видях в първото писмо, дало началото на нишката "Bind в chroot". В един от редовете от syslog журнала съзрях следния ужас:
Mar 18 09:35:26 localhost named[11017]: starting BIND 9.2.5 -u nobody -t /var/lib/named
Процесите на демона named се пускат със собственик потребителя nobody, който почти сигурно се ползва за какво ли още не. Ако утре се пусне демон с правата на nobody и той бъде пробит, какво ли ще се случи при добро желание от страна на атакуващия с процесите на named, чиито процеси също са собственост на потребителя nobody? Например, как ви звучи "обезобразяване на зонален файл":) apt-get не прави запис за нов потребител, с който да се пуска named. Но поне го направете ръчно за да няма проблеми. Ето пример за такъв потребител:
Можете да се сърдите, но Debian не предоставя възможностите нужни за работа в chroot среда на демона named. Изобщо в тази дистрибуция малко са скарани с темата "сигурност" (особено след като вчера след apt-get install ntp-server разбрах, че ntpd се пуска с права на root :), което ме разтрепера и накара да преправям init скрипта, защото в този init скрипт нямаше дори предвидено четене на /etc/defaults/ntp-server, от където евентуално да се зададе кой да е собственик на процесите, за опционлано заключване изобщо не може и да се говори).
Конкретно за bind:
1) в /etc/init.d/bind9 липсва каквато и да е мобилност и оперативност за заключване на демона named
конкретно:
- start () {
echo -n "Starting domain name service: named"
if [ ! -x /usr/sbin/named ]; then
echo "named binary missing - not starting"
exit 1
fi
start-stop-daemon --start --quiet \
--pidfile /var/run/named.pid --exec /usr/sbin/named -- $OPTIONS
echo "."
Прекрасно, но тук се обвързваш с pid файл, който не е в chroot, дори в $OPTIONS да имаш указване за chroot директория с "-t".
- stop () {
echo -n "Stopping domain name service: named"
# --exec doesn't catch daemons running deleted instances of
named,
# as in an upgrade. Fortunately, --pidfile is only going to hit
# things from the pidfile.
start-stop-daemon --stop --quiet \
--pidfile /var/run/named.pid --name named
echo "."
}
Отново това обвързване. Да не говорим, че ISC пишат в документацията си, но кой да чете. Демонът named се спира с командата:
# rndc stop
Ето как изглежда stop функцията в bash скрипт в друга дистрибуция (където няма проблеми с chroot пускането на named):
stop() { # Stop daemons. echo -n $"Stopping $prog: " /usr/sbin/rndc stop >/dev/null 2>&1 RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named || { # killproc named # Never do this! Can cause corrupt zone files! /usr/sbin/rndc stop >/dev/null 2>&1 RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named echo return $RETVAL } success echo return $RETVAL }
Никакви обвързвания с pid и оттам никакви проблеми с chroot. Няма проблеми със спирането. Може дори да не се използва pid файл. Поздрави Весо
Но от определено време се замислям за FC3. Понатрупах малко стаж с тази дистрибуция
на домашния компютър и се замислям дали на не опитам да направя този сървър с нея.
И без това е все още във вътрешната мрежа и не е готов за работа.
Явор Атанасов ============================================================================ A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers). http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html ============================================================================
