[devel] [sisyphus] приключения resolv.conf в ALT

[Vladimir D. Seleznev]

On Fri, Apr 03, 2020 at 07:53:20PM +0300, Andrey Savchenko wrote:
> On Fri, 3 Apr 2020 16:46:03 +0300 Vladimir D. Seleznev wrote:
> > On Fri, Apr 03, 2020 at 04:21:52PM +0300, Denis Medvedev wrote:
> > > 03.04.2020 16:10, Dmitry V. Levin пишет:
> > > > On Fri, Apr 03, 2020 at 03:56:04PM +0300, Andrey Savchenko wrote:
> > > >> On Fri, 3 Apr 2020 15:20:23 +0300 Dmitry V. Levin wrote:
> > > >>> On Fri, Apr 03, 2020 at 01:51:51PM +0300, Denis Medvedev wrote:
> > > >>>> 03.04.2020 13:50, Vladimir D. Seleznev пишет:
> > > >>>>> On Fri, Apr 03, 2020 at 01:37:41PM +0300, Vladimir D. Seleznev wrote:
> > > >>>>>> On Fri, Apr 03, 2020 at 01:32:38PM +0300, Denis Medvedev wrote:
> > > >>>>>>> 03.04.2020 13:28, Vladimir D. Seleznev пишет:
> > > >>>>>>>> On Tue, Mar 31, 2020 at 10:05:17PM +0300, Alexey Shabalin wrote:
> > > >>>>>>>>>> PS: следующим письмом попробую подробно описать наши кувыркания с resolv.conf.
> > > >>>>>>>>>> дождитесь его, прежде чем отвечать :)
> > > >>>>>>>>> 5) update_chrooted.
> > > >>>>>>>>> Наши замечательные ALT особенности :)
> > > >>>>>>>>> Множество сервисов и отдельных программ(например ping) запускаются в chroot.
> > > >>>>>>>>> В этот chroot должны быть скопированы и библиотеки, и настройки для
> > > >>>>>>>>> этих библиотек, в частности resolv.conf.
> > > >>>>>>>>> Т.е. ping не использует /etc/resolv.conf, а использует
> > > >>>>>>>>> /var/resolv/etc/resolv.conf.
> > > >>>>>>>>> Нам очень важно держать в chroot'ах resolv.conf синхронным c с
> > > >>>>>>>>> основной системой.
> > > >>>>>>>>> Вроде все утилиты, обновляющие /etc/resolv.conf обучены вызывать
> > > >>>>>>>>> update_chrooted.
> > > >>>>>>>> Может быть стоит написать некий update_chrootd, который следил бы за
> > > >>>>>>>> всеми файлами, которые должны быть в чруте, и при их обновлении обновлял
> > > >>>>>>>> бы чрут? rpm -qf *
> > > >>>>>>>> файл /var/lib/ldap/usr/lib/libcom_err.so.2 не принадлежит ни одному из пакетов
> > > >>>>>>>> файл /var/lib/ldap/usr/lib/libdb-4.7.so не принадлежит ни одному из пакетов
> > > >>>>>>>> файл /var/lib/ldap/usr/lib/libgssapi_krb5.so.2 не принадлежит ни одному из пакетов
> > > >>>>>>>> файл /var/lib/ldap/usr/lib/libk5crypto.so.3 не принадлежит ни одному из пакетов
> > > >>>>>>>> файл /var/lib/ldap/usr/lib/libkeyutils.so.1 не принадлежит ни одному из пакетов
> > > >>>>>>>> файл /var/lib/ldap/usr/lib/libkrb5.so.3 не принадлежит ни одному из пакетов
> > > >>>>>>>> файл /var/lib/ldap/usr/lib/libkrb5support.so.0 не принадлежит ни одному из пакетов
> > > >>>>>>>> файл /var/lib/ldap/usr/lib/libm.so.6 не принадлежит ни одному из пакетов
> > > >>>>>>>> файл /var/lib/ldap/usr/lib/libodbc.so.2 не принадлежит ни одному из пакетов
> > > >>>>>>>> файл /var/lib/ldap/usr/lib/libpcre.so.3 не принадлежит ни одному из пакетов
> > > >>>>>>>> файл /var/lib/ldap/usr/lib/libperl-5.28.so не принадлежит ни одному из пакетов
> > > >>>>>>>> файл /var/lib/ldap/usr/lib/libselinux.so.1 не принадлежит ни одному из пакетов
> > > >>>>>>>> openldap-servers-2.4.48-alt3.x86_64
> > > >>>>>>>> openldap-servers-2.4.48-alt3.x86_64
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>> Делать inotify на список файлов относящимся к chroot и по событию
> > > >>>>>>> изменения делать update_chroot?
> > > >>>>>> Да.
> > > >>>>> Нет, при текущей архитектуре update_chrooted предложенное мной решение
> > > >>>>> невозможно. Для него надо с нуля придумывать всё решение. И если для
> > > >>>>> postfix'а нельзя декларативно указать все его конфиги, то боюсь в общем
> > > >>>>> случае это будет невозможно.
> > > >>>>>
> > > >>>> Хотелось бы прописать политику о том, что любой пакет, желающий
> > > >>>> использовать chroot, должен иметь возможность работать БЕЗ chroot.
> > > 
> > > Наличие чрута приводит к вот такой ситуации:
> > > 
> > >   rpm -qf *
> > > файл /var/lib/ldap/usr/lib/libcom_err.so.2 не принадлежит ни одному из 
> > > пакетов
> > > файл /var/lib/ldap/usr/lib/libdb-4.7.so не принадлежит ни одному из пакетов
> > > файл /var/lib/ldap/usr/lib/libgssapi_krb5.so.2 не принадлежит ни одному 
> > > из пакетов
> > > файл /var/lib/ldap/usr/lib/libk5crypto.so.3 не принадлежит ни одному из 
> > > пакетов
> > > файл /var/lib/ldap/usr/lib/libkeyutils.so.1 не принадлежит ни одному из 
> > > пакетов
> > > файл /var/lib/ldap/usr/lib/libkrb5.so.3 не принадлежит ни одному из пакетов
> > > файл /var/lib/ldap/usr/lib/libkrb5support.so.0 не принадлежит ни одному 
> > > из пакетов
> > > файл /var/lib/ldap/usr/lib/libm.so.6 не принадлежит ни одному из пакетов
> > > файл /var/lib/ldap/usr/lib/libodbc.so.2 не принадлежит ни одному из пакетов
> > > файл /var/lib/ldap/usr/lib/libpcre.so.3 не принадлежит ни одному из пакетов
> > > файл /var/lib/ldap/usr/lib/libperl-5.28.so не принадлежит ни одному из 
> > > пакетов
> > > файл /var/lib/ldap/usr/lib/libselinux.so.1 не принадлежит ни одному из 
> > > пакетов
> > > openldap-servers-2.4.48-alt3.x86_64
> > > openldap-servers-2.4.48-alt3.x86_64
> > > 
> > > И как мне правильно проверять целостность таких файлов относительно базы 
> > > rpm? Это  файлы с исполняемым кодом.
> > 
> > Из-за отсутствия инструмента для такой проверки предлагается отказаться
> > от security feature? Это странное решение.
> 
> Chroot не является security feature:
> 
> It is not hard to consider the chroot() system call a security
> feature. In theory, it sounds great, but if you really take the
> time to understand what is going on, it is not really a security
> feature, it is closer to what we would call a hardening feature.
> 
> https://access.redhat.com/blogs/766093/posts/1975883

Хорошо, назовём её по своему классу: hardening feature.

> У этой технологии, безусловно, есть свои применения, но если вы
> строите системы безопасности на основе chroot, то это всего лишь
> иллюзия безопасности.

Я не знаю откуда возникло мнение, что кто-то строит системы безопасности
на основе chroot.

> > Правильнее было бы сделать
> > такой инструмент. Из того, что сходу приходит на ум, можно в chroot dir
> > создавать базу данных rpm и копировать туда записи пакетов из исходной
> > базы при обновлении чрута по признаку принадлежности пакета по
> > копируемым путям.
> 
> Правильным было бы использовать инструменты по их назначению.

Правильно иметь инструмент для решения задачи или создание такового при
его отсутствии.

-- 
   WBR,
   Vladimir D. Seleznev