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

[Alexey Shabalin <a.shabalin@gmail.com>]

чт, 8 нояб. 2018 г. в 22:22, Andrey Savchenko <bircoph@altlinux.org>:
>
> 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 класть (в таком случае файлик нужно
> переложить в другое место).

Пакет startup с измененным местоположением (на
/var/lib/random/random-seed) ждёт апрува.

-- 
Alexey Shabalin