From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 14 Aug 2018 15:12:11 +0300 From: "Dmitry V. Levin" To: ALT Devel discussion list Message-ID: <20180814121211.GA4879@altlinux.org> Mail-Followup-To: ALT Devel discussion list References: <20180813112813.GA25532@gyle.altlinux.org> <20180813115904.GC19699@altlinux.org> <20180813152533.f5fc9b8a379dbe396f9e6845@altlinux.org> <20180813123243.GA20495@altlinux.org> <20180814143114.365690229320119998d2889d@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180814143114.365690229320119998d2889d@altlinux.org> Subject: Re: [devel] Q: trustworhtiness of chrony X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 12:12:11 -0000 Archived-At: List-Archive: List-Post: 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