[devel] Q: trustworhtiness of chrony

[Dmitry V. Levin]

On Tue, Aug 14, 2018 at 02:31:14PM +0300, Andrey Savchenko wrote:
> On Mon, 13 Aug 2018 15:32:43 +0300 Dmitry V. Levin wrote:
> > On Mon, Aug 13, 2018 at 03:25:33PM +0300, Andrey Savchenko wrote:
> > > On Mon, 13 Aug 2018 14:59:04 +0300 Dmitry V. Levin wrote:
> > > > On Mon, Aug 13, 2018 at 02:52:13PM +0300, Yuri Sedunov wrote:
> > > > > У кого-то часы отстают?
> > > > > 
> > > > > ...
> > > > > check OK
> > > > > 2018-Aug-13 11:27:30 :: [x86_64-i586] plan: #4 +4 -4 =11420
> > > > > arepo/x86_64-i586/rpms/i586-libappstream-glib-devel-0.7.12-alt1.i586.rpm: BUILDTIME in the future: Mon Aug 13 11:28:15 UTC 2018
> > > > > sisyphus_check: check-buildtime ERROR: buildtime violation
> > > > > arepo/x86_64-i586/rpms/i586-libappstream-glib-0.7.12-alt1.i586.rpm: BUILDTIME in the future: Mon Aug 13 11:28:13 UTC 2018
> > > > > sisyphus_check: check-buildtime ERROR: buildtime violation
> > > > > 2018-Aug-13 11:28:13 :: [x86_64-i586] sisyphus_check FAILED
> > > > > 2018-Aug-13 11:28:13 :: [x86_64-i586] build FAILED
> > > > > 2018-Aug-13 11:28:13 :: task #211319 for sisyphus FAILED
> > > > 
> > > > Да, один из сборочных узлов опять заресетился, время на нём сбилось,
> > > > ntpd подправляет его каждые несколько минут на несколько секунд,
> > > > процесс сходящийся.
> > > 
> > > А можно поставить chrony и плавно поправить через tike skew без
> > > всяких скачков и прочего безобразия. Мало того, при запуске он сам
> > > умеет использовать поправку на вычисленную на основе собранных
> > > ранее данных систематическую погрешность системных часов. На
> > 
> > Кто-нибудь читал исходный код chrony,
> > что этот исходный код представляет из себя по сравнению с openntpd,
> > им вообще можно пользоваться там, где нужно минимизировать риск
> > исполнения произвольного кода?
> 
> Для минимизации рисков в chrony предусмотрено использование
> seccomp. Не знаю, есть ли в openntpd такая функциональность.

В openntpd реализован privsep.  Та версия openntpd, которая в Сизифе,
старше seccomp.  Вообще seccomp без privsep это маркетинг и грабли.

> У chrony предусмотрено более десятка опций конфигурации, так что
> можно собрать chrony-minimal, если очень хочется.

Кому-то придётся в это посмотреть.

> Что касается аудита кода. Чем конкретно вызвана эта необходимость?

Жизненными принципами. :)

> chrony можно настроить для использования внутреннего ntp-сервера,
> так что внешних векторов атаки не будет.

Это будет сделано в любом случае.

> Безусловно, анализ кода —
> это хорошо, но тогда нужно анализировать все потенциально уязвимые
> компоненты системы, т.к. нет смысла в одной безопасной при двух
> опасных. 

С одной стороны, принято считать, что безопасность системы не превосходит
безопасности самого слабого звена.

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

> Поэтому меня интересует: выполнялся ли аудит кода ядра и openssl,
> которые применяются на нашей сборочнице? Если да, то где он?

На сборочнице используется openssh, который в конфигурации, используемой
на сборочнице, почти не использует openssl.

Общеизвестно, что самым слабым звеном операционной системы, используемой
на сборочнице, является ядро.  Даже при том, что на сборочнице
используемое подмножество ядра ограничено.

> Сообществу будет очень интересно. Если нет, то зачем тогда особо
> придираться к серверу времени?

Чтобы сервер времени не создавал дополнительных угроз.

> Следующий вопрос: зачем вообще наша сборочница настолько придирчива
> к времени сборки, что сборка на 1 секунду в будущем приводит
> к провалу всего процесса сборки пакета?

Время должно быть синхронно.  Я не хочу думать о том, какими
неприятностями в данном случае грозит рассинхронизация времени,
поскольку время просто должно быть синхронно.


-- 
ldv