[devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

On Thu, 8 Nov 2018 18:58:34 +0300 Andrey Savchenko wrote:
> On Thu, 8 Nov 2018 01:19:27 +0300 Leonid Krivoshein wrote:
> > 
> > 07.11.2018 22:41, Paul Wolneykien пишет:
> > > 07.11.2018 21:38, Leonid Krivoshein пишет:
> > >> 4. надо находить и устранять причины раннего опустошения энтропии,
> > >> приводящие к блокировкам.
> > >    Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
> > > железе, поскольку для загрузки внезапно понадобились случайные числа?
> > 
> > Пока что поймать железо (в отладочных целях), где подобное проявляется 
> > именно с дистрибутивами Альт, нам удалось лишь единожды. По ссылкам из 
> > этого обсуждения видно, что проблема есть на новых ядрах в других 
> > дистрибутивах, так что может быть до нас просто ещё эхо не докатилось. И 
> > видно, что глобального решения пока не предложено. Частным порядком все 
> > обходятся вкорячиванием haveged/rngd, но как мы уже определились, этого 
> > делать не надо. Раз так, мы должны предложить альтернативу, и что-то 
> > подсказывает, что RND-ключик, как у Алексея, в качестве такой 
> > альтернативы подойдёт далеко не всем. И не просто предложить, а сделать 
> > автоматически применяемым в дистрибутивах решением, чтобы не было 
> > блокировок на старте, даже в очень редких случаях.
> > 
> > Однако тема имеет много практических целей. Одной уже достигли, 
> > определившись с haveged и rngd. Предлагаю ещё вспомнить назначение файла 
> > и одноимённой службы: 
> > https://www.freedesktop.org/software/systemd/man/systemd-random-seed.html 
> > . Тут ещё выяснилось, что для улучшения безопасности systemd не просто 
> > так собирается с libgcrypt -- он может использовать случайные числа для 
> > цифровой подписи каждой записи журнала. Отсюда столько интересных 
> > патчей, связанных с FIPS, портированных в свободную FC из RHEL. Полагаю, 
> > цель на раннем старте задействовать по-возможности более кошерный 
> > getrandom(2), на случай доступности "более естественной случайности". Но 
> > вот что я сейчас вижу в сизифном логе:
> > 
> > 
> > [    5.112227] systemd[1]: systemd 239 running in system mode. (+PAM 
> > +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
> > +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN 
> > +PCRE2 default-hierarchy=hybrid)
> > [    5.124337] systemd[1]: Detected architecture x86-64.
> > [    5.223381] random: systemd: uninitialized urandom read (16 bytes read)
> > [    5.223456] systemd[1]: Listening on Journal Audit Socket.
> > [    5.223521] random: systemd: uninitialized urandom read (16 bytes read)
> > [    5.223592] systemd[1]: Listening on udev Control Socket.
> > [    5.223656] random: systemd: uninitialized urandom read (16 bytes read)
> > ...
> > [   32.283736] random: crng init done
> > [   32.283746] random: 7 urandom warning(s) missed due to ratelimiting
> > 
> > 
> > То есть, на самом раннем старте (большая часть железа здесь 
> > инициализируется за 5-й секундой!) журнал systemd уже нужен, но даже для 
> > его инициализации средствами кошерного /dev/urandom нет энтропии либо 
> > почему-то (!) он к этому времени всё ещё не проинициализирован. То есть, 
> > по логике Андрея, мы на сертифицировнных дистрах при большом желании 
> > сможем подделывать записи (подменять журнал) systemd, верно? Для 
> > гражданских-то не столь актуально. 384-бит на 5-й секунде -- не жирно так?
> 
> Суть последних изменений в ядре в том, что urandom теперь тоже
> может блокироваться, пока не набрана энтропия для первичного
> наполнения пула. Я всячески приветствую это изменение, т.к. оно
> защищает от генерации слабых ключей, на которые есть реально
> осуществляемая атака. Есть научное исследование и публикация на эту
> тему:
> https://factorable.net/paper.html
> https://factorable.net/weakkeys12.extended.pdf
> 
> В статье рассказывается как недостаточно случайные числа можно
> использовать для атаки на RSA и DSA полученные с их использованием
> и проводится общемировой анализ и статистика использования подобных
> ключей.
> 
> Советую почитать разделы 5.1 Weak entropy and the Linux RNG
> и 6.2 /dev/(u)random as a usability failure. Да, начиная с 4.17 это
> должно быть исправлено в ядрах, но сколько ещё всплывёт проблем?
> Для долгосрочных ключей пригоден только /dev/random: см. раздел 7
> Defenses and Lessons.
> 
> Да, заметь, что это научная статья со всеми надлежащими ссылками на
> литературы и рецензированием, а не рандомная публикация в инете.

Кстати, а на проблемных системах /etc/init.d/random (или
аналогичный unit-файл для systemd) стартует? По идее, он должен
дать достаточно энтропии для запуска системы (если это не загрузка
заранее подготовленного образа по сети, конечно). Ещё нужно следить
за тем, чтоб файл /var/run/random-seed существовал, а то есть
любители /var/run в tmpfs класть (в таком случае файлик нужно
переложить в другое место).

Best regards,
Andrew Savchenko
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 833 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20181108/3da77ba2/attachment.bin>