Linux-Bulgaria.ORG
навигация

 

начало

пощенски списък

архив на групата

семинари ...

документи

как да ...

 

 

Предишно писмо Следващо писмо Предишно по тема Следващо по тема По Дата По тема (thread)

Re: lug-bg: Bind в chroot


  • Subject: Re: lug-bg: Bind в chroot
  • From: Vesselin Kolev <vlk@xxxxxxxxxxxxxxxxx>
  • Date: Fri, 18 Mar 2005 12:36:51 +0200

Tsvetin Vasilev wrote:

Бтв съществува ... но дали съществува в chroot обвивката ? ;-)
Ако отговорът е не има две възможности или да ги направиш най-просто с mkdir
или да използваш mount -o bind


Защо си мисля, че не си чел внимателно "BIND9 Configuration Reference"....

Та там хората са го написали хипер ясно:

***
*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 файл.
     Поздрави
   Весо











============================================================================
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
============================================================================



 

наши приятели

 

линукс за българи
http://linux-bg.org

FSA-BG
http://fsa-bg.org

OpenFest
http://openfest.org

FreeBSD BG
http://bg-freebsd.org

KDE-BG
http://kde.fsa-bg.org/

Gnome-BG
http://gnome.cult.bg/

проект OpenFMI
http://openfmi.net

NetField Forum
http://netField.ludost.net/forum/

 

 

Linux-Bulgaria.ORG

Mailing list messages are © Copyright their authors.