Re: linux /dev/random initialization CVE-2018-1108
Я же правильно понимаю, что и без всяких rng-tools линукс использует rdrandr? -- sergio.
Re: linux /dev/random initialization CVE-2018-1108
On Thu, Dec 20, 2018 at 11:29:02AM +0300, sergio wrote: > On 20/12/2018 11:00, Artem Chuprina wrote: > > > С WiFi как с сетевого интерфейса, конечно, снимает. > > Уровень сигнала, биконы? Или просто пакеты, уже после соединения? Уровень сигнала это очень слабо меняющаяся величина, там энтропию можно по байту в час собирать, или ещё хуже. А подавать данные в RNG совершенно недопустимо. Но вот последние биты времени прихода пакетов (где-то до 100 нс), это ещё можно как-то использовать. Снизу оно упирается в точность таймера, типично она порядка 10 нс, так что примерно байт в секунду (+/- порядок) можно набирать энтропии в типичной домовой wifi-сети. IMHO. Ну а как оно в реальности реализовано -- см. исходники ядра. -- Eugene Berdnikov
Re: linux /dev/random initialization CVE-2018-1108
sergio -> debian-russian@lists.debian.org @ Thu, 20 Dec 2018 11:29:02 +0300: >> С WiFi как с сетевого интерфейса, конечно, снимает. > Уровень сигнала, биконы? Или просто пакеты, уже после соединения? А вот это уже надо в код смотреть. Я подозреваю, что нет, потому что случайности там мало, и распределение у нее сомнительное. Оно плавает, конечно, но насколько случайны характеристики этого изменения...
Re: linux /dev/random initialization CVE-2018-1108
On 20/12/2018 11:00, Artem Chuprina wrote: С WiFi как с сетевого интерфейса, конечно, снимает. Уровень сигнала, биконы? Или просто пакеты, уже после соединения? -- sergio.
Re: linux /dev/random initialization CVE-2018-1108
sergio -> debian-russian@lists.debian.org @ Wed, 19 Dec 2018 22:32:14 +0300: > У хостов есть user input, у виртуалок сетевая активность, а что есть у > embedded? > Ну вот скажем у меня wifi чайник, который изображает точку доступа, что бы к > нем мог с телефона подключиться и температуру понастраивать. > С wifi, наверное, хорошо энтропию снимать. Соседей полно. Только делает ли > так > кто? С WiFi как с сетевого интерфейса, конечно, снимает.
Re: linux /dev/random initialization CVE-2018-1108
У embedded скорее всего (и если там есть os) ставят железный TRNG? On 19/12/2018 22.32, sergio wrote: У хостов есть user input, у виртуалок сетевая активность, а что есть у embedded? Ну вот скажем у меня wifi чайник, который изображает точку доступа, что бы к нем мог с телефона подключиться и температуру понастраивать. С wifi, наверное, хорошо энтропию снимать. Соседей полно. Только делает ли так кто?
Re: linux /dev/random initialization CVE-2018-1108
У хостов есть user input, у виртуалок сетевая активность, а что есть у embedded? Ну вот скажем у меня wifi чайник, который изображает точку доступа, что бы к нем мог с телефона подключиться и температуру понастраивать. С wifi, наверное, хорошо энтропию снимать. Соседей полно. Только делает ли так кто? -- sergio.
Re: linux /dev/random initialization CVE-2018-1108
Damir Hakimov -> Debian Russian Mailing List @ Tue, 18 Dec 2018 22:59:57 +0400: >> > > Получается проблема курицы и яйца. Чтобы набрать энтропию, системе >> > > требуется начать работать - обрабатывать какие-то сетевые запросы, >> > > шуршать диском и т.д. >> > Чисто для расширения кругозора вопрос: на сетевом интерфейсе свет > клином сошелся? Почему не задействовать микрофон, АЦП подключенный к > нагреваемому резистору, пятна на солнце для этой самой энтропии? В рассматриваемых случаях обычно ни микрофона, ни АЦП нет, а пятна на солнце есть, но вот данных о них опять же нет. Все-таки беседа в основном о серверах, причем часто о виртуальных. Может быть, ядерный ДСЧ и умеет задействовать микрофон, если он вдруг найдется. Конструкцию из АЦП с резистором — вряд ли, потому как те полтора землекопа, которые ее соберут, нехай сами дописывают этот кусок кода и оценивают собранную энтропию.
Re: linux /dev/random initialization CVE-2018-1108
Vladimir Zhbanov -> debian-russian@lists.debian.org @ Tue, 18 Dec 2018 23:25:46 +0300: >> > Чисто для расширения кругозора вопрос: на сетевом интерфейсе свет >> > клином сошелся? Почему не задействовать микрофон, АЦП подключенный к >> > нагреваемому резистору, пятна на солнце для этой самой энтропии? >> >> Нажатие клавиш (например, Shift-а с автоповтором) позволяет быстро >> проскочить место, где системный демон завис на getrandom(). >> Так что по крайней мере драйвер клавиатуры задействован. >> >> Но у серверов кроме сети существенных источников шума обычно нет. > Отслеживаемые напряжения питания материнской платы и процессора, > которых обычно несколько, по-любому плавают. Плавает и > температура, но гораздо медленнее, что, впрочем, тоже можно > использовать. Про какие-то процессоры читал, что там специально > улучшали качество и скорость отслеживания напряжений, по ходу даже > датчики и АЦП в том же корпусе были, чтобы энтропию собирать. Плохо там со случайностью без специальных мер. Для мониторинга высокоточное измерение не нужно, а при невысокой точности энтропии там кот наплакал. А если речь про виртуалку, так и вообще никак. Кто ж ей даст реальные данные о напряжении на плате?
Re: linux /dev/random initialization CVE-2018-1108
On Tue, Dec 18, 2018 at 10:35:51PM +0300, Eugene Berdnikov wrote: ... > > Чисто для расширения кругозора вопрос: на сетевом интерфейсе свет > > клином сошелся? Почему не задействовать микрофон, АЦП подключенный к > > нагреваемому резистору, пятна на солнце для этой самой энтропии? > > Нажатие клавиш (например, Shift-а с автоповтором) позволяет быстро > проскочить место, где системный демон завис на getrandom(). > Так что по крайней мере драйвер клавиатуры задействован. > > Но у серверов кроме сети существенных источников шума обычно нет. Отслеживаемые напряжения питания материнской платы и процессора, которых обычно несколько, по-любому плавают. Плавает и температура, но гораздо медленнее, что, впрочем, тоже можно использовать. Про какие-то процессоры читал, что там специально улучшали качество и скорость отслеживания напряжений, по ходу даже датчики и АЦП в том же корпусе были, чтобы энтропию собирать. -- Vladimir
Re: linux /dev/random initialization CVE-2018-1108
On Tue, Dec 18, 2018 at 10:59:57PM +0400, Damir Hakimov wrote: > > Artem Chuprina wrote: > > > > > > Получается проблема курицы и яйца. Чтобы набрать энтропию, системе > > > > требуется начать работать - обрабатывать какие-то сетевые запросы, > > > > шуршать диском и т.д. > > > Чисто для расширения кругозора вопрос: на сетевом интерфейсе свет > клином сошелся? Почему не задействовать микрофон, АЦП подключенный к > нагреваемому резистору, пятна на солнце для этой самой энтропии? Нажатие клавиш (например, Shift-а с автоповтором) позволяет быстро проскочить место, где системный демон завис на getrandom(). Так что по крайней мере драйвер клавиатуры задействован. Но у серверов кроме сети существенных источников шума обычно нет. -- Eugene Berdnikov
Re: linux /dev/random initialization CVE-2018-1108
> Artem Chuprina wrote: > > > > Получается проблема курицы и яйца. Чтобы набрать энтропию, системе > > > требуется начать работать - обрабатывать какие-то сетевые запросы, > > > шуршать диском и т.д. > Чисто для расширения кругозора вопрос: на сетевом интерфейсе свет клином сошелся? Почему не задействовать микрофон, АЦП подключенный к нагреваемому резистору, пятна на солнце для этой самой энтропии? -- DamirX
Re: linux /dev/random initialization CVE-2018-1108
On Tue, 18 Dec 2018 14:28:01 +0300 Eugene Berdnikov wrote: > On Tue, Dec 18, 2018 at 02:24:11PM +0300, Victor Wagner wrote: > > On Tue, 18 Dec 2018 14:16:49 +0300 > > Eugene Berdnikov wrote: > > > > > On Tue, Dec 18, 2018 at 01:37:47PM +0300, Victor Wagner wrote: > > > > > А вот кто бы объяснил: в initscripts есть > > > скрипт /etc/init.d/urandom, судя по датам модификации > > > файла /var/lib/urandom/random-seed скриптик исправно отрабатывает > > > при шатдауне и должен отрабатывать при загрузке, какого же хрена > > > ядро (во всяком случае, 4.17) блокируется на urandom, вместо > > > того, чтобы сохранённый пул использовать? Кто-нибудь в курсе > > > последних веяний в этой области? > > > > Так в системе systemd или sysV init? > > SysV. То-то я смотрю у меня в системе этот файлик 2015 годом датирован.
Re: linux /dev/random initialization CVE-2018-1108
On Tue, 18 Dec 2018 14:28:01 +0300 Eugene Berdnikov wrote: > On Tue, Dec 18, 2018 at 02:24:11PM +0300, Victor Wagner wrote: > > On Tue, 18 Dec 2018 14:16:49 +0300 > > Eugene Berdnikov wrote: > > > > > On Tue, Dec 18, 2018 at 01:37:47PM +0300, Victor Wagner wrote: > > > > > А вот кто бы объяснил: в initscripts есть > > > скрипт /etc/init.d/urandom, судя по датам модификации > > > файла /var/lib/urandom/random-seed скриптик исправно отрабатывает > > > при шатдауне и должен отрабатывать при загрузке, какого же хрена > > > ядро (во всяком случае, 4.17) блокируется на urandom, вместо > > > того, чтобы сохранённый пул использовать? Кто-нибудь в курсе > > > последних веяний в этой области? > > > > Так в системе systemd или sysV init? > > SysV.
Re: linux /dev/random initialization CVE-2018-1108
On Tue, Dec 18, 2018 at 02:24:11PM +0300, Victor Wagner wrote: > On Tue, 18 Dec 2018 14:16:49 +0300 > Eugene Berdnikov wrote: > > > On Tue, Dec 18, 2018 at 01:37:47PM +0300, Victor Wagner wrote: > > > А вот кто бы объяснил: в initscripts есть скрипт /etc/init.d/urandom, > > судя по датам модификации файла /var/lib/urandom/random-seed скриптик > > исправно отрабатывает при шатдауне и должен отрабатывать при > > загрузке, какого же хрена ядро (во всяком случае, 4.17) блокируется > > на urandom, вместо того, чтобы сохранённый пул использовать? > > Кто-нибудь в курсе последних веяний в этой области? > > Так в системе systemd или sysV init? SysV. -- Eugene Berdnikov
Re: linux /dev/random initialization CVE-2018-1108
On Tue, 18 Dec 2018 14:16:49 +0300 Eugene Berdnikov wrote: > On Tue, Dec 18, 2018 at 01:37:47PM +0300, Victor Wagner wrote: > А вот кто бы объяснил: в initscripts есть скрипт /etc/init.d/urandom, > судя по датам модификации файла /var/lib/urandom/random-seed скриптик > исправно отрабатывает при шатдауне и должен отрабатывать при > загрузке, какого же хрена ядро (во всяком случае, 4.17) блокируется > на urandom, вместо того, чтобы сохранённый пул использовать? > Кто-нибудь в курсе последних веяний в этой области? Так в системе systemd или sysV init?
Re: linux /dev/random initialization CVE-2018-1108
On Tue, Dec 18, 2018 at 01:37:47PM +0300, Victor Wagner wrote: > On Tue, 18 Dec 2018 13:30:06 +0300 > Artem Chuprina wrote: > > Отчасти да. Но энтропию оно набирает, сколь я помню, не только с > > сетевых запросов к себе, но и вообще со всего, что пролетает мимо > > сетевки. > > Ага щаз, так уж в эпоху управляемых свитчей и полетит что-нибудь > мимо сетевки, что этому хосту не адресовано. ARP-запросы разве что. Но > много ли их в типичной серверной стойке? Все бродкасты и мультикасты передаются ядру, и для типичной стойки такого мусора достаточно. Мало его там, где сеть хорошо структурирована, выделены серверные vlan'ы и лишних машин в этих сегментах нет. А вот кто бы объяснил: в initscripts есть скрипт /etc/init.d/urandom, судя по датам модификации файла /var/lib/urandom/random-seed скриптик исправно отрабатывает при шатдауне и должен отрабатывать при загрузке, какого же хрена ядро (во всяком случае, 4.17) блокируется на urandom, вместо того, чтобы сохранённый пул использовать? Кто-нибудь в курсе последних веяний в этой области? -- Eugene Berdnikov
Re: linux /dev/random initialization CVE-2018-1108
On Tue, 18 Dec 2018 13:30:06 +0300 Artem Chuprina wrote: > > Получается проблема курицы и яйца. Чтобы набрать энтропию, системе > > требуется начать работать - обрабатывать какие-то сетевые запросы, > > шуршать диском и т.д. > > > Но она не может стартовать ни одного сетевого сервиса, не набрав > > достаточно энтропии хотя бы для urandom, потому что все сервисы > > нынче хотят какие-нибудь эфемерные ключи. А следовательно - и > > проявить хоть какую-то сетевую активность, равно и локальный > > ввод-вывод. Поскольку клиентов нет, а любая имитация нагрузки > > будет все равно иметь проблемы со своей случайностью. > > Отчасти да. Но энтропию оно набирает, сколь я помню, не только с > сетевых запросов к себе, но и вообще со всего, что пролетает мимо > сетевки. Ага щаз, так уж в эпоху управляемых свитчей и полетит что-нибудь мимо сетевки, что этому хосту не адресовано. ARP-запросы разве что. Но много ли их в типичной серверной стойке? (а уж если это у нас виртуальный эзернет какой-нибудь системы управления виртуальными машинами...) > А сетевую активность без проблем со случайностью можно сделать, > например, так: взять совсем уже псевдослучайное число, например, > 8.8.8.8, пингануть его, таймингом ответа зарядить обычный дешевый > PRNG, который не криптографического качества, а дальше в параллель > попинговать его следующие значения, периодически подмешивая тайминги > ответов. С этого ядро наберет уже вполне вменяемую энтропию. Интересная идея. Может такую утилитку написать и запускать из post-up в /etc/network/interfaces? Только стартовый адрес надо конфигурируемым сделать. А то вдруг из этого датацентра нет роутинга до 8.8.8.8. --
Re: linux /dev/random initialization CVE-2018-1108
Victor Wagner -> Artem Chuprina @ Tue, 18 Dec 2018 12:52:11 +0300: >> Как интересно... Хотя, если по уму, то urandom'у бы тоже сначала >> набрать энтропию, и только потом уже раскручивать псевдорандомизацию. >> А прикапывать ее между перезагрузками чревато тем же боком. Так-то >> считается, что urandom — псевдослучайный, но с криптографическим >> качеством. А значит, должен иметь в виду криптографическую модель >> угроз. > Получается проблема курицы и яйца. Чтобы набрать энтропию, системе > требуется начать работать - обрабатывать какие-то сетевые запросы, > шуршать диском и т.д. > Но она не может стартовать ни одного сетевого сервиса, не набрав > достаточно энтропии хотя бы для urandom, потому что все сервисы нынче > хотят какие-нибудь эфемерные ключи. А следовательно - и проявить хоть > какую-то сетевую активность, равно и локальный ввод-вывод. Поскольку > клиентов нет, а любая имитация нагрузки будет все равно иметь проблемы > со своей случайностью. Отчасти да. Но энтропию оно набирает, сколь я помню, не только с сетевых запросов к себе, но и вообще со всего, что пролетает мимо сетевки. А сетевую активность без проблем со случайностью можно сделать, например, так: взять совсем уже псевдослучайное число, например, 8.8.8.8, пингануть его, таймингом ответа зарядить обычный дешевый PRNG, который не криптографического качества, а дальше в параллель попинговать его следующие значения, периодически подмешивая тайминги ответов. С этого ядро наберет уже вполне вменяемую энтропию.
Re: linux /dev/random initialization CVE-2018-1108
On Tue, 18 Dec 2018 12:24:57 +0300 Artem Chuprina wrote: > Как интересно... Хотя, если по уму, то urandom'у бы тоже сначала > набрать энтропию, и только потом уже раскручивать псевдорандомизацию. > А прикапывать ее между перезагрузками чревато тем же боком. Так-то > считается, что urandom — псевдослучайный, но с криптографическим > качеством. А значит, должен иметь в виду криптографическую модель > угроз. Получается проблема курицы и яйца. Чтобы набрать энтропию, системе требуется начать работать - обрабатывать какие-то сетевые запросы, шуршать диском и т.д. Но она не может стартовать ни одного сетевого сервиса, не набрав достаточно энтропии хотя бы для urandom, потому что все сервисы нынче хотят какие-нибудь эфемерные ключи. А следовательно - и проявить хоть какую-то сетевую активность, равно и локальный ввод-вывод. Поскольку клиентов нет, а любая имитация нагрузки будет все равно иметь проблемы со своей случайностью. --
Re: linux /dev/random initialization CVE-2018-1108
Eugene Berdnikov -> debian-russian@lists.debian.org @ Mon, 17 Dec 2018
23:22:51 +0300:
> On Mon, Dec 17, 2018 at 10:05:55PM +0300, Artem Chuprina wrote:
>> Eugene Berdnikov -> debian-russian@lists.debian.org @ Mon, 17 Dec 2018
>> 18:48> > Пришлось уже позаменять syslog-ng на rsyslog, потому что первый
>> вызывает
>> > getrandom() ДО того, как свалить в бэкграунд (правда, к нему и другие
>> > претензии были). Хорошо что sshd так не делает, иначе на серверах
>> > пришлось бы его под inetd переводить.
>>
>> Вот интересно, а зачем syslog-ng понадобилась настоящая энтропия? Чему
>> ему urandom не угодил?
> Насколько я разбираюсь в медицине, он как раз urandom и читает.
> Вот что написано в мане random(7):
>* The Linux-specific getrandom(2) system call, available since Linux
> 3.17. This system call provides access either to the same source as
> /dev/urandom (called the urandom source in this page) or to the same
> source as /dev/random (called the random source in this page). The
> default is the urandom source; the random source is selected by
> specifying the GRND_RANDOM flag to the system call. (The geten‐
> tropy(3) function provides a slightly more portable interface on top
> of getrandom(2).)
> А вот что делает syslog-ng, фрагмент трассы, который я отправил в BT:
>
> 1501 22:44:00
> getrandom("\x74\x78\x56\x35\x28\xad\x52\xd2\xcb\x51\xb1\x30\xc7\x67\x14\x26\x01\xa4\x2d\xa0\x30\x1d\xad\x09\x9e\xe3\x2c\x4e\x07\x55\x0d\x29",
> 32, 0) = 32 <322.583360>
> Got with "strace -Tt", means reading of 32 random bytes tooks 322 seconds.
>
> Флаги здесь, как видно, нулевые, в то время как GRND_NONBLOCK = 1,
> GRND_RANDOM = 2. Так что именно urandom он и читает, и блокируется
> на нём на 5 минут.
Как интересно... Хотя, если по уму, то urandom'у бы тоже сначала набрать
энтропию, и только потом уже раскручивать псевдорандомизацию. А
прикапывать ее между перезагрузками чревато тем же боком. Так-то
считается, что urandom — псевдослучайный, но с криптографическим
качеством. А значит, должен иметь в виду криптографическую модель угроз.
>> > Зато появился новый квест: писать программы так, чтобы они рандомные
>> > битики получали асинхронно, в отдельном треде. Рядом с резолвером.
>>
>> Опять-таки, если им нужна настоящая энтропия, то им ее все равно
>> дожидаться.
> Да, это правильно, но теперь нужно понимать, что этом сисколе можно крепко
> зависнуть, а это может быть критично. Для syslog-ng квест выглядит так:
> автор должен был догадаться, что сначала нужно создать сокет в /dev/log
> и сказать ему listen(), иначе некоторые сервисы (например, sshd) не захотят
> запускаться и процесс загрузки встанет. Так что просто сделать костыль,
> принудительно отправив syslog-ng в бэкграуд -- не получится. Я пробовал,
> на SysV-init. Возможно, с systemd результат будет иной, но проблема
> имеется, для других утилит она может проявляться иначе.
Да, одна проблема раскрыла наличие другой. Ну что ж, бывает...
Re: linux /dev/random initialization CVE-2018-1108
On Mon, Dec 17, 2018 at 10:05:55PM +0300, Artem Chuprina wrote:
> Eugene Berdnikov -> debian-russian@lists.debian.org @ Mon, 17 Dec 2018
> 18:48> > Пришлось уже позаменять syslog-ng на rsyslog, потому что первый
> вызывает
> > getrandom() ДО того, как свалить в бэкграунд (правда, к нему и другие
> > претензии были). Хорошо что sshd так не делает, иначе на серверах
> > пришлось бы его под inetd переводить.
>
> Вот интересно, а зачем syslog-ng понадобилась настоящая энтропия? Чему
> ему urandom не угодил?
Насколько я разбираюсь в медицине, он как раз urandom и читает.
Вот что написано в мане random(7):
* The Linux-specific getrandom(2) system call, available since Linux
3.17. This system call provides access either to the same source as
/dev/urandom (called the urandom source in this page) or to the same
source as /dev/random (called the random source in this page). The
default is the urandom source; the random source is selected by
specifying the GRND_RANDOM flag to the system call. (The geten‐
tropy(3) function provides a slightly more portable interface on top
of getrandom(2).)
А вот что делает syslog-ng, фрагмент трассы, который я отправил в BT:
1501 22:44:00
getrandom("\x74\x78\x56\x35\x28\xad\x52\xd2\xcb\x51\xb1\x30\xc7\x67\x14\x26\x01\xa4\x2d\xa0\x30\x1d\xad\x09\x9e\xe3\x2c\x4e\x07\x55\x0d\x29",
32, 0) = 32 <322.583360>
Got with "strace -Tt", means reading of 32 random bytes tooks 322 seconds.
Флаги здесь, как видно, нулевые, в то время как GRND_NONBLOCK = 1,
GRND_RANDOM = 2. Так что именно urandom он и читает, и блокируется
на нём на 5 минут.
> > Зато появился новый квест: писать программы так, чтобы они рандомные
> > битики получали асинхронно, в отдельном треде. Рядом с резолвером.
>
> Опять-таки, если им нужна настоящая энтропия, то им ее все равно
> дожидаться.
Да, это правильно, но теперь нужно понимать, что этом сисколе можно крепко
зависнуть, а это может быть критично. Для syslog-ng квест выглядит так:
автор должен был догадаться, что сначала нужно создать сокет в /dev/log
и сказать ему listen(), иначе некоторые сервисы (например, sshd) не захотят
запускаться и процесс загрузки встанет. Так что просто сделать костыль,
принудительно отправив syslog-ng в бэкграуд -- не получится. Я пробовал,
на SysV-init. Возможно, с systemd результат будет иной, но проблема
имеется, для других утилит она может проявляться иначе.
--
Eugene Berdnikov
Re: linux /dev/random initialization CVE-2018-1108
Eugene Berdnikov -> debian-russian@lists.debian.org @ Mon, 17 Dec 2018 18:48:51 +0300: >> >> > Почему нельзя сохранить entropy pool при выключении и восстановить >> при >> >> > включении, как происходить с urandom seed? >> >> >> >> Потому что небезопасно. >> >> > Может ли кто-нибудь изложить модель угроз? >> >> replay в случае восстановления диска с бэкапа/снапшота или размножения >> образов диска. > Угу, а те кому работать, а не заниматься размножением в рабочее время, > и кому нужно в случае чего быстро ребутнуться, те сосут лапу из-за > измышлений теоретиков. И ладно бы теоретики предусмотрели ручку, чтобы > отключить их фантазии нахрен, или хотя бы сделали параметр "время жизни > энтропийного пула" с отметками времени, mac-адресами сетевушек и т.п... > > Пришлось уже позаменять syslog-ng на rsyslog, потому что первый вызывает > getrandom() ДО того, как свалить в бэкграунд (правда, к нему и другие > претензии были). Хорошо что sshd так не делает, иначе на серверах > пришлось бы его под inetd переводить. Вот интересно, а зачем syslog-ng понадобилась настоящая энтропия? Чему ему urandom не угодил? > Зато появился новый квест: писать программы так, чтобы они рандомные > битики получали асинхронно, в отдельном треде. Рядом с резолвером. Опять-таки, если им нужна настоящая энтропия, то им ее все равно дожидаться. Пул и закончиться может. А если сгодится urandom, то фиг ли они настоящую просят?
Re: linux /dev/random initialization CVE-2018-1108
Eugene Berdnikov -> debian-russian@lists.debian.org @ Mon, 17 Dec 2018 19:04:40 +0300: >> > Ну и плюс, если речь о виртуалках у хостера, дополнительные риски с >> > доступом злоумышленника к образу диска (по сравнению с доступом к >> > памяти). >> >> Если виртуалка у хостера, то он уже и так имеет полный доступ ко всем >> закрытым ключам хранящимся на диске (ssh) и ещё одни приватные данные >> никаких рисков не добавят. > Вообще, у хостера есть доступ к памяти виртуалки... Так что прятать > что-то от хостера глупо. :) Не от хостера, а от соседей по хостингу. > Но зачем на хостинге приватные ключи ssh? Они должны быть на рабочей > станции админа, а на хостинг следует пробрасывать лишь ssh-agent. > Да и то не всегда, а лишь на доверенные хостинги. Ключи сервера, например, еще как нужны.
Re: linux /dev/random initialization CVE-2018-1108
On 17/12/2018 19:04, Eugene Berdnikov wrote: Но зачем на хостинге приватные ключи ssh? я про /etc/ssh/ssh_host_*_key -- sergio.
Re: linux /dev/random initialization CVE-2018-1108
On Mon, Dec 17, 2018 at 06:40:34PM +0300, sergio wrote: > On 17/12/2018 17:56, Artem Chuprina wrote: > > Ну и плюс, если речь о виртуалках у хостера, дополнительные риски с > > доступом злоумышленника к образу диска (по сравнению с доступом к > > памяти). > > Если виртуалка у хостера, то он уже и так имеет полный доступ ко всем > закрытым ключам хранящимся на диске (ssh) и ещё одни приватные данные > никаких рисков не добавят. Вообще, у хостера есть доступ к памяти виртуалки... Так что прятать что-то от хостера глупо. :) Но зачем на хостинге приватные ключи ssh? Они должны быть на рабочей станции админа, а на хостинг следует пробрасывать лишь ssh-agent. Да и то не всегда, а лишь на доверенные хостинги. Если же на хостинге нужно автономно использовать приватный ключ, его применение следует ограничить в authorized_keys. Например, разрешить запуск бэкапалки и запретить всё лишнее (форвард портов, etc). -- Eugene Berdnikov
Re: linux /dev/random initialization CVE-2018-1108
On Mon, Dec 17, 2018 at 05:56:47PM +0300, Artem Chuprina wrote: > Eugene Berdnikov -> debian-russian@lists.debian.org @ Mon, 17 Dec 2018 > 16:34:58 +0300: > > >> > Почему нельзя сохранить entropy pool при выключении и восстановить при > >> > включении, как происходить с urandom seed? > >> > >> Потому что небезопасно. > > > Может ли кто-нибудь изложить модель угроз? > > replay в случае восстановления диска с бэкапа/снапшота или размножения > образов диска. Угу, а те кому работать, а не заниматься размножением в рабочее время, и кому нужно в случае чего быстро ребутнуться, те сосут лапу из-за измышлений теоретиков. И ладно бы теоретики предусмотрели ручку, чтобы отключить их фантазии нахрен, или хотя бы сделали параметр "время жизни энтропийного пула" с отметками времени, mac-адресами сетевушек и т.п... Пришлось уже позаменять syslog-ng на rsyslog, потому что первый вызывает getrandom() ДО того, как свалить в бэкграунд (правда, к нему и другие претензии были). Хорошо что sshd так не делает, иначе на серверах пришлось бы его под inetd переводить. Зато появился новый квест: писать программы так, чтобы они рандомные битики получали асинхронно, в отдельном треде. Рядом с резолвером. -- Eugene Berdnikov
Re: linux /dev/random initialization CVE-2018-1108
On 17/12/2018 17:56, Artem Chuprina wrote: Во втором случае получится не столько replay как таковой, сколько одинаковые seed'ы у нескольких инстансов. Как и одинаковые ssh ключи. И пока настоящая энтропия не набежала, выхлоп из них будет очень сильно скоррелирован, на самом старте, возможно, даже идентичен. Она-то хоть набежит, а вот ssh ключи сами себя не обновят. Ну и плюс, если речь о виртуалках у хостера, дополнительные риски с доступом злоумышленника к образу диска (по сравнению с доступом к памяти). Если виртуалка у хостера, то он уже и так имеет полный доступ ко всем закрытым ключам хранящимся на диске (ssh) и ещё одни приватные данные никаких рисков не добавят. -- sergio.
Re: linux /dev/random initialization CVE-2018-1108
Eugene Berdnikov -> debian-russian@lists.debian.org @ Mon, 17 Dec 2018 16:34:58 +0300: >> > Почему нельзя сохранить entropy pool при выключении и восстановить при >> > включении, как происходить с urandom seed? >> >> Потому что небезопасно. > Может ли кто-нибудь изложить модель угроз? replay в случае восстановления диска с бэкапа/снапшота или размножения образов диска. Во втором случае получится не столько replay как таковой, сколько одинаковые seed'ы у нескольких инстансов. И пока настоящая энтропия не набежала, выхлоп из них будет очень сильно скоррелирован, на самом старте, возможно, даже идентичен. Ну и плюс, если речь о виртуалках у хостера, дополнительные риски с доступом злоумышленника к образу диска (по сравнению с доступом к памяти). Или к освобожденным блокам хранилища после затирания этого seed'а на виртуальном диске. Память-то под это дело наверняка лочится, и в своп данные RNG не попадают.
Re: linux /dev/random initialization CVE-2018-1108
On 17/12/2018 15:59, Artem Chuprina wrote: > Почему нельзя сохранить entropy pool при выключении и восстановить при > включении, как происходить с urandom seed? Потому что небезопасно. Чем именно? -- sergio.
Re: linux /dev/random initialization CVE-2018-1108
On Mon, Dec 17, 2018 at 03:59:35PM +0300, Artem Chuprina wrote: > sergio -> debian-russian @ Mon, 17 Dec 2018 15:09:11 +0300: > > Почему нельзя сохранить entropy pool при выключении и восстановить при > > включении, как происходить с urandom seed? > > Потому что небезопасно. Может ли кто-нибудь изложить модель угроз? -- Eugene Berdnikov
Re: linux /dev/random initialization CVE-2018-1108
sergio -> debian-russian @ Mon, 17 Dec 2018 15:09:11 +0300: > Я правильно понял, что безопасных способов решения проблемы нет? > (Ну кроме как купить надёжный TRNG.) Да. RNG - это в принципе самая большая проблема криптографии. > Почему нельзя сохранить entropy pool при выключении и восстановить при > включении, как происходить с urandom seed? Потому что небезопасно.
