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

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

[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, который следил бы за
всеми файлами, которые должны быть в чруте, и при их обновлении обновлял
бы чрут?

-- 
   WBR,
   Vladimir D. Seleznev

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

[Denis Medvedev]

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, который следил бы за
> всеми файлами, которые должны быть в чруте, и при их обновлении обновлял
> бы чрут?
>
Делать inotify на список файлов относящимся к chroot и по событию 
изменения делать update_chroot?

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

[Alexey V. Vissarionov]

On 2020-04-03 13:28:27 +0300, Vladimir D. Seleznev wrote:

 >> Вроде все утилиты, обновляющие /etc/resolv.conf обучены вызывать
 >> update_chrooted.
 > Может быть стоит написать некий update_chrootd, который следил бы
 > за всеми файлами, которые должны быть в чруте, и при их обновлении
 > обновлял бы чрут?

Не надо! Максимум - свой для каждого процесса, и чтобы его можно было
не ставить.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

[Vladimir D. Seleznev]

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, который следил бы за
> > всеми файлами, которые должны быть в чруте, и при их обновлении обновлял
> > бы чрут?
> >
> Делать inotify на список файлов относящимся к chroot и по событию 
> изменения делать update_chroot?

Да.

-- 
   WBR,
   Vladimir D. Seleznev

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

[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, который следил бы за
> > > всеми файлами, которые должны быть в чруте, и при их обновлении обновлял
> > > бы чрут?
> > >
> > Делать inotify на список файлов относящимся к chroot и по событию 
> > изменения делать update_chroot?
> 
> Да.

Нет, при текущей архитектуре update_chrooted предложенное мной решение
невозможно. Для него надо с нуля придумывать всё решение. И если для
postfix'а нельзя декларативно указать все его конфиги, то боюсь в общем
случае это будет невозможно.

-- 
   WBR,
   Vladimir D. Seleznev

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

[Denis Medvedev]

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, который следил бы за
>>>> всеми файлами, которые должны быть в чруте, и при их обновлении обновлял
>>>> бы чрут?
>>>>
>>> Делать inotify на список файлов относящимся к chroot и по событию
>>> изменения делать update_chroot?
>> Да.
> Нет, при текущей архитектуре update_chrooted предложенное мной решение
> невозможно. Для него надо с нуля придумывать всё решение. И если для
> postfix'а нельзя декларативно указать все его конфиги, то боюсь в общем
> случае это будет невозможно.
>
Хотелось бы прописать политику о том, что любой пакет, желающий 
использовать chroot, должен иметь возможность работать БЕЗ chroot.

(легкую отключаемость этой IMHO mis-feature).

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

[Dmitry V. Levin]

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, который следил бы за
> >>>> всеми файлами, которые должны быть в чруте, и при их обновлении обновлял
> >>>> бы чрут?
> >>>>
> >>> Делать inotify на список файлов относящимся к chroot и по событию
> >>> изменения делать update_chroot?
> >> Да.
> > Нет, при текущей архитектуре update_chrooted предложенное мной решение
> > невозможно. Для него надо с нуля придумывать всё решение. И если для
> > postfix'а нельзя декларативно указать все его конфиги, то боюсь в общем
> > случае это будет невозможно.
> >
> Хотелось бы прописать политику о том, что любой пакет, желающий 
> использовать chroot, должен иметь возможность работать БЕЗ chroot.

Нет, хотелось бы обратного, чтобы всякий желающий оторвать чрут
получал бы по рукам.


-- 
ldv

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

[Denis Medvedev]

03.04.2020 15:20, Dmitry V. Levin пишет:
> 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, который следил бы за
>>>>>> всеми файлами, которые должны быть в чруте, и при их обновлении обновлял
>>>>>> бы чрут?
>>>>>>
>>>>> Делать inotify на список файлов относящимся к chroot и по событию
>>>>> изменения делать update_chroot?
>>>> Да.
>>> Нет, при текущей архитектуре update_chrooted предложенное мной решение
>>> невозможно. Для него надо с нуля придумывать всё решение. И если для
>>> postfix'а нельзя декларативно указать все его конфиги, то боюсь в общем
>>> случае это будет невозможно.
>>>
>> Хотелось бы прописать политику о том, что любой пакет, желающий
>> использовать chroot, должен иметь возможность работать БЕЗ chroot.
> Нет, хотелось бы обратного, чтобы всякий желающий оторвать чрут
> получал бы по рукам.
>
>
Может тогда убрать вообще конфиги для chroot сервисов  из главного /etc 
чтобы они не путали людей и не вносили некогерентность?

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

[Alexey V. Vissarionov]

On 2020-04-03 15:20:23 +0300, Dmitry V. Levin wrote:

 >> Хотелось бы прописать политику о том, что любой пакет, желающий
 >> использовать chroot, должен иметь возможность работать БЕЗ chroot.
 > Нет, хотелось бы обратного, чтобы всякий желающий оторвать чрут
 > получал бы по рукам.

... и ставил шляпу или дебилиан?

Система должна быть гибкой в настройке. То есть, уметь в точности
повторять форму рук администратора.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3695 bytes --]

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, который следил бы за
> > >>>> всеми файлами, которые должны быть в чруте, и при их обновлении обновлял
> > >>>> бы чрут?
> > >>>>
> > >>> Делать inotify на список файлов относящимся к chroot и по событию
> > >>> изменения делать update_chroot?
> > >> Да.
> > > Нет, при текущей архитектуре update_chrooted предложенное мной решение
> > > невозможно. Для него надо с нуля придумывать всё решение. И если для
> > > postfix'а нельзя декларативно указать все его конфиги, то боюсь в общем
> > > случае это будет невозможно.
> > >
> > Хотелось бы прописать политику о том, что любой пакет, желающий 
> > использовать chroot, должен иметь возможность работать БЕЗ chroot.
> 
> Нет, хотелось бы обратного, чтобы всякий желающий оторвать чрут
> получал бы по рукам.

А чем поясняется такое стойкое желание использовать chroot? Выход
из него абсолютно тривиален при наличии прав рута и сложнее при
отсутствии, но всё же осуществим через то же локальное поднятие
привилегий.

Если действительно важна изоляция сервисов с точки зрения
безопасности, почему бы не использовать LXC? Да, этот механизм тоже
не идеален, но он предоставляет намного больше защиты, чем простой
chroot.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[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, который следил бы за
> > > >>>> всеми файлами, которые должны быть в чруте, и при их обновлении обновлял
> > > >>>> бы чрут?
> > > >>>>
> > > >>> Делать inotify на список файлов относящимся к chroot и по событию
> > > >>> изменения делать update_chroot?
> > > >> Да.
> > > > Нет, при текущей архитектуре update_chrooted предложенное мной решение
> > > > невозможно. Для него надо с нуля придумывать всё решение. И если для
> > > > postfix'а нельзя декларативно указать все его конфиги, то боюсь в общем
> > > > случае это будет невозможно.
> > > >
> > > Хотелось бы прописать политику о том, что любой пакет, желающий 
> > > использовать chroot, должен иметь возможность работать БЕЗ chroot.
> > 
> > Нет, хотелось бы обратного, чтобы всякий желающий оторвать чрут
> > получал бы по рукам.
> 
> А чем поясняется такое стойкое желание использовать chroot?

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

> Выход из него абсолютно тривиален при наличии прав рута

Никто в здравом уме не использует чрут таким образом.

> и сложнее при
> отсутствии, но всё же осуществим через то же локальное поднятие
> привилегий.

Если есть уязвимости в ядре, их надо устранять, а не запускать всё от рута.

> Если действительно важна изоляция сервисов с точки зрения
> безопасности, почему бы не использовать LXC? Да, этот механизм тоже
> не идеален, но он предоставляет намного больше защиты, чем простой
> chroot.

Под LXC обычно понимают контейнеризацию, а не unshare, это другое.


-- 
ldv

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

[Denis Medvedev]

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? Это  файлы с исполняемым кодом.

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

[Dmitry V. Levin]

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? Это  файлы с исполняемым кодом.

Вы как будто предлагаете лечить насморк методом декапитации?


-- 
ldv

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

[Vladimir D. Seleznev]

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 dir
создавать базу данных rpm и копировать туда записи пакетов из исходной
базы при обновлении чрута по признаку принадлежности пакета по
копируемым путям.

Возвращаясь к вопросу демона отслеживания изменений файлов: ldv@:
возможно ограничиться только остлеживанием файлов /etc/resolv.conf и
/etc/hosts и в случае их изменений выполнять update_chrooted conf?

-- 
   WBR,
   Vladimir D. Seleznev

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

[Alexey V. Vissarionov]

On 2020-04-03 16:28:18 +0300, Dmitry V. Levin wrote:

 >> Наличие чрута приводит к вот такой ситуации:
 >> rpm -qf *
 >> файл /var/lib/ldap/usr/lib/libcom_err.so.2 не принадлежит ни
 >> одному из пакетов
 >> [...]
 >> И как мне правильно проверять целостность таких файлов
 >> относительно базы rpm? Это файлы с исполняемым кодом.
 > Вы как будто предлагаете лечить насморк методом декапитации?

Ну вообще-то это старый и надежный способ борьбы с эпидемиями...

Подумай, как это выглядит с кочки зрения админа: в системе хрен
пойми откуда (в обход пакетной системы) появляются исполняемые
файлы. Уже этого факта достаточно для того, чтобы разработчиков
не то что декапитации, а массовым расстрелам подвергнуть. И нас
в этой ситуации спасает ровно одно: админы - люди ленивые.

Вот если создавать каталог для chroot() в tmpfs непосредственно
при запуске процесса, а после остановки нещадно его уничтожать
(в том числе при перезапуске) - может быть, и не расстреляют, а
просто морду набьют. Потому что все равно фу.

Думаю, каталоги наподобие /run/chroot/${daemon_name} для этого
вполне подойдут.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 8124 bytes --]

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

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

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

Правильным было бы использовать инструменты по их назначению.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [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