Версия 1.0.1, 19 юни 2008
Веселин Колев, Софийски Университет "Св. Климент Охридски"
Адрес за кореспонденция: vesso AT vesselin.org
Първоизточник: http://www.vesselin.org
Лиценз на документа: CC Attribution-ShareAlike
Съдържание:
Има различни описани техники, чрез които да се заставят процесите на Sendmail в локалната система, да използват правата на непривилигерован потребител. Повечето от тях са сложни за реализиране от страна дори на системни администратори с опит, а най-лошото е, че често влизат в противоречие с актуализациите на пакета sendmail, който идват от дистрибутивното хранилище. Целта на тази статия е да покаже начин на стартиране на процесите на Sendmail с права на непривилигерован потребител, който да е максимално съвместим с логиката на актуализация на пакетите в една Linux дистрибуция. Основният фокус е върху Red Hat Enterprise Linux и производните му (CentOS, Scientific Linux и др).
Най-често се препоръчва схема на стартирането на sendmail демона в chroot. След това в конфигурационния файл sendmail.cf (който също е в chroot средата), се указва потребител и група, с чиито права ще се изпълняват процесите на Sendmail. Тази схема е напълно ненужна при наличието на SELinux. Нещо повече, тази схема е дори опасна, защото при нея се налага в chroot средата да се копират библиотеки от пакета glibc. В даден момент от живота на системата може да се получи ситуация, при която в chroot средата има файлове от старата версия на пакета glibc, който са потенциално опасни, а в системната среда има по-нова, актуализирана версия на glibc (същото касае и файловете от пакета sendmail). Това може да открие пътя за злонамерено използване на тази разлика във версиите. От друга страна няма еднозначно решение как при пакетно обновяване да се "изравни" chroot средата със системната, от гледна точка на библиотеки, изпълними файлове, конфигурационни и директорийни промени и др.
Вторият тип схема, при която процесите на Sendmail се изпълняват с права на непривилигерован потребител, включва промяна на правата върху директорията /var/spool/mqueue (писане и четене за непривилигерования потребител) и промяна на правата върху конфигуационните файлове (писане и четене за непривилигерования потребител). Обикновено конфигурационните файлове на Sendmail в Red Hat Enterprise Linux се намират в директория /etc/mail. След това в конфигурационния файла sendmail.cf се указва потребителя и групата, с чиито права ще се изпълняват процесите на Sendmail. Това е достатъчно за използване на схемата.
Втората схема обаче, влиза в тотално противоречие с пакетната система. RPM пакетите за Sendmail са направени така, че задават права върху служебните файлове и директории на демона sendmail. Дори администраторът да смени тези права в полза на непривилигерования потребител върху локалната система, след пакетна актуализация на Sendmail, ще се възстановят оригиналните права върху служебните файлове и директории (разбира се, няма да се промени sendmail.cf), което означава, че процесите на демона, които се изпълняват с права на непривилигерован потребител няма повече да могат да пишат и четат на и от съответното място на файловата система, което пък ще провали услугата.
Логиката на изграждане на решение, при което използването на непривилигерован потребител за собственик на процесите на демона sendmail не влиза в противоречие с пакетната система, изисква създаването на паралелна структура от конфигурационни файлове и служебни директории, които да не са създадени и не се актуализират от пакета sendmail. Трябва да се направи така, че от пакета sendmail да се използва само изпълнимото приложение и конфигуртационния файл sendmail.cf. Пакетната система RPM маркира определени файлове като конфигурационни и не ги подменя при актуализация на пакетната версия. Такива са файловете в директория /etc/mail. За нуждите на решението, от тази директория ще се използват само файловете sendmail.mc и sendmail.cf. В тях се изгражда такава стартова конфигурация, която да указва на демона sendmail да чете и пише върху файлове и директории, които не са ангажирани с актуализация от страна на пакетната система.
При изграждането на решението трябва да се следва принципа за минималната системна промяна така, че да не се затрудни администриращия персонал при работа с новото решение. Т.е. целта е всеки системен оператор, който знае как се поддържа Sendmail базиран пощенски MTA сървър, базиран на оригиналните RPM пакети, да може да се научи да работи с новото решение с минимална загуба на време и усилия (което пък гарантира стабилност на услугата).
Най-лесният начин е да се създаде директория, аналог на кореновата директория и в нея да се създадат всички служебни директории и файлове, нужни за работата на Sendmail. В примерът по-долу е използвана директория /home/sendmail, но този избор не е задължителен и може да се използва произволен друг, избран от инженера по внедряване на решението.
Предварителна стъпка, преди изграждане на решението е избор на непривилигерован потребител, с чиито права да се изпълняват процесите на демона sendmail. Един възможен избор е да се създаде потребител sendmail по следната схема:
# useradd -g mail -d /dev/null -s /sbin/nologin -c "Sendmail Daemon User" sendmail
В директорията /home/sendmail се създава следната директорийна структура (в скоби са посочени правата за достъп, собственик и група):
/home/sendmail/ (755,root:root) etc/ (755,sendmail:mail) etc/mail/ (755,root:root) var/ (755,root:root) var/spool/ (755,root:root) var/spool/mqueue/ (700,sendmail:mail)
Следва копирането на файловете, от които демона на sendmail чете настройките. Това означава, че трябва да се копират следните файлове (в скобите са указани правата за достъп, собственика и групата, които трябва да има файла след копирането си):
/etc/aliases -> /home/sendmail/etc/aliases (644,sendmail:mail) /etc/mail/access -> /home/sendmail/etc/mail/access (644,root:root) /etc/mail/domaintable -> /home/sendmail/etc/mail/domaintable (644,root:root) /etc/mail/mailertable -> /home/sendmail/etc/mail/mailertable (644,root:root) /etc/mail/virtusertable -> /home/sendmail/etc/mail/virtusertable (644,root:root)
Следващата стъпка е указването на промените в макросния прототип /etc/mail/sendmail.mc:
define(`confTRUSTED_USER', `sendmail')dnl define(`confRUN_AS_USER', `sendmail')dnl define(`ALIAS_FILE', `/home/sendmail/etc/aliases')dnl define(`QUEUE_DIR',`/home/sendmail/var/spool/mqueue/')dnl FEATURE(`access_db',`hash -T<TMPF> -o /home/sendmail/etc/mail/access.db')dnl FEATURE(`domaintable',`hash -o /home/sendmail/etc/mail/domaintable.db')dnl FEATURE(`mailertable',`hash -o /home/sendmail/etc/mail/mailertable.db')dnl FEATURE(`virtusertable',`hash -o /home/sendmail/etc/mail/virtusertable.db')dnl
След запазването на промените в конфигурационния файл /etc/mail/sendmail.mc, се генерира нова версия на /etc/mail/sendmail.cf:
# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
Следва изграждане на базата с псевдоними:
# newaliases
Горната команда ще изгради файла /home/sendmail/etc/newaliases.
Накрая се генерират останалите необходими конфигурации, които процесите на демона sendmail четат по време на обработката на електронната поща:
# cd /home/sendmail/etc/mail
# for map in virtusertable access domaintable mailertable ; do /usr/bin/makemap hash ${map} < ${map} ; done
Ако демонът sendmail по време на тези операции е бил в режим на работа и е обслужвал задачи, той трябва да бъде спрян:
# service sendmail stop
и да се изчака всички негови дъщерни процеси да спрат обработката на задачи (прави се преглед на текущите процеси в системата). След това всички останали в директорията /var/spool/mqueue писма, трябва да се преместят в /home/sendmail/var/spool/mqueue:
# mv /var/spool/mqueue/* /home/sendmail/var/spool/mqueue # chown -R sendmail:mail /home/sendmail/var/spool/mqueue/*
и демонът sendmail може да се стартира отново:
# service sendmail start
Тази схема не може да бъде прилагана, когато за доставка на писмата до кутиите се използва procmail. В този случай procmail изисква неговия процес да бъде инициран от процес на sendmail с ефективни права на root, за да може да се установят правата на съответния потребител върху поставеното в кутията му писмо. Във всички други случаи, когато MDA услугата работи като демон (например при използване на cyrus-imapd), няма значение с правата на какъв потребител се изпълнява процесите на Sendmail, защото в този случай доставката се извършва по начин, който не изисква ефективни права на root.
Версия 1.0: [tar.gz] [електронен подпис върху архива]
Публикувана на: 7 ноември 2007г.
Този документ е с OpenPGP подписано съдържание
[информация] [електронен подпис][TimeStamp]