Разработчики системного менеджера systemd намерены (http://www.heise.de/open/meldung/Systemd-will-Linux-Start-pe...) интегрировать в состав пакета поддержку загрузчика gummiboot (http://freedesktop.org/wiki/Software/gummiboot/) для обеспечения верификации процесса загрузки на системах с UEFI Secure Boot. Верификация загрузки позволит гарантировать отсутствие посторонней активности во время начальной загрузки, в том числе присечь попытки запуска подконтрольных злоумышленникам приложений, внедрённых, например, для перехвата ввода паролей к зашифрованным разделам.
Ранее поддержка верификации как правило ограничивалась проверкой загрузчика или верификацией загрузки ядра и связанных с ним модулей. Разработчики systemd предлагают расширить число проверяемых компонентов, дав возможность пользователю разрешить загрузку только специально подписанных системных образов начальной загрузки (initramfs). Даже получив доступ к системе атакующие не смогут внести изменения в initramfs чтобы запустить кейлоггер и перехватить ввод пароля к зашифрованному корневому разделу.
Загрузчик gummiboot выбран так как он является разработкой (http://www.opennet.me/opennews/art.shtml?num=34222) Red Hat, изначально поддерживает интеграцию с systemd и не требует (https://plus.google.com/u/0/+KaySievers/posts/GisPmPBsqfK) специальной настройки - он автоматически выявляет конфигурацию ядра и наличие на диске заверенных цифровой подписью EFI-образов и добавляет их в меню загрузки.
<center><a href="http://freedesktop.org/wiki/Software/gummiboot/gummiboot-men... src="http://www.opennet.me/opennews/pics_base/0_1422903487.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>Дополнительно можно отметить публикацию (http://ma.ttias.be/whats-new-systemd-2015-edition/) тезисов выступления Леннарта Поттеринга (Lennart Poettering) на конференции FOSDEM, в котором он рассказал о последних тендерция в разработке systemd и планах на ближайшее будущее.
Некоторые интересные выдержки из доклада:
- В systemd появится поддержка перезапуска сервисов без потери состояния - каждый демон сможе сохранять на диске своё минимальное состояние и после перезапуска восстановить исходное состояние (systemd сохранит открытые сокеты и файловые дескрипторы и после перезапуска передаст их сервису).- Ожидается минимальная поддержка средств управления межсетевым экраном в привязке к сервисам, а не номерам портов. Например, вместо определения правил доступа к 80 порту, можно будет привязать правила к http-серверу apache, без оглядки на то, на каком порту он принимает соединения.
- Приоритетным остаётся подход, при котором большая часть подсистем systemd, за исключением journald, не являются обязательными и могут быть отключены;
- Работа над компонентами пространства пользователя для dbus практически завершена;- Nspawn вырос из системы тестирования системы инициализации без необходимости перезагрузки в систему управления изолированными контейнерами, поддерживающую RAW-образы и docker-подобные контейнеры;- Под впечатлением от концепции Solaris zone развивается machined - менеджер регистрации виртуальных машин;- В будущем ожидается появление новых возможностей, связанных с изолированными контейнерами. В конечном счёте, целью является обеспечение работы всех инструментов systemd с оглядкой на контейнеры, например, journald может показывать как логи/сообщения основного хоста, так и всех работающих на нём контейнеров;
- В следующем выпуске systemd появится дополнительная поддержка btrfs;
- В consoled появится поддержка экранов high DPI и Unicode;- Утилиты systemctl-cat и systemctl-edit позволят отобразить и отредактировать файл конфигурации выбранного юнита (например, "systemctl-cat apache2.service"), без необходимости определения пути.
- Команда "ping gateway" позволит автоматически определить всех доступные сетевые интерфейсы и проверить их работу утилитой ping;- Развитие networkd и средств для автоматической настройки сетевой конфигурации в изолированных контейнерах. Создание собственной библиотеки для работы с DHCP (dhcpv4 и dhcpv6);- Создание средств для проведения системного аудита, например, для ведения полного лога системных вызовов, связанных с /etc/passwd. Добавление средств аудита в journald и реализация в audit-tools возможность чтения сохранённых в journald логов;- Обеспечение работы систем, не сохраняющих своё состояние (stateless). Генерация содержимого /etc и /var для таких систем.
- Возможность journald-remoting (http://www.freedesktop.org/software/systemd/man/systemd-jour...) для передачи бинарных логов на удалённый хост с использованием HTTP вместо протокола syslog. Поддержка в journald моделей pull и push: при pull выполняется запрос HTTP GET для получения потока JSON, а при push данные передаются в другой экземпляр journald при помощи HTTP POST. Поддержка данных режимов позволит существенно упросить отправку логов из различных программ, вместо поддержки syslog в которых достаточно будет отправить запрос по HTTP.
- Возможность определения минимальных пространств имён и sandbox-изоляции для сервисов, например, сделать для выбранных сервисов доступ к /usr и /home в режиме только на чтение или вообще скрыть или запретить доступ. Возможность использования отдельных директорий /tmp для определённых сервисов. Возможность ограничения доступа к файлам устройств /dev/*, с сохранением возможности работы с /dev/zero, /dev/null и т.п.
- Развитие простого ntp-клиента timesyncd (https://wiki.archlinux.org/index.php/systemd-timesyncd) в качестве минималистичной альтернативы ntpd;- Автоматическое определение разделов GPT (GUID Partition Table) без их явного перечисления в etc/fstab;
URL: http://www.heise.de/open/meldung/Systemd-will-Linux-Start-pe...
Новость: http://www.opennet.me/opennews/art.shtml?num=41592
> Приоритетным остаётся подход, при котором большая часть подсистем systemd, за исключением journald, не являются обязательными и могут быть отключеныВопрос, сколько и чего в бинарных дистрибутивах скомпилят-включат мейнтейнеры.
Тем временем где-то в районе 3.19 появилась возможность проверки цифровой подписи init...
Ответ, сколько и чего посчитают нужным, столько в бинарных дистрибутивах и скомпилят-включат мейнтейнеры.
journald периодически создаёт проблемы (забирает себе весь CPU, блокирует переключение раздела в режим ro).
> journald периодически создаёт проблемы (забирает себе весь CPU, блокирует переключение
> раздела в режим ro).Ну, он же знает, что после ro уже ничего не допишешь (как же так, он же журнал (ядро пофиг) ;)
>каждый демон сможе сохранять на диске своё минимальное состояние и после перезапуска восстановить исходное состояниеГм. Ну программы так обычно и работают. Или Поттеринг утверждает, что это каким-то образом будет делаться средствами systemd без модификации кода демона?
Да нет, конечно. Просто хочет чтобы вообще все демоны имели в зависимостях libsystemd
если это действительно так то это полный ахтунг, если раньше ты хотел перенести функционал какого либо сетевого сервиса на систему без системд(например мобильный девайс), то тебе приходилось как минимум мучиться с кросс компиляцией, а сейчас помимо всего прочего придется руками выпиливать зивисимости от этого барахла?
что скажут на это системд фаны?
> если это действительно так то это полный ахтунг, если раньше ты хотел
> перенести функционал какого либо сетевого сервиса на систему без системд(например мобильный
> девайс), то тебе приходилось как минимум мучиться с кросс компиляцией, а
> сейчас помимо всего прочего придется руками выпиливать зивисимости от этого барахла?
> что скажут на это системд фаны?Необходимо, кодить больше разных "падучих" демонов, что бы системд смог подать им руку при падении?!?!? Ну это только в том случае если оформлена подписка на "поднятие" ;)
Библиотеку назвать libsystemd-viagra :)
> что скажут на это системд фаны?Они ничего не скажут, ибо лохи и не понимают, что и как работает.
--without-systemd в autoconf спасёт отцов русского ретроградства
> Ну программы так обычно и работают.Они обычно так не работают, а они обычно после перезапуска заново производят инициализацию, подключение и т.д. Здесь же каким-то образом будет сохранятся то, что необязательно вычислять заново после перезапуска и таким образом будет экономится время и ресурсы.
А как это будет выглядеть-то? Вот перезапущенному сервису systemd отдал кучу файловых дескрипторов — как сервис должен узнать номера этих дескрипторов, узнать что за ресурсы они обозначают, и в какой стадии работы с ними они находятся?Пример — файловый дескриптор 35 для TCP-соединения 0.0.0.0:80-x.x.x.x:12345, оттуда уже было получено 40 байт (HTTP/1.1 строка запроса и кусочек первого заголовка). Как перезапущенный сервис обо всем этом узнает — что есть открытый дескриптор 35, что он TCP-сокет, что из него пришло 40 байт, и какие именно байты?
> А как это будет выглядеть-то?Что-за-истерика-ТМ? Прочитай-ложик-Б-бога-уже-R!
Example 4. Store a File Descriptor in the Service ManagerTo store an open file descriptor in the service manager, in order to continue operation after a service restart without losing state use "FDSTORE=1":
sd_pid_notify_with_fds(0, 0, "FDSTORE=1", &fd, 1);
+++Пять строчек, пять переменных -- to rule th^W^W^Wдовольно с них, со всех!
То есть если я хочу этой штукой пользоваться, мне надо при остановке засериализовать куда-то все контексты для открытых сокетов и запихнуть эти сокеты в sd_pid_notify_with_fds(), а потом при запуске разсериализовать контексты и продолжить как ни в чем не бывало. Вызывать sd_listen_fds() по желанию, чтобы проверить, все ли FD_STORE'нные сокеты были возвращены.Ну, в принципе неплохо. Надо, конечно, будет вместе с контекстами сокетов хранить изначальное окружение/настройки и потом сравнивать его с новыми, и решать, не стоит ли закрыть какой-то из восстановленных сокетов, но это и так неизбежно, если ты пишешь snapshot-able программу.
С другой стороны, такие сложности редко когда оправданы.
> С другой стороны, такие сложности редко когда оправданы.Оправданы например с долгоживущими TCP-соединениями.
>> А как это будет выглядеть-то?
> Что-за-истерика-ТМ? Прочитай-ложик-Б-бога-уже-R!Example 4.
> Store a File Descriptor in the Service ManagerАга, а другом конце сокета тебя уже три раза нах послали, выслав TCP_RST или shutdown()
А смысл-то вообще в чем? НАФИГА? Нет таких реальных ситуаций, где бы это действительно нужно было. Конфиг перечитать - все равно придется все потом переоткрывать, потому что что-то изменилось. Просто так остановить и потом снова запустить - это вообще бессмысленно само по себе и уже есть SIGSTOP/SIGCONT.
> А смысл-то вообще в чем? НАФИГА? Нет таких реальных ситуаций, где быЛогр Воландепоттр сказал -- значит, нужно! Неосиляторы бьются в истерике на обочине истории, нет им места в Профессии(тм). Один Комбайн to rule 'em all, олл ёр бэйз билонг, суррендер ёр шилдз, OBEY^WSIGOBEY!
> есть SIGSTOP/SIGCONT.
В теории можно вообразить службу, которая сохранит текущее состояние, перечитает конфигурацию, восстановит состояние, решит, что в нем надо исправить, чтобы оно соответствовало новым настройкам (условно говоря, какие соединения стоит оборвать, а какие могут продолжать работать), и продолжит работать как ни в чем не бывало. Делать это через "прибить процесс-изменить конфиг-запустить процесс" раньше было невозможно потому, что сетевые соединения на первом шаге умирают.Другое дело, что это действительно нахрен не надо: если вы умеете корректно накатывать новые настройки, так обрабатывайте SIGHUP. Опять же, SIGSTOP/SIGCONT - любая сетевая программа умеет обрабатывать внезапный обрыв соединения, это не проблема. Задержки из-за переподключений? Так большинство протоколов устроено так, что при резком изменении настроек одной из сторон протокол следует прервать и начать заново. Рядом в комментариях кто-то вообще шутил насчет восстановления *упавшего* сервиса, но это уж совсем — вы его восстановите (точнее, состояние из последнего снапшота), а он тут же опять упадет по той же самой причине. Ну и понту?
Если сервис падает, то каким макаром он сможет systemd передать свои файловые дескрипторы? Тут либо придется на sigsegv вешать передачу, но это чревато как раз тем самым бесконечным повтором с загрузкой сервера на 100% (да и проще сразу новую копию себя запустить из обработчика и ему напрямую - systemd-то дергать зачем?). Либо обязать ядро отдавать все дескрипторы упавших программ этому самому. Но это уже вообще за гранью добра и зла будет.
Очевидно, он должен их отдавать до того, как упадет — открыл файл, дернул systemd, куда-то положил снапшот своего текущего состояния. И так на каждый чих. Такое вполне возможно, даже пара ОС такого типа была написана, но это дорого, очень дорого...
> Очевидно, он должен их отдавать до того, как упадет — открыл файл,
> дернул systemd, куда-то положил снапшотНикакого отношения к _падению это иметь не может. И Ленарт тоже идиот.
http://httpd.apache.org/docs/2.4/stopping.html#gracefulstop
То же самое есть и у nginx. И у кучи других сетевых сервисов, скорее всего.+++
Только существующие соединения (=без разрывов и переподключений для клиенсов) продолжают обслуживать старые воркеры, которые больше не принимают новых соединений и _завершаются, когда клиент закончит или кто-то прибьёт их, воркеров (таймаут, килллл).
Свет же наш Солнышко Ленарт предлагает, видимо, прерываться посреди отдачи файла, например, по ftp:, быренько-быренько скинуть с воркер-процесса внутреннее состояние и fd сокета клиентского соединения в тёмный и прохладный s-d, перезапустить сервис, который уже должен быть научен, отдельно от s-d, прогрессивными монтёнерами [того ftpd] и исполнить танец святого Ленарта: восстановить внутреннее состояние, взять сокет и _продолжить обслуживать клиента. Типа, "как ни в чём не бывало". И пусть у _них, тех прогрессивных ребят, голова болит про изменение конфигурации (=+ а вдруг теперь клиента и не надо обслуживать?), изменение версии сервера (=+ формата "сохранения сосотояния") и кучи прочих _плодов _с _куста ленартова. Но Ленарт не может быть обвинён ни за что -- то уже будут _не _его проблемы. By "design".
+++Когда-то уже же Ленарт расскажет нам о бесшовном перезапуске икс-сервера?
>> Очевидно, он должен их отдавать до того, как упадет — открыл файл,
>> дернул systemd, куда-то положил снапшот
> Никакого отношения к _падению это иметь не может. И Ленарт тоже идиот, который хочет http://lwn.net/Articles/434821/rss?format=printable быть Линусом??!
---Это не дирижабль, это последний выдох господина ПЖ!
Во-во, именно так, потому что больше ни к чему и не приделать эту фичу.Я же, собственно, какую мысль имел в голове? Что в теории-то найти этой фиче применение можно, но на практике она нафиг никому не сдалась — те проблемы, которые она может помочь решить, либо ни фига не проблемы, либо решаются уже имеющимися методами гораздо проще и яснее. Это просто "крутая фича": "Глядите, теперь сервис может сохранить файлы открытыми между перезапусками, а раньше не мог!"
Вот только задаться вопросом "ну это конечно круто, а какую проблему это решает?" очевидно, руки не дошли.
Проблему оно решает единственную - надо чтобы большое количество демонов имело бы libsystemd в зависимостях. Захват плацдарма и последующее его расширение. Человек реально уже в войну с миром "консервативных линуксоидов" играет.
> Только существующие соединения (=без разрывов и переподключений для клиенсов) продолжают
> обслуживать старые воркеры, которые больше не принимают новых соединений и _завершаются,
> когда клиент закончит или кто-то прибьёт их, воркеров (таймаут, килллл).В реале это приводит к тому, что на graceful restart новые соединения ВООБЩЕ не принимаются, пока не умрут все воркеры.
> В реале это приводит к тому, что на graceful restart новые соединения
> ВООБЩЕ не принимаются, пока не умрут все воркеры.Я слышал про другой "реал", где ставый мастер шлёт старым воркерам сигнал, они все откоючаются от _слушающего сокета, но не разрывают и продолжают обрабатывать ранее установленные соединения. После этого новый мастер (да, кстати, и пославший старому мастеру тот сигнал) открывает слушающий сокет, пускает воркеров, и они, кооперативом, обрабатывают новые вх.соедиения. А старые воркеры ко всему, когда старые соединения закрываются [все], "просто" завершаются.
Другое дело, что и с таком виде это никому не надо, 99,99% админов довольно простого рестарта.
> Я слышал про другой "реал", где ставый мастер шлёт старым воркерам сигнал,
> они все откоючаются от _слушающего сокета, но не разрывают и продолжают
> обрабатывать ранее установленные соединения. После этого новый мастер (да, кстати, и
> пославший старому мастеру тот сигнал) открывает слушающий сокет, пускает воркеров, и
> они, кооперативом, обрабатывают новые вх.соедиения. А старые воркеры ко всему, когда
> старые соединения закрываются [все], "просто" завершаются.Проверил на подручной площадке (благо кластер, и выпадение одного httpd к отказу в обработке запросов не приводит xD). 2.2 и 2.4 ведут себя в точности, как я написал.
А простой рестарт плох тем, что DL'ящие длинные файлы или ждущие длинного запроса клиенты получают кукиш...
(systemd сохранит открытые сокеты и файловые дескрипторы и после перезапуска передаст их сервису)
> (systemd сохранит открытые сокеты и файловые дескрипторы и после перезапуска передаст их
> сервису)systemd-keyd для передачи сеансовых ключей, к подключениям которые были открыты в момент падения! ;)
NSA одобряет ;)
>дав возможность пользователю разрешить загрузку только специально подписанных системных образов начальной загрузки (initramfs...в котором уже лежит systemd, и если подписи недоступны, то systemd может стать невыпиливаемым на кривых UEFI и всяких лок-инах.
зы. даешь UEFI с QR-кодами и веб-сервером!
> systemd может стать невыпиливаемым на кривых UEFI и всяких лок-инах.на кривых (забагованных) реализациях UEFI -- просто отключи режим Secure Boot. и не мучийся
> просто отключи режим Secure Boot. и не мучийсяУчитывая что там априори прописаны ключи микрософта, которому я ни разу не доверяю, потому что они подписывают своими подписями даже БОЕВЫЕ КОМПЛЕКСЫ ДЛЯ САБОТАЖА - секурность этого бута очень преувеличена, скажем так.
А давайте без FUD?Есть возможность их удалить (либо просто не устанавливать. Да, они есть в фирмвари, но не используются для проверки, пока не выбрать "Install default Secure Boot keys" или подобное). Обычно это рядом с пунктами по установке своих ключей.
Секьюрность бута заключается исключительно в возможности проверить загружаемый код на предмет подписи, никакой конкретики - какими ключам - спецификацией не оговорено.
И кстати, Microsoft *ГАРАНТИРУЕТ*, что на любой x86 системе с Secure Boot и ключами винды - даже если она была предустановлена с виндой и ключи уже установлены - ОБЯЗАТЕЛЬНО есть возможность убрать ключи Microsoft и установить свои ВМЕСТО них. Если в фирмвари нет такого пункта - материнка никогда не получит сертификации с Windows 8 и не имеет право использовать логотип. Так что не надо тут разводить панику без повода.
> И кстати, Microsoft *ГАРАНТИРУЕТ*, что на любой x86 системе с Secure Boot и ключами винды - даже если она была предустановлена с виндой и ключи уже установлены - ОБЯЗАТЕЛЬНО есть возможность убрать ключи Microsoft и установить свои ВМЕСТО них.Только благодаря тому, что люди во время поднимали шум. А так изначально они лоббировали исключить такую возможность.
> А давайте без FUD?
> Есть возможность их удалить (либо просто не устанавливать. Да, они есть в
> фирмвари, но не используются для проверки, пока не выбрать "Install default
> Secure Boot keys" или подобное). Обычно это рядом с пунктами по
> установке своих ключей.
> Секьюрность бута заключается исключительно в возможности проверить загружаемый код на
> предмет подписи, никакой конкретики - какими ключам - спецификацией не оговорено.birus-ы все исправят!
Другое дело что это очень трудоемко. Но когда все унифицируют...
> А давайте без FUD?А давайте без давайте?
> Есть возможность их удалить (либо просто не устанавливать. Да, они есть в
> фирмвари, но не используются для проверки, пока не выбрать "Install default
> Secure Boot keys" или подобное). Обычно это рядом с пунктами по
> установке своих ключей.Внимание, коронный вопрос: как мне с разумными затратами усилий проверить что блоб-онли фирмвара по факту перестала доверять всем кроме апрувнутого мной ключа? Раз уж мы про секурность...
> Секьюрность бута заключается исключительно в возможности проверить загружаемый код на
> предмет подписи, никакой конкретики - какими ключам - спецификацией не оговорено.Спецификацией - да. А вот если какой-то микрософт и их друзья, ну и просто хаксоры спершие ключи, смогут на моей системе запускать какое-нибудь боевое программное обеспечение, которое я совсем не заказывал - какая ж это секурити?
> и ключи уже установлены - ОБЯЗАТЕЛЬНО есть возможность убрать ключи Microsoft
И как мне проверить что все ключи по факту убраны и что фирмвара перестала доверять кому попало? Сорцов то нет. А дизассемблером колупать десятиметровый блобик как-то утомительно. Мне предлагается поверить на честное слово мутному многометровому блобу от штатовских проприерасин прогнувшихся под микрософт? Секурити такая секурити...
> Так что не надо тут разводить панику без повода.
Так это не паника, это капитанинг. Вы, простите, глупый, если готовы на честное слово верить огромному многометровому блобу без сырцов но с чужими ключами что мамой клянус, будет безопасно.
> Внимание, коронный вопрос: как мне с разумными затратами усилий проверить что блоб-онли
> фирмвара по факту перестала доверять всем кроме апрувнутого мной ключа? Раз
> уж мы про секурность...Никак. Используйте Coreboot какой-нибудь или еще что.
Строго говоря, даже честная фирмварь не может знать, что ее не обманывают, если она хранит ключи в внешнем TPM-модуле - она скажет "очистить" и запишет туда ключ, а он ей потом дополнительный ключ будет доставать. А еще Computrace может некий код выполнять и что-то делать http://betanews.com/2014/08/12/computrace-back-door-could-ma.../
В общем, в страшном мире мы живем. Но это не повод валить все зло на конкретные технологии. Можете обойтись без них - рад за вас. Не можете - не надо распространять мифы, что Secure Boot это зло и там "вшита левая функциональность". Она и без него вшита в места, которые вы выключить не можете.>> Секьюрность бута заключается исключительно в возможности проверить загружаемый код на
>> предмет подписи, никакой конкретики - какими ключам - спецификацией не оговорено.
> Спецификацией - да. А вот если какой-то микрософт и их друзья, ну
> и просто хаксоры спершие ключи, смогут на моей системе запускать какое-нибудь
> боевое программное обеспечение, которое я совсем не заказывал - какая ж
> это секурити?Не смогут. Не надо исходить из неверных предпосылок. Убираете ключи и левый код не запустится.
(кроме того, я думаю, если MS подпишет ключами какую-нибудь малварь или допустит, что ключи своруют, будет скандал такого масштаба, что вы про это точно заранее узнаете)
>> Так что не надо тут разводить панику без повода.
> Так это не паника, это капитанинг. Вы, простите, глупый, если готовы на
> честное слово верить огромному многометровому блобу без сырцов но с чужими
> ключами что мамой клянус, будет безопасно.А вы переворачиваете ситуацию с ног на голову и вините Secure Boot как источник угроз. В то время как именно он *дает* вам возможность предотвратить запуск левого "боевого программного обеспечения". А вот без него как раз - запускай кто угодно что угодно.
Я ж не предлагаю вам на 100% верить, что включение Secure Boot обезопасит вас ото всех угроз. Современный хакер вообще поставит вам какое-нибудь расширение в браузер и будет спирать оттуда ваши аккаунты и другую приватную информацию - сейчас информация = деньги (а глядишь, и номер кредитки подвернется). И плевать ему на то, что там при загрузке. Но в текущей реализации Secure Boot только может безусловно увеличить безопасность системы, ограничивая запуск кодом, подписанным MS или же админом вашей организации (по вашему желанию). Без него у вас нет такой возможности. Никаким образом его включение не может скомпрометировать безопасность по сравнению с его выключением или отсутствием - или будьте добры, приведите такой пример. А то вы разводите какие-то теории "а что если фирмварь не исключила ключ" (наверное, в MS не идиоты сидят и проверили, что функциональность работает, а не просто пункт в меню во время сертификации?).
А что если фирмварь только притворяется, что грузит линукс, а на самом деле быстро грузит винду или еще что, включает виртуализацию, в ней загружает ваш линукс, а на самом деле контролирует гипервизор и секретно выполняет там и другой код, о котором вы не знаете? Это намного более вероятно, чем то, что она мухлюет с ключиками! Во всяком случае, тут хотя бы профит какой-то есть.
>[оверквотинг удален]
> выключением или отсутствием - или будьте добры, приведите такой пример. А
> то вы разводите какие-то теории "а что если фирмварь не исключила
> ключ" (наверное, в MS не идиоты сидят и проверили, что функциональность
> работает, а не просто пункт в меню во время сертификации?).
> А что если фирмварь только притворяется, что грузит линукс, а на самом
> деле быстро грузит винду или еще что, включает виртуализацию, в ней
> загружает ваш линукс, а на самом деле контролирует гипервизор и секретно
> выполняет там и другой код, о котором вы не знаете? Это
> намного более вероятно, чем то, что она мухлюет с ключиками! Во
> всяком случае, тут хотя бы профит какой-то есть.Может ли фирмварь обновится в то время как уже операционная система загружена и работает?
> Может ли фирмварь обновится в то время как уже операционная система загружена
> и работает?Ну "обновить прошивку" из ОС можно (тупо записывается новый код во флешку) - но я не уверен, что новый код начнет выполняться прямо сейчас, я не со следующей загрузки.
UEFI также может обновлять сам себя, но опять же работает начиная со следующей загрузки..
Определенный код UEFI работает во время работы ОС - не тот, который загружает, а отдельные т.н. runtime-сервисы - например, задумывалось, что UEFI может предоставить драйверы устройств, незнакомых операционке, реализованные в виде кода для нее. Но практически ОС (как минимум винда и линукс) не обращаются к runtime-сервисам, т.к. это сложно организовать безопасно. Поэтому как-то сказать UEFI, что нужно выполнять новый залитый код или подобное не выйдет.
Из http://vzimmer.blogspot.ru/2012/12/accessing-uefi-form-opera...
> The net result is that you cannot get to the UEFI RT or the system table at OS runtime, I'm afraid. The Linux sysfs is the closest but even there it doesn't expose each UEFI RT call point. The reason that the UEFI variable services are exposed in the fashion they are via Win32 calls is that OS installer programs have needed them since EFI1.02 back in 1999. Writing UEFI RT code is pretty tricky because of things like the OS owning the hardware, the virtual mapping of the firmware, etc.(i.e., tough for firmware folks). Also, the OS guys don't necessarily trust firmware and the UEFI RT code/data isn't hardware isolated from the other OS kernel components and drivers.
>[оверквотинг удален]
> UEFI также может обновлять сам себя, но опять же работает начиная со
> следующей загрузки..
> Определенный код UEFI работает во время работы ОС - не тот, который
> загружает, а отдельные т.н. runtime-сервисы - например, задумывалось, что UEFI может
> предоставить драйверы устройств, незнакомых операционке, реализованные в виде кода для
> нее. Но практически ОС (как минимум винда и линукс) не обращаются
> к runtime-сервисам, т.к. это сложно организовать безопасно. Поэтому как-то сказать UEFI,
> что нужно выполнять новый залитый код или подобное не выйдет.
> Из http://vzimmer.blogspot.ru/2012/12/accessing-uefi-form-opera...
>> The net result is that you cannot get to the UEFI RT or the system table at OS runtime, I'm afraid. The Linux sysfs is the closest but even there it doesn't expose each UEFI RT call point. The reason that the UEFI variable services are exposed in the fashion they are via Win32 calls is that OS installer programs have needed them since EFI1.02 back in 1999. Writing UEFI RT code is pretty tricky because of things like the OS owning the hardware, the virtual mapping of the firmware, etc.(i.e., tough for firmware folks). Also, the OS guys don't necessarily trust firmware and the UEFI RT code/data isn't hardware isolated from the other OS kernel components and drivers.Это я не к тому, что бы сказать очевидную вещь, а для того что бы сказать еще более очевидную вещь: аппаратный триггер необходимо ставить. Который переключается только в одну сторону и только один раз (до следующего "аппаратного" reset-а). Фирмварь по завершению работы переключит этот триггер, и тем самым (аппаратно) снимет напряжение питания (для записи) с соответствующей ножки микрухи.
> Но в текущей реализации Secure Boot только может безусловно увеличить безопасность системы, ограничивая запуск кодом, подписанным MS или же админом вашей организации (по вашему желанию).Ходят слухи что админ "нашей" организации не имеет право подписать код. Это может сделать только МС. Либо это не секуребут.
> Ходят слухи что админ "нашей" организации не имеет право подписать код. Это может сделать только МС. Либо это не секуребут.Не надо слухов, берете signtool от MS или оупенсорсный аналог под линукс (ссылка есть ниже) и подписываете вашим ключем. Ключ записываете на флешку или любой fat32 раздел, в фирмвари выбираете "установить пользовательский ключ" и выбираете его. Включаете secure boot.
MS вообще не имеют отношения к технологии Secure Boot - и ее реализация никак не завязано на существование MS. Просто была договоренность от MS с производителями материнок, что те будут поставлять ключи MS в фирмвари.
Почитайте наконец секцию про Secure Boot тут
https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-.../
и прекратите верить слухам.
> MS вообще не имеют отношения к технологии Secure Boot - и ее реализация никак не завязано на существование MS.
> Ключ записываете на флешку или любой fat32 разделДа вааааще мс тут не при чём. Просто так fat в стандарте самозародился. Точно так же как и secureboot.
И оказывается что пока ещё это разрешено делать на х86 процах. С остальным в сад. Так мс решил, в своих "рекомендациях".
> С остальным в сад. Так мс решил, в своих "рекомендациях".А потом эти редмондские фаготы удивляются когда их НАВЯЗЧИВОГО ВТЮХИВАНИЯ какой-то там "защиты от проблем" кто-то опасается. Наверное потому что очень уж напоминает поведение крышевика ларьков, навязчиво предлагающего защиту от проблем.
А вы знаете ФС, более совместимую между всеми ОС, чем FAT с его 35-ти летней историей?Про "самозарождение" secure boot я даже комментировать не буду. По ссылке выше все настолько понятно разжевано (на тему что это такое, зачем нужно и как появилось), что смысла цитировать это нет. В конце концов, если ничего не помогает - почитайте оригинальную спецификацию UEFI. Она открыта.
> Почитайте наконец секцию про Secure Boot тутА еще можно почитать заметки Мэтью Гарретта как он прыгал по граблям со всем этим уефанством. Когда то установка операционки девайс убивает, то девайс готов запускать на выбор целый виндус и редхат, etc.
> Никак. Используйте Coreboot какой-нибудь или еще что.Ну вот о том и речь. Выглядит как защита, а по факту - лапша на уши. Чем и плохо, собственно. Притупляет бдительность путем навешивания лапши на уши. А потом чего доброго будет использовано для взломов.
> если она хранит ключи в внешнем TPM-модуле - она скажет "очистить"
> и запишет туда ключ, а он ей потом дополнительный ключ будет доставать.Поэтому TPM - еще одна порция лапши на уши. Единственный вариант когда оно может быть trusted - это если сие сделано на каком-нибудь микроконтроллере с открытой фирмварой. В остальных случаях это еще порция лапши на уши. Мало ли что там этот модуль делает и какие у него бэкдоры есть.
> А еще Computrace может некий код выполнять и что-то делать
Ну так бэкдор же откровенный. При том не подконтрольный толком тому лоху который его себе впендюривает.
> не надо распространять мифы, что Secure Boot это злоЭто зло. Потому что вешает много лапши на уши, разводя много бла-бла про какую-то там секурити, при том что эти бла-бла НИЧЕМ НЕ ПОДКРЕПЛЕНЫ. А навешивание лапши на уши лохам это зло. И гемор с загрузкой легитимных ОС - тоже.
> и там "вшита левая функциональность". Она и без
> него вшита в места, которые вы выключить не можете.Для начала секурбут с нахрапом втюхивается как некая защита от проблем, а по факту - больше похож на форму ларечного рэкета от MS с мутными типами которые фиг поймешь на кого работают. Какая там безопасность когда возле тебя тусует парочка мутных рэкетиров - большой вопрос.
> Убираете ключи и левый код не запустится.
Кто это гарантирует? Какой-то мутный многометровый проприетарный блоб, делающий невесть что? В котором по закону жанра найдут "случайно забытый инженерный ключ" или "досадную уязвимость".
> (кроме того, я думаю, если MS подпишет ключами какую-нибудь малварь
Они уже подписали парочку милых вещиц - stuxnet и duqu. Боевые комплексы саботажного программного обеспечения, если вы вдруг не в курсе. Ну да, все обтяпано так что микрософт вроде как не очень виноват. Но факты таковы что их валидная цифровая подпись - налеплена на боевое программное обеспечение, которое предназначено для выведения из строя инфраструктуры, промышленного шпионажа и проведения атак.
> точно заранее узнаете)
Так я уже в курсе про валидные подписи stuxnet и duqu. По поводу чего доверять мелкомякоти и их ключам ни разу не собираюсь. И даже тем кто интегрирует их ключи. Если кто засыпался на валидных цифровых подписях на боевой малвари - это все, пиндык доверию, особенно когда его с нахрапом навязывают на уровне дефолтных ключей UEFI.
> А вы переворачиваете ситуацию с ног на голову и вините Secure Boot
> как источник угроз.В такой реализации да, он - источник угроз. Потому что врет о своем функциональном предназначении и нет внятных возможностей проверить что этот мутный тип будет делать именно то что и заявлено, а не что-нибудь другое, втирая очки, отвлекая внимание и являясь скрытым плацдармом для проведения неожиданных атак. Как раз очень круто - втереть про то что может выполняться только подписанный вами код. А потом окажется что не только он, но и код тех то знает какой-нибудь небольшой секрет. Но кто ж будет это подозревать, если со всех сторон пиндят что секур, секур! Только ваши ключи, блаблабла. А возможности проверить что только наши - нет. Потому что многометровый мутный блоб. От господ, сто лет как попавшихся на вещах по типу AWARD_SW.
> В то время как именно он *дает* вам возможность предотвратить запуск
> левого "боевого программного обеспечения".Не, не так. Оно втирает очки что якобы дает такую возможность. А вот насколько это по факту будет именно так как обещали - фиг проверишь! Исходников же нету. А биосописателей не раз ловили на инженерных паролях и даже бэкдорах в BMC (как у супермикры). Да и микрософт активно впаривающий свои ключи отличился подписыванием боевого саботажного ПО.
> А вот без него как раз - запускай кто угодно что угодно.
Там по крайней мере не вешают лапшу на уши и у пользователей не формируется каких-то ложных, ничем не обоснованных ожиданий. А тут втирают очки внаглую с нахрапом про секурность. При полном отсутствии пруфов этой самой секурности.
> Я ж не предлагаю вам на 100% верить, что включение Secure Boot
> обезопасит вас ото всех угроз.Вы предлагаете мне верить что оно от чего-то обезопасит. Вот я и спрашиваю: а как проверить что оно себя ведет именно вот так?
> Но в текущей реализации Secure Boot только может безусловно увеличить безопасность
А я вижу нахрапистое втирание очков с козырянием безопасностью. А попутно - рэкет с узакониванием позиции микрософта в роли решателя того кто допущен к кормушке, много ничем не подкрепленных обещаний, проблемы с запуском легитимных операционок и прочая. И почему все это хорошо - мне совсем не очевидно. Особенно если Б. Франклина вспомнить...
> образом его включение не может скомпрометировать безопасность по сравнению с его
> выключением или отсутствием -Вообще-то может. Путем формирования каких-то там ожиданий, которые по факту ничем не подкреплены. Ну и результирующее ослабление бдительности всех причастных. Что позволяет проводить ВНЕЗАПНЫЕ атаки которые никто для начала не ожидает. Ну в общем еще один SSL.
> или будьте добры, приведите такой пример.
А что - пример? Притупление бдительности под действием сказок про секурность и как результат недооценка угроз буткитов - вполне возможны вроде. Да и у микрософтушки появляются рычаги глобального давления на производителей железа и манипулирования рынком софта, что вообще целая глобальная угроза.
> ключ" (наверное, в MS не идиoты сидят и проверили, что функциональность
> работает, а не просто пункт в меню во время сертификации?).Да, duqu и stuxnet эти НеИдиoты проверили. Значит того хуже: заведомые саботажники и диверсанты будут нам про безопасность рассказывать и обеспечивать нашу безопасность. Это так круто.
А так я видел как они софт и драйвера проверяют на logo. Называя вещи своими именами - никак. Формально смотрят что требоания выполнены и ... все. Поэтому все эти сертификации гроша ломаного не стоят. Чтобы кого-то там завернули - он должен настолько сказочно лохануться, что это заметят даже малокомпетентные индусы. Для этого талантище надо иметь.
> Вы предлагаете мне верить что оно от чего-то обезопасит. Вот я и спрашиваю: а как проверить что оно себя ведет именно вот так?Я не вижу смысла отвечать на такой агрессивный поток сообщений об одном и том же :)
Отвечу на этот "главный вопрос".Secure Boot - это спецификация, описывающая, как с помощью криптографии на открытом ключе гарантировать, что загружается только подписанный код и не запускается левого. (подписанный лично вами, для примера). Это отличная идея, отличная настолько же, насколько отличной идеей является подписывание модулей ядра в вашем дистрибутиве и подписывание пакетов дистрибутива, чтобы гарантировать, что вам их не подменили при скачивании.
Спецификация - это спецификация, она по определению (да, я понимаю что бывают дыры в криптографии и тд, но не будем еще и в это углубляться) ведет себя "именно вот так". Вести себя иначе может конкретная реализация. Вы можете написать свою реализацию UEFI фирмвари, или посмотреть сорцы открытого TianoCore и убедиться, что криптография реализована корректно и что никаких левых ключей нет.
Убедиться, что в абстрактной бинарной реализации UEFI все корректно вы не можете (хотя есть много оснований верить, что это так. Например, попытались загрузить левый код - получили ошибку. Подписали, вставили ключ - загружается. Так что остается разве что вариант "лишнего ключа"). Но там можно скрыть лишний код кучей других более серьезных способов. В том числе теоретически возможно и так, чтобы он выполнялся и после загрузки ОС. Поэтому я не вижу причин обвинять Secure Boot в какой-либо угрозе безопасности. Есть возможность использовать свободную фирмварь - используйте. Можно там включить Secure Boot (в TianoCore можно) - еще лучше! Безопаснее.
Причины нападать на бинарную фирмварь я вижу, на Secure Boot - никакого. Это просто опциональная возможность еще в одном месте проверять код.
> недооценка угроз буткитов - вполне возможны вроде
Не надо недооценивать. Даже Secure Boot можно выключить в одно движение. Никакая защита не является абсолютной. Но возможность ограничить загружаемый код подписью - лучше, чем отсутствие такой возможности. Да, даже с ключами MS. Я без понятия деталей истории со stuxnet и причем там вообще MS и Secure Boot, но я знаю, что среднестатическому пользователю угрожают совсем другие вещи и другие малвари. И среднестатическая малварь не будет подписана каким-либо ключом, который есть у кого-то в фирмвари.
Название TPM такое же ложное, как и SD.
Только ССЗБ доверяют TPM.
> зы. даешь UEFI с QR-кодами и веб-сервером!накаркаете...
>даешь UEFI с QR-кодами и веб-сервером!и настройками в облаках!
Старший брат теперь будет старшим... А кто-нибудь знает, когда Леннарт собирается выпустить свой дистрибутив?
А зачем? Он круче. скоро все дистрибутивы будут "его".
GNU/Linux плавно перетечет в Леннарт/Линукс
ну или systemd/linux
> А зачем? Он круче. скоро все дистрибутивы будут "его".
> GNU/Linux плавно перетечет в Леннарт/Линукс
> ну или systemd/linuxВы так говорите, как будто это что-то плохое!
в принцыпе я то не против.
проблема в том что это происходит почти безальтернативно.
и по живому. при том что с качеством говорят проблемы.
а говорят, что из бабки девочку сделали
Разумеется, плохое. Когда монополия была чем-то хорошим для конечного пользователя?
В марте 2014-го обещали.
>Утилиты systemctl-cat и systemctl-edit позволят отобразить и отредактировать файл конфигурации выбранного юнита (например, "systemctl-cat apache2.service"), без необходимости определения пути.Господи, спаси линукс от этого графоманствующего ламера!
И да, считать cat утилитой для отображения текстовых файлов на экран - это все равно, что считать плоскогубцы девайсом для раскалывания орехов. То есть, можно, конечно, но не для этого придумывалось.
Странно, в man'е написано, что для вывода файлов: "cat - concatenate files and print on the standard output", да, stdout не экран, но про экран никто и не говорил, вероятно в оригинале было что-то типа "print", а не "отобразить"... Нашли к чему придраться, при таком-то списке фитч.
Фич? Вы хотели сказать "велосипедов"?
Или в списке действительно есть что-то инновационное?
Всё-таки ключевое слово здесь "concatenate", а не "print".
> слово здесь "concatenate", а не "print".Не-не, Дэвид Блэйн, если Леннарт сделает _конкатенацию юнит-файлов, то они ж резко станут длиннее 5 строк. Ц.А. будет потеряна, дизайн гоул профукан. </>
Да ладно, скоро он сделает systemctl-editd и все будет хорошо.
> Да ладно, скоро он сделает systemctl-editd и все будет хорошо.systemctl-regedit ты хотел сказать?
>> Да ладно, скоро он сделает systemctl-editd и все будет хорошо.
> systemctl-regedit ты хотел сказать?Тьфу-тьфу...
emacsd
Это замечательная новость! Наконец-то замена TrustedGRUB.
TrustedGROB
Какое-то безумие. Если бы мне лет 10 тому назад сказали, что удар придёт именно с этой стороны..
какой такой «удар»?P.S. Насчёт безумия - согласен) шизофазия какая-то.
> какой такой «удар»?
> P.S. Насчёт безумия - согласен) шизофазия какая-то.UEFI же. Мелкософт долго наверное думали, как поднагадить всем прочим ОС.
Означает ли это что я смогу скомпилить свою версию systemd и подписать каким-то специальным ключом (на сколько я понимаю в этом суть UEFI Secure Boot) и это будет работать или что в составе systemd появится проприетарный закрытый загрузчик?
> Означает ли это что я смогу скомпилить свою версию systemd и подписать
> каким-то специальным ключом (на сколько я понимаю в этом суть UEFI
> Secure Boot) и это будет работать или что в составе systemd
> появится проприетарный закрытый загрузчик?Да, вы сможете подписать загрузчик gummiboot своим собственным ключем, добавить этот ключ в фирмварь (в UEFI есть соответствующий пункт), и после этого данная материнка будет соглашаться грузить только этот (и другие подписанные данным ключем) загрузчики.
(по секрету - вы это можете сделать и сейчас. Просто подписывать надо shim, а он будет запускать grub. С gummiboot просто упрощают цепочку - его подписываем, он же и загружает ядро. Но хозяин барин, если нужно - подписывайте сейчас. Инструменты тут: https://github.com/rhinstaller/pesign).
> материнка будет соглашаться грузить только этот (и другие подписанные данным ключем)
> загрузчики.Правда проверить что это именно так - вы не сможете. Это "мамой клянус" обеспечивает многометровый проприетарный блоб. Поэтому если так окажется что блоб слегка приврал в пользу АНБ и прочих мелкософтов - будет довольно наивно удивляться. AWARD_SW мы уже видели. Ну и мастер-ключ для вламывания на любой комп смотрелся бы логично...
Поддерживаю. Сколько можно заставлять сотрудников АНБ хранить потертую бумажку с паролями от всех БИОСов? Не зря UEFI так шомполом всем вендорам заталкивают.
Через сколько десятилетий все это начнет работать нормально?
Вижу столько негатива, вот только не могу понять почему? в чем причина? обосновано можно на пальцах объяснить, чтоб потом на этот пост ссылаться всегда?
Так плохая программа же. Никакого негатива, только заслуженное презрение.
> Вижу столько негатива, вот только не могу понять почему? в чем причина?В том что Поттеринг посмел осознать ряд проблем администрирования и постарался их разрулить. А хотя-бы и послав в пешее эротическое кучу костыльных устаревших подходов создающих проблемы, по типу скриптов sysv init.
> Вижу столько негатива, вот только не могу понять почему? в чем причина?
> обосновано можно на пальцах объяснить, чтоб потом на этот пост ссылаться
> всегда?Ну, проблема в общем-то в том, что от него все устали. Устали потому что он, по мнению большого количества людей, заменяет нужные работающие вещи на не нужные и не работающие.
Многие плевались на PulseAudio, когда его проталкивали. Я сам до сих пор его выпиливаю из систем, что ставлю друзьям. Почему - почитайте мои посты здесь же, небось не сложно отыскать.
А теперь он написал то, что сначала планировалось как система инициализации, а теперь превратилось в таблетку ото всех болезней, и он активно пытается придать своему продукту вид хорошего востребованного поделия, чтобы на него завязывались недальновидные разработчики.
Да и вообще, он больше упор делает на внедрение новых фич, нежели на отладку уже написанного кода. Вот о чём стоит подумать: окружение GNU/Linux писалось и отлаживалось десятилетия - и результатом этой работы была стабильно работающая среда. А он тут за четыре года налабал среду, в которой переписал чуть ли не всё, да к тому же навесил дополнительного функционала... Когда ему, казалось бы, всё это отлаживать?
Он не делает ничего принципиально нового. Нахватался парнишка разных идей оттуда-отсюда. Наспех реализовал какие-то реализации - и теперь вовсю трубит, будто шагает впереди планеты всей.
Задумайтесь: Pulse он забросил, а нам с ней теперь жить. SystemD он теперь внедряет, понимаешь ли.
PS: очень устал, да и накипело
Да кстати, хочу вдогонку сказать одну вещь.Есть два способа создать программный комплекс. В первом случае он делается настолько простым, что в нём явно нет изъянов. Во втором случае он делается настолько сложным, что в нём нет явных изъянов.
В далёком 2007-м году, когда никаким systemd ещё даже не воняло, уже были вполне себе серьёзные загрузчики, которые могли проверять чексуммы/ключи для отдельных чанков файловой системы, и хрен ты туда подсунешь кейлоггер без физического доступа к машине. Зачем нужно было городить весь этот цирк?
>В далёком 2007-м году, когда никаким systemd ещё даже не воняло, уже были вполне себе серьёзные загрузчики, которые могли проверять чексуммы/ключи для отдельных чанков файловой системы, и хрен ты туда подсунешь кейлоггер без физического доступа к машине. Зачем нужно было городить весь этот цирк?NIH-синдром. RedHat хочет закрепиться в определенном сегменте рынка. Да пусть разрабатывают, главное чтобы умный народ проверенный инструментарии не выкидывали, т.к. приведет к монополии и неявному вендор-локу (да-да, можно все форкнуть, знаю..).
Это не NIH-синдром, это результат партнёрства редхета и микрософта. По результатам редхет получает часть микрософтовых клиентов с миллиардом денег, а микрософт — свалку костылей похожую на вантуз вместо конкурирующей операционки и лающуюся свору вместо сообщества СПО.
>Это не NIH-синдром, это результат партнёрства редхета и микрософта. По результатам редхет получает часть микрософтовых клиентов с миллиардом денег, а микрософт — свалку костылей похожую на вантуз вместо конкурирующей операционки и лающуюся свору вместо сообщества СПО.Хм..это интересно.
>Это не NIH-синдром, это результат партнёрства редхета и микрософта.
А можете вот с этого места подробнее пожалуйста и с ссылками на новости/документы? - Ко мне в криокамеру не поступили эти события :(
>>Это не NIH-синдром, это результат партнёрства редхета и микрософта. По результатам редхет получает часть микрософтовых клиентов с миллиардом денег, а микрософт — свалку костылей похожую на вантуз вместо конкурирующей операционки и лающуюся свору вместо сообщества СПО.
> Хм..это интересно.
>>Это не NIH-синдром, это результат партнёрства редхета и микрософта.
> А можете вот с этого места подробнее пожалуйста и с ссылками на
> новости/документы? - Ко мне в криокамеру не поступили эти события :(Потому что чтобы уловить эти события надо одеть шапочку из фольги для улучшения приёма сообщений из космоса и принять расширяющие создания вещества.
>>>Это не NIH-синдром, это результат партнёрства редхета и микрософта.
>> А можете вот с этого места подробнее пожалуйста и с ссылками на
>> новости/документы? - Ко мне в криокамеру не поступили эти события :(
> Потому что чтобы уловить эти события надо одеть шапочку из фольги для
> улучшения приёма сообщений из космоса и принять расширяющие создания вещества.Ха. А ты поди-опровергни его. )
Собственно, если у нас паранойя, это не означает, что за нами не следят и не стоят против нас заговоры.
>>Это не NIH-синдром, это результат партнёрства редхета и микрософта. По результатам редхет получает часть микрософтовых клиентов с миллиардом денег, а микрософт — свалку костылей похожую на вантуз вместо конкурирующей операционки и лающуюся свору вместо сообщества СПО.
> Хм..это интересно.
>>Это не NIH-синдром, это результат партнёрства редхета и микрософта.
> А можете вот с этого места подробнее пожалуйста и с ссылками на
> новости/документы? - Ко мне в криокамеру не поступили эти события :(можешь считать это оригинальным исследованием, выполненным на базе анализа новостей и разговоров с живыми людьми
> это результат партнёрства редхета и микрософта.Именно так. Коротко, ясно и по существу. Между M$ и RedHat определённо существует соглашение. Обе стороны это признают (правда, не спешат делиться деталями). РедХат запускает апликухи Моно на своём ОпенШифте, Микрософт запускает RHEL на своей Азуре, RHEL единственная ОСь, подписанная ключами M$...
>> это результат партнёрства редхета и микрософта.
> Именно так. Коротко, ясно и по существу. Между M$ и RedHat определённо
> существует соглашение. Обе стороны это признают (правда, не спешат делиться деталями).
> РедХат запускает апликухи Моно на своём ОпенШифте, Микрософт запускает RHEL на
> своей Азуре, RHEL единственная ОСь, подписанная ключами M$...То есть RHEL - ОСь, а Ubuntu и Suse - не считаются?
> То есть RHEL - ОСь, а Ubuntu и Suse - не считаются?А что, M$ подписала их загрузчики? Я не в курсе. Если подписала, то они тоже ОСи (в глазах M$), но ведь остаются другие...
>> То есть RHEL - ОСь, а Ubuntu и Suse - не считаются?
> А что, M$ подписала их загрузчики? Я не в курсе. Если подписала,
> то они тоже ОСи (в глазах M$), но ведь остаются другие...То есть не в курсе, но обязательно надо теорию заговора вбросить? Ещё когда убунта покупала подпись у МС эту тему обсосали со всех сторон. Если что - загрузчики заглушки с подписью для убунты или того же RHEL (и Fedora, если уж на то пошло) имеются в открытом доступе и представляют из себя простейшую минимальную затычку для запуска grub.
Но я мешать не буду, продолжайте рассказывать о том как красношляпа и МС вступили в заговор чтобы сделать linux plumbing layer более однородным^W^W поработить мир дистрибутивов.
> То есть не в курсе, но обязательно надо теорию заговора вбросить?Обязательно. А как ещё развлекаться, если не вбрасывать и не вестись на чужие вбросы? Вы слишком серьёзны, мой виртуальный собеседник.
На самом деле, тот факт, что ещё кто-то прогнулся под Микрософт, никак не опровергает гипотезу о сговоре. Микрософт является врагом опенсорса и всё, к чему она прикасается, нечисто.
>> То есть не в курсе, но обязательно надо теорию заговора вбросить?
> Обязательно. А как ещё развлекаться, если не вбрасывать и не вестись на
> чужие вбросы? Вы слишком серьёзны, мой виртуальный собеседник.Вбрасывать тоже можно по-разному. Вкидывать дезинформацию - засорять ресурс. Вкидывать критику по существу - провоцировать интересные срачики.
согласен на 100 %
Если это действительно было, значит это и есть до сих пор, только почему ментейнеры выбирают systemd, а не эти крутые программы, которые уже давно есть ?Ответ прост -- им намного легче поставить systemd и не мучиться, и не искать все эти программы по разным углам, налаживать их совместную работу между собой с помощью скриптов и постоянно самостоятельно это всё поддерживать в работоспособном состоянии.
systemd можно рассматривать как комплекс утилит, где его создатели несут ответственность, как за работу каждой утилиты в отдельности, так и за связь их между собой.
Вообще у Линукса такая репутация, что в нём постоянно надо ковыряться, чтобы что-то наладить, чтобы исправлять какие-то ошибки, чтобы заставить что-то работать. systemd всё сильно облегчит, идея systemd -- чтобы всё работало сразу из коробки.
Недавно было интервью с Солнцеликим, где Он сказал о системде:>it's the job of the distro to pick a release, integrate it into their OS, stabilize it when it is needed
То есть, с точки зрения мейнтейнеров "поставить и не мучиться", "не налаживать и не поддерживать" не получится. Поживем - увидим, конечно, но что-то мне подсказывает, что кое-кого ждет большое разочарование в этом плане.
>systemd можно рассматривать как комплекс утилит, где его создатели несут ответственность
Ну-ну. Лицензию почитайте. Ответственность они несут, лол.
>Вообще у Линукса такая репутация, что в нём постоянно надо ковыряться, чтобы что-то наладить, чтобы исправлять какие-то ошибки, чтобы заставить что-то работать. systemd всё сильно облегчит, идея systemd -- чтобы всё работало сразу из коробки.
С точки зрения пользователя все и так работало из коробки уже много лет, системда тут ничего нового не принесет. Или у вас есть офигительная история, как вам приходилось ковырять инит-скрипт на баше?
>С точки зрения пользователя все и так работало из коробки уже много лет, системда тут ничего нового не принесет.systemd создает очень хреновую проблему - если что-то валится, то просто на коленке во время обеда систему поднять не получится
>Или у вас есть офигительная история, как вам приходилось ковырять инит-скрипт на баше?
мне приходилось, правда я не совсем обычный пользователь: и в ядрах приходилось копаться (почти всегда из-за драйверов), а сейчас например у меня X11 пропатчен (нужны были доп. опции для старта).
> То есть, с точки зрения мейнтейнеров "поставить и не мучиться", "не налаживать и не поддерживать" не получится. Поживем - увидим, конечно, но что-то мне подсказывает, что кое-кого ждет большое разочарование в этом плане.Согласен, что ещё не доделано, но его ведь развивают постоянно, не известно, что будет в будущем.
"Ну-ну. Лицензию почитайте. Ответственность они несут, лол."
Про ответственность я имел ввиду другое. Конечно я понимаю, что в СПО никто и никому ничего не должен, значит и нет ответственности, но я главным образом подразумевал то, что любые ошибки пытаются исправить, если в остальных проектах их авторы исправляют ошибки только самих программ и развивают эти программы, то тут всё развивается в комплексе -- все утилиты развиваются одновременно и с учётом зависимостей между ними, любые несостыковки должно исправлять сообщество systemd, все результаты тестируются тоже совместно в результате качество продукта повышается.
Вообщем про ответственность может быть я не правильно выразился."С точки зрения пользователя все и так работало из коробки уже много лет, системда тут ничего нового не принесет. Или у вас есть офигительная история, как вам приходилось ковырять инит-скрипт на баше?"
Ну я главным образом сказал о системе в целом.
Из коробки работает не всё и конечно у меня есть такие истории, например, на моей ноутбучной видеокарте(nvidia) не работал OpenCL и и мне пришлось вручную всё настраивать.
Сами же Nvidia жаловались на недоработки в Линукс системах из-за которых у них возникают трудности в развитии всяких технологий. Я так понимаю, что EGL им облегчит жизнь, который придёт вместе с Wayland`ом и Mir`ом. Но если Wayland и Mir наводят порядок в одной сфере, то systemd в другой. Например у меня были проблемы - после обновления дистрибутива некоторые функции переставали работать и приходилось заново настраивать и вот продуманная система юнитов в systemd должна решить такие проблемы обновления(ну или часть их). У меня ещё есть притензии к стабильности некоторых моментов, но они скорее всего не относятся к systemd. Это например то, что надо сделать транзакционное обновление системы, чтобы сбой не смог всё запороть, а то у меня было так, после чего компьютер вообще перестал загружаться и пришлось самому вручную переустанавливать(обновлять).А вообще в целом у меня всё работает хорошо, но читая чужие комментарии, вижу, что кто-то постоянно в чём-то там ковыряется, у одного одно не работает, у другого - другое и т.д. И вот они все всё это настраивают своими руками.
>я главным образом подразумевал то, что любые ошибки пытаются исправить, если в остальных проектах их авторы исправляют ошибки только самих программ и развивают эти программы, то тут всё развивается в комплексеТавтология какая-то. Ну да, авторы программы исправляют свои ошибки, по отношению к системде это утверждение тоже справедливо*. Ну и что с того?
*на самом деле, не совсем: помните, тот эпичный патч с командной строкой ядра и debug от сиверса?
>второй абзац
К чему все это? Причем здесь системд?
>А вообще в целом у меня всё работает хорошо, но читая чужие комментарии, вижу, что кто-то постоянно в чём-то там ковыряется, у одного одно не работает, у другого - другое и т.д. И вот они все всё это настраивают своими руками.
В высшей степени наивно полагать, что системда что-то здесь изменит. Ну не существует золотой пилюли от всех болезней сразу.
> Вообще у Линукса такая репутация, что в нём постоянно надо ковыряться, чтобы
> что-то наладить, чтобы исправлять какие-то ошибки, чтобы заставить что-то работать. systemd
> всё сильно облегчит, идея systemd -- чтобы всё работало сразу из
> коробки.Где профитЪ?
> Ожидается минимальная поддержка средств управления межсетевым экраном в привязке к сервисам, а не номерам портовотлично
> Создание средств для проведения системного аудита, например, для ведения полного лога системных вызовов, связанных с /etc/passwd. Добавление средств аудита в journald и реализация в audit-tools возможности чтения сохранённых в journald логов;Теперь он будет изобретать собственный греп по бинарным логам. Они же теперь бинарные, а надо же как-то ими пользоваться.
Да, grepd всем нам не хватает. И еще awkd и sedd.
>> Создание средств для проведения системного аудита, например, для ведения полного лога системных вызовов, связанных с /etc/passwd. Добавление средств аудита в journald и реализация в audit-tools возможности чтения сохранённых в journald логов;
> Теперь он будет изобретать собственный греп по бинарным логам. Они же теперь
> бинарные, а надо же как-то ими пользоваться.Вот только бинарныая в логах только метадата, по логфайлам так же отработает и grep и awk и sed. Но разбираться в теме сейчас не модно, сейчас модно повторять что-то где-то услышанное, причём чем меньше знаешь о сабже критики, тем лучше.
>Ожидается минимальная поддержка средств управления межсетевым экраном в привязке
>к сервисам, а не номерам портов. Например, вместо определения правил доступа к
>80 порту, можно будет привязать правила к http-серверу apache, без оглядки на
>то, на каком порту он принимает соединения.Из процесса апача с mod_perl / mod_php / троянским so-модулем форкнется какой-нибудь "потомок", откроет свой сокет - и ему sysD тут же порт в файрволле откроет? Вот это сервис! Классно придумали.
>>Ожидается минимальная поддержка средств управления межсетевым экраном в привязке
>>к сервисам, а не номерам портов. Например, вместо определения правил доступа к
>>80 порту, можно будет привязать правила к http-серверу apache, без оглядки на
>>то, на каком порту он принимает соединения.
> Из процесса апача с mod_perl / mod_php / троянским so-модулем форкнется какой-нибудь
> "потомок", откроет свой сокет - и ему sysD тут же
> порт в файрволле откроет? Вот это сервис! Классно придумали.Может там прописывать возможный порт, или диапазон портов в конфигурилке необходимо.
Все равно не вижу необходимости. Уже сейчас можно iptables настроить в привязке к процессу (подробностей не помню, пока нет необходимости).
Ну разве что "типичные" настройки давать всем. А там кто сам подправит, а кому то придется в RedHat обратится за помощью ;)
> Ожидается минимальная поддержка средств управления межсетевым экраном в привязке к сервисам, а не номерам портов. Например, вместо определения правил доступа к 80 порту, можно будет привязать правила к http-серверу apache, без оглядки на то, на каком порту он принимает соединения.Админы поколения MTV нынче и так тупые донельзя, а теперь от них и вовсе OSI скроют (а точнее ее частный случай - TCP/IP)
Сборище хейтеров и неосиляторов
Ты какой-то слишком агрессивный. Поменьше агрессии и негатива, плиз.
Ну, это скорее леннартовские неосиляторы не сумели настроить файрволл и научиться читать текстовые логи.
/itt белки истерички.
да прибудет тот день когда тыщи дистров начнут отличаться только картинкой десктопа! вангую чтобы поц после системды взялся за единый пакет манагер!
Packaged. omen!
systemd-packaged, блджад
>тыщи дистров начнут отличаться только картинкой десктопа!Да Поцтер тут не первый, много их уже. Первым был Попов?
Сплошные контейнеры и изолированные среды, а чем тогда будет ОС заниматься - только запуском systemd?
И еще бэкдоров АНБ.
Наоборот, ОС будет в виртуалке под софтом от АНБ.
systemd теперь будет загружать UEFI-биос как одну из своих подсистем?
> systemd теперь будет загружать UEFI-биос как одну из своих подсистем?Вы не понимаете, оно сжирает linux-инфраструктуру, Майкрософт оно не трогает.
>> systemd теперь будет загружать UEFI-биос как одну из своих подсистем?
> Вы не понимаете, оно сжирает linux-инфраструктуру, Майкрософт оно не трогает.Ну так ничего удивительного, каждый одеяло на себя тянет. И RH здесь не исключение.
Другое дело, что "осадочек" то накапливается.
>>> systemd теперь будет загружать UEFI-биос как одну из своих подсистем?
>> Вы не понимаете, оно сжирает linux-инфраструктуру, Майкрософт оно не трогает.
> Ну так ничего удивительного, каждый одеяло на себя тянет. И RH здесь
> не исключение.
> Другое дело, что "осадочек" то накапливается.Red Hat против Линукса? Удивительного ничего нет. Хорошего еще меньше.
Меня одного смутило упоминание high dpi экранов при рассказе о возможностях системы инициализации? И где тогда поддержка HTML5?
После включения поддержки high-DPI мышек в systemd - это уже не так шокирует.
В udev. Но это уже звучит не так интересно, да?
udev - часть systemd
> udev - часть systemdНадеюсь что это будет именно так и вам придется съесть этот факт.
У нас уже есть рабочий eudev - равноценная замена udev и без systemd.
> У нас уже есть рабочий eudev - равноценная замена udev и без systemd.Ну вот и скатертью дорожка к этим гентушным пЫонерам.
С лета использую eudev на всех системах.Полёт нормальный!
Какое отношение имеет udev к dpi у мышки? ИМХО кроме драйвера мыши и программы ее использующей это никого касаться не должно.
> Какое отношение имеет udev к dpi у мышки? ИМХО кроме драйвера мыши
> и программы ее использующей это никого касаться не должно.Ну, мышевозилам http://who-t.blogspot.ru/2014/12/building-a-dpi-database-for... не достат плюгнплюя в мышых, они подпирают сей недостаток переписью мышей.
И кто же, как не ude^Wlibsystemd-mouse-hwdb -- именно то место, куда надо сложить добытое непосильным трудом?!
Тс-с-с-с, тебя сейчас хейтером и неосилятором обзовут.
> Меня одного смутило упоминание high dpi экранов при рассказе о возможностях системы
> инициализации? И где тогда поддержка HTML5?Там есть реализация консоли в пространстве пользователя
http://www.opennet.me/opennews/art.shtml?num=38543Это позволяет теперь поддержать удобную консоль даже на high dpi устройствах (сейчас оно по факту неюзабельно, т.к. возможности ядра по рендерингу шрифтов сильно ограничены и усложнять код в ядре никто не собирается).
Поддержка HTML5 - это ваши фантазии :) Требуйте это от lynx вместо systemd! И будет поддержка в этой консоли.
Всё это так вкусно, что аж слюнки текут. Молодцы разработчики, скорее бы всё это реализовали. А там и до микроядра недалеко.
Кто-нибудь может описать реалистичное применение этого идиотизма с перезагрузкой без перезагрузки? Как можно использовать эту фигню, которая оставляет открытыми файлы и сокеты, отдает их systemd, а потом принимает обратно?Mysql приостановить на пару минут и потом снова запустить? Соединения все позакрываются по таймаутам. Текстовый редактор приостановить, а потом продолжить редактирование? Так уже есть CTRL-Z, да и заново открыть несколько текстовых файлов - доли секунды.
Админишь локалхост?
Да нет, поэтому и не понимаю. В энтерпрайзе это вообще какой-то бред. Там если сервисы запустят, то они работают, пока конфигурацию не поменяют. А для изменения конфигурации все равно нужно все закрывать и переоткрывать.
> Кто-нибудь может описать реалистичное применение этого идиотизма с перезагрузкой без перезагрузки?Ну вот так - сделать рестарт сервера без сброса пользователей, например. Реально это требует нефиговой поддержки в коде сервера, но если системный стартер подыграет - авторам сервера не придется кодить кучу не совсем простой логики, которая без такой поддержки со стороны системы делается только изрядным местечковым костылем.
>> Кто-нибудь может описать реалистичное применение этого идиотизма с перезагрузкой без перезагрузки?
> Ну вот так - сделать рестарт сервера без сброса пользователей, например. Реально
> это требует нефиговой поддержки в коде сервера, но если системный стартер
> подыграет - авторам сервера не придется кодить кучу не совсем простой
> логики, которая без такой поддержки со стороны системы делается только изрядным
> местечковым костылем.Что есть "рестарт сервера"? Просто на ровном месте все перезапустить - это к чему? Конфигурация если поменялась, то в подавляющем количестве случаев - нужно все переоткрывать все равно.
>> Кто-нибудь может описать реалистичное применение этого идиотизма с перезагрузкой без перезагрузки?
> Ну вот так - сделать рестарт сервера без сброса пользователей, например. Реально
> это требует нефиговой поддержки в коде сервера, но если системный стартер
> подыграет - авторам сервера не придется кодить кучу не совсем простой
> логики, которая без такой поддержки со стороны системы делается только изрядным
> местечковым костылем.libd-systemd
>> Кто-нибудь может описать реалистичное применение этого идиотизма с перезагрузкой без перезагрузки?
> Ну вот так - сделать рестарт сервера без сброса пользователей, например. Реально
> это требует нефиговой поддержки в коде сервера, но если системный стартер
> подыграет - авторам сервера не придется кодить кучу не совсем простой
> логики, которая без такой поддержки со стороны системы делается только изрядным
> местечковым костылем.Смысл придумай.
Там где нужно, оно и так перезапускается естественным путем. Пример sshd перезапускается без прибивания дочерних процессов. И никаких костылей и у Поттеринга разрешения спрашивать не надо.
Все что сумел придумать - поощрение криворуких программеров. В демоне утечка памяти? А не парься, просто сбрось текущие данные на диск и перезапустись через системд. Авось память освободится.
> Все что сумел придумать - поощрение криворуких программеров. В демоне утечка памяти?
> А не парься, просто сбрось текущие данные на диск и перезапустись
> через системд. Авось память освободится.systemd в роли garbage collector? А ведь ты прав в некотором смысле.
> Все что сумел придумать - поощрение криворуких программеров. В демоне утечка памяти?
> А не парься, просто сбрось текущие данные на диск и перезапустись
> через системд. Авось память освободится.В реальной жизни мемликов реально полно (да, программисты тоже люди), и рестартить сервис даже при обновлении бывает очень накладно. Так что эта тема действительно имеет право на жизнь.
> Кто-нибудь может описать реалистичное применение этого идиотизма с перезагрузкой без перезагрузки?
> Как можно использовать эту фигню, которая оставляет открытыми файлы и сокеты,
> отдает их systemd, а потом принимает обратно?systemd-init(pid 1) слинкован с кучей хдама, начиная от glibc и заканчивая... , ну, скажем полуэкт. Реалистичненько: перезапуск pid-1 без перезагрузки! Сервис!!
>> Кто-нибудь может описать реалистичное применение этого идиотизма с перезагрузкой без перезагрузки?
>> Как можно использовать эту фигню, которая оставляет открытыми файлы и сокеты,
>> отдает их systemd, а потом принимает обратно?
> systemd-init(pid 1) слинкован с кучей хдама, начиная от glibc и заканчивая... ,
> ну, скажем полуэкт. Реалистичненько: перезапуск pid-1 без перезагрузки! Сервис!!В смысле systemd подержит сокеты в то время как systemd перезапускается? А systemd-singularityd Леннарт уже написал, новость была?
> systemd-singularityd Леннарт уже написал, новость была?Еще нет, но мы работаем над этим.
В systemd есть опция при компиляции которая скомпилирует только udev?
Я таки одно не понимаю - почему ядро все ещё не часть systemd? Это явное упущение.
Очевидно потому что Поттеринг переписывает все с нуля, повторяя функционал существующих инструментов. Дак вот чтобы сделать ядро частью systemd, его надо написать с нуля (NIH-синдром же). А написать ядро аналогичное Линукс у Поттера с его то квалификацией и 10 жизней не хватит.
> Очевидно потому что Поттеринг переписывает все с нуля, повторяя функционал существующих
> инструментов. Дак вот чтобы сделать ядро частью systemd, его надо написать
> с нуля (NIH-синдром же). А написать ядро аналогичное Линукс у Поттера
> с его то квалификацией и 10 жизней не хватит.Более того systemd завязан на специфичных функциях glibc, и вообзе жаль что эта бездна поглотила udev
а Таненбаум че на это коментирует, годно не годно?
Он пока что не может вертеться в гробу.
а то какая то шняга непонятная уже
Было -бы очень смешно если бы небыло всё так печально.Взяли бы своё ядро написали и отстали наконец от Линукса и Линкус дистров..
Но нет, засовывают зонд не только в глубь но и ворочят им в разные стороны...
Поттеринг - просто проект АНБ по запихиванию в линукс новых закладок и их унификации через один большой блоб. Старые уже многие поотлавливали, а объяснять зачем нужны еще тысячи вариантов TCP и SSL, да еще сотням создателей разных дистрибутивов - становится все сложнее.Редхат подкармливают деньгами через выгодные контракты от своих фирм, те платят поттерингам и гномостроителям всяким, чтобы те друг на друга вязались все больше, заодно подсаживая всех остальных.
Поттеринг никогда не читал man signal и не в курсе, что есть SIGSTOP/SIGTSTP. :)
Как долго я ждал этого события!До завершения осталось следующее.
Убрать устаревшую и вызывающую проблемы безопасности возможность вызова из systemd скриптов инициализации.
Поместить пользователя в виртуализованное, безопасное для системы окружение, предоставив ему права просителя у systemd.
В рамках обеспечения безопасности потребовать RedHat-у исключения возможности регистрации левых ключей в UEFI Secure boot. Что не должно вызвать такого возмущения как с MS по поводу монополизации рынка ПК. Ведь теперь вы можете поставить не только единственную ОС MS Windows, но так же Linux! Пускай даже если это единственный RH. (Кто еще претендует на тарелку с борщем?)В результате каждый пользователь сможет сделать свободный выбор: поставить платную хорошую версию проприетарного продукта (будь то MS Windows или даже, ура, Linux-RedHat), или поставить диструбутив из гуманитарной помощи (например всеми уважаемый CentOS или несущий просвещение ScientificLinux). Ведь обеспечение всеобщей безопасности должно достигаться безоговорочными превентивными мерами, упреждающими нападки хакеров на драгоценные фоточки пользователя.
Ой, да о чем я! Это всего лишь шаг к светлому будущему, где нет места проблемам людей со взаимодействием с лично-собственническим компьютером. Зачем разделять мировую вычислительную массу на неэффективные ящички, отражающих разве что финансовое благополучие некоторых личностей. Каждый человек сможет получить столько терминалов доступа в мировые облака, насколько хватит креативности его мЫшленья. Кто должен задумываться о том под какой ОС работает его холодильник, микроволновка, утюг и терминал доступа! Даешь развитие равенства, присущее браузерам, в вычислительные средства!
Ядро ! когда они уже добавят в системД ЯДРО !!!! и будет Windows 2
прийдёт майкософт и скажет, извините но этот мальчик работает на нас и всё это наше ! а ваш Линукс - маст дай !!! гоните бабло !
> Разработчики системного менеджера systemd намерены
> Разработчики systemd предлагают расширить
>он рассказал о последних тендерция в разработке systemd и
> - Приоритетным остаётся подход, при котором большая часть подсистем systemd,
>Под впечатлением от концепции Solaris
>целью является обеспечение работы всех инструментов systemd сПоследние директивы: Спасибо лично товарищу Потерингу за 64-бита, звук и USB!!!1
-- http://www.phoronix.com/scan.php?page=news_item&px=GNU-Hurd-...
https://twitter.com/samhocevar/status/562408610182230016/pho...
Ждём новость "В системд включен minix. Ну так, чисто поржать, и для тех кто хочет unix без systemd, а то задрали орать".
Я, кажется, знаю, что получится, когда к systemd наконец прикрутят оконный GUI :)
