В systemd 228 выявлена (http://openwall.com/lists/oss-security/2017/01/24/4) опасная локальная уязвимость, которая позволяет непривилегированному пользователю выполнить свой код с правами root. Выпуск systemd 228 лежит в основе дистрибутива SUSE Linux Enterprise 12 SP2 и также применялся (https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2...) в Ubuntu Touch 15.04. Debian (https://security-tracker.debian.org/tracker/CVE-2016-10156) и RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-10156) проблеме не подвержены, но не исключено, что проблема перенесена в некоторые дистрибутивы, явно не использующие версию 228, в процессе бэкпортирвоания новых возможностей в старые пакеты с systemd.Уязвимость вызвана тем, что выполнение функции touch() приводит к созданию файлов в директории /run с правами 07777 при использовании таймеров systemd. Проблема присутствует (https://github.com/systemd/systemd/commit/ee735086f8670be159...) в кодовой базе systemd только в выпуске 228 и была около года назад без лишней огласки устранена (https://github.com/systemd/systemd/commit/06eeacb6fe029804f2...) в выпуске 229. В примечании указано, что исправленная ошибка может привести к DoS-атаке через исчерпание дискового пространства в разделе через заполнение файла /run/systemd/show-status, созданного с правами 07777.
На это исправление обратили (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-10156) внимание разработчики дистрибутива SUSE, которые пришли к выводу что указанная ошибка не ограничивается отказом в обслуживании и может легко быть использована для получения root-доступа в системе. Выставляемые для файла права 07777 подразумевают не только общий доступ на запись, но и установку на файл suid-бита. Файлы создаются под пользователем root. Адаптировав к данной особенности эксплоит (http://www.halfdog.net/Security/2015/SetgidDirectoryPrivileg...) от похожей уязвимости, исследователям удалось успешно провести тестовую атаку, присвоив произвольному исполняемому файлу права suid root.$ ls -la /var/lib/systemd/timers/
-rwsrwsrwt 1 root root 155 18. Jan 11:37 stamp-fstrim.timer$ /var/lib/systemd/timers/stamp-fstrim.timer /bin/sh -p
# grep bin /etc/shadow
bin:*:15288::::::
URL: http://openwall.com/lists/oss-security/2017/01/24/4
Новость: https://www.opennet.ru/opennews/art.shtml?num=45908
1) для альта неактуально;
2) автор коммита ee735086f8670be1591fa9593e80dd60163a7a2f -- некто lennart@.
В AltLinux вычистили systemd?
В смысле выпилили?
Я тебя наверное огорчу, но любой дистрибутив может работать без systemd. Ну, только если ты не используешь GNOME и его форки, конечно.
> Я тебя наверное огорчу, но любой дистрибутив может работать без systemd. Ну,
> только если ты не используешь GNOME и его форки, конечно.Не любой, любой не может.
Если конечно ты замену юнит-файлам сам писать не будешь, как минимум.
СистемД просто намертво прибит гвоздями к любому почти дистрибутиву.
"Можно" нужно брать в кавычки, так как линукс исходный код - и в нем можно конечно теоретически и свой оффис написать, и свой драйвер и свои иксы с нуля, только вот скилов не хватит.
Gentoo rulez! No systemd by default.
Freebsd его нет даже и не ожидается, а к генте его рано или поздно прибьют гвоздями.
> Если конечно ты замену юнит-файлам сам писать не будешь, как минимум.Debian Jessie, Debian Stretch, полёт без системды нормальный. А ещё как минимум есть Gentoo, Slackware.
> СистемД просто намертво прибит гвоздями к любому почти дистрибутиву.
Я тоже так считал, но у меня почему-то SysVInit и всё работает. Чудеса, не иначе.
> Debian Jessie, Debian Stretch, полёт без системды нормальный.Говори это себе _чаще_, ещё чаще! Пока субж не долетел.
$ apt-cache rdepends libc6 |grep '^ ' -c
15021
$ apt-cache rdepends libsystemd0 |grep '^ ' -c
E: Не найдено ни одного пакета
0
$ _Ещё ожидаем новых встречь с пр.лёня-кодом:
$ apt-cache rdepends udev |grep '^ ' -c
83
$ _>> СистемД просто намертво прибит гвоздями к любому почти дистрибутиву.
> Я тоже так считал, но у меня почему-то SysVInit и всё работает.
> Чудеса, не иначе.Ты просто ещё чего-то не заметил. Следи за новостями _внимательно_.
> $ apt-cache rdepends libsystemd0 |grep '^ ' -c
> E: Не найдено ни одного пакета
> 0Уже которую новость о systemd у меня одна и та же мысль: что у вас за дистрибутив такой?
>> $ apt-cache rdepends libsystemd0 |grep '^ ' -c
>> E: Не найдено ни одного пакета
>> 0
> Уже которую новость о systemd у меня одна и та же мысль:
> что у вас за дистрибутив такой?Debian GNU/Linux "Wheezy" LTS aka oldstable.
https://www.opennet.ru/openforum/vsluhforumID3/109353.html#209 + #347
> libsystemd0Заглушка же, ну.
У меня пульса даже без системды работает.
> Ты просто ещё чего-то не заметил. Следи за новостями _внимательно_.
Я заблокировал установку пакетов с именем *systemd* :) И да, я знаю, что дебьян по умолчанию перешёл на systemd, но я не первый день пользуюсь GNU/Linux и Дебьяном в частности, так что этой заразы у меня нет и не будет.
>> libsystemd0
> Заглушка же, ну.Э, не. Это уже обсуждалось: с libsystemd0 надо развязываться потому, что это заглушка только сейчас. А что там потом в голову Леннарту придёт, кто его там разберёт?
Помните, как с Гномом было, и как после этого в Debian пошли разговоры, чтобы systemd стал умолчательным инитом? Гном-то потом от systemd отпилили, но обсуждение уже как следует разогналось-разогрелось... и вуаля: systemd в Debian по дефолту.
> Я заблокировал установку пакетов с именем *systemd*
Я так тоже поначалу делал. Но очень много пакетов завязаны на libsystemd0, хренова туча хорошего софта принципиально отказалась ставиться. Тот же mpd, который в Jessie собирается с флагом --with-systemd.
Я поначалу, когда Jessie ещё testing-ом был, держал смешанную систему: часть пакетов с Wheezy стояло. Но со временем прекратило работать и это, потому что всё больше пакетов завязывались на libsystemd0, так что с заглушкой пришлось согласиться.
Затем каким-то чудом при обновлении мне стал втюхиваться systemd. Нет, не systemd-sysv, не дефолтным инитом, но сам systemd таки втюхался в систему. А у меня уже не было времени разбираться и спорить. Тогда родилась мысль, что надо бы пакеты с любыми завязками на systemd пересобирать без оных. И сразу вспомнился Devuan.
Некоторое время собирался с силами, время выискивал, и наконец переехал. Сижу теперь на Devuan Ascii, местном тестинге. Очень добротно работает. Как Wheezy некогда.
>> libsystemd0
> Заглушка же, ну."Когда они пришли за мной — уже некому было заступиться за меня."
https://www.opennet.ru/openforum/vsluhforumID3/110249.html#22> У меня пульса даже без системды работает.
Да, у тебя и udev без него работает, мы поняли.
>> Ты просто ещё чего-то не заметил. Следи за новостями _внимательно_.
> Я заблокировал установку пакетов с именем *systemd* :) И да, я знаю,И libsystemd, да? Мужык!!1
Да ты волшебник прям. Можешь в "винде" также прогу "отвязать" от Framework-а? Делай уроки и не выдавай желаемое за действительное.
Да ты что? А если даже введение логина "завязано" на systemd?
> А если даже введение логина "завязано" на systemd?Что несёшь?
Если ты про logind, то: $ man logind
И почитай, для чего он нужен. Но это НЕ логин в систему -_- И потом логин в систему легко исправить путём правки одного файла.
Ты серьезно в этом уверен? А это https://www.opennet.ru/opennews/art.shtml?num=36330 что тогда?
Чему вас только учат? А это https://wiki.debian.org/ru/Systemd#A.2BBB8EMAQ6BDUEQgRL_Debi... как же?
> Чему вас только учат? А это https://wiki.debian.org/ru/Systemd#A.2BBB8EMAQ6BDUEQgRL_Debi...
> как же?Чему тебя только учат! У меня без systemd работает. Правда старнно? И logind нет.
Пруф:
$ apt-cache policy systemd
systemd:
Установлен: (отсутствует)
Кандидат: 232-8
Таблица версий:
232-14 52
52 http://http.debian.net/debian unstable/main amd64 Packages
232-8 500
500 http://mirror.yandex.ru/debian stretch/main amd64 PackagesКстати, да, таки logind теперь в пакете systemd, судя по всему:
$ apt-cache policy logind
N: Не удалось найти пакет logind
> Ты серьезно в этом уверен? А это https://www.opennet.ru/opennews/art.shtml?num=36330
> что тогда?Что несёшь, опять?
> Ubuntu
Ubuntu != Debian
И таки да, в убунте можно сделать ровно то же, что в дебьяне. Например снести к херам systemd и установить SysVInit.
И использовать программы, в которых явно не указана зависимость от systemd? А как же быть с Network Manager-ом, у которого в зависимостях "программа" от Лени указано прямой зависимостью?
> В AltLinux вычистили systemd?В определённых сборках его и не было.
Наверняка используется более лохматая версия системд, либо отключен суид глобально.
> Наверняка используется более лохматая версия системд, либо отключен суид глобально.Промахнулись, см. справа на http://packages.altlinux.org/systemd
Вы когда прекратите в каждой теме свою кривую поделку рекламировать?
> для альта неактуальноАльт сам по себе неактуален.
За себя говорите.
По поводу актуальности. Если бы в альте из коробки запускался Консультант СБИС электронная отчетность и прочий головняк российских предприятий, то был бы очень актуальный дистр.
> По поводу актуальности. Если бы в альте из коробки запускался Консультант СБИС
> электронная отчетность и прочий головняк российских предприятий, то был бы очень
> актуальный дистр.Из коробки - значит нету денег за внедрение. Но в результате оно вообще никак не запускается и никому этот линукс не вперся.
> По поводу актуальности. Если бы в альте из коробки запускался Консультант СБИС
> электронная отчетность и прочий головняк российских предприятий, то был бы очень
> актуальный дистр.Потихоньку прокапываем, но в основном всё-таки стоит спрашивать поставщика (если бы они не работали на OS/2, вряд ли бы стали в первую очередь интересоваться в IBM ведь).
Но вообще см. altlinux.org/замена и до кучи altlinux.org/ЭЦП -- по электронной отчётности тоже есть варианты, при желании пишите на support@ или sales@ (или мне, а там уже сконтачу).
Ну кто же ещё, как не сам дядя Лёня!
> без лишней огласки устранена.
> Debian и RHEL проблеме не подвержены, но не исключено, что проблема перенесена в некоторые дистрибутивы, явно не использующие версию 228, в процессе бэкпортирвоания новых возможностей в старые пакеты с systemd.Поправьте если я неправ, но кажется "бэкпортированием новых возможностей" только указанные двое и занимаются, а остальные тупо берут upstream?
Скорее бы в CentOS 8 уберут это недоразумение.
Вы хотите продолжения тредиции "Новый RHEL?CentOS - новый init"?5 - sys V init;
6 - upstart;
7 - systemd;
8 - ваши варианты?
8 - OpenRC
8 - winlogon.exeя серьёзно.
8 - "Рога и Копыта" или "Кость мамонта".
8 - sinit + runit + svc
> Вы хотите продолжения тредиции "Новый RHEL?CentOS - новый init"?
> 8 - ваши варианты?bsd-like init, тот что когда-то был в Арче.
не понимаю чего тебя минусят, годная штука была на самом деле. все настройки были в одном файле, никаких симлинков и прочего гемороя.
> не понимаю чего тебя минусятпо ходу это не единственная вещь, которую вы не понимаете.
> не понимаю чего тебя минусят, годная штука была на самом деле. все
> настройки были в одном файле, никаких симлинков и прочего гемороя.Потому, что *далее идет обоснование, которые ОНИ все равно не поймут, поднимут на смех, и закидают продуктами кaкашками*
А еще в /etc/rc.d/ файлы запуска/останова программ/сервисов/демонов были в открытом исходном коде - на баше написаны, в то время как systemd - закрытая черная коробка, с пятью строчками открытого кода.
это уже было в rh2.x, так что проехали :))))))
> Скорее бы в CentOS 8 уберут это недоразумение.Откуда такая информация? можно ссылку?
Нет никакой ссылки. Просто кто-то жутко наелся конфет
Дыра в ядре - бывает. Дыра в systemd - криворукость разрабов. Таков двойной стандарт хейтеров.
Ядро - необходимость, системда - <придумайте сами>.
Занятие для кота, который не очень занят.
Микроядро — необходимость, а линукс — всего лишь суровая реальность.
> Ядро - необходимость, системда - <придумайте сами>.придуманная необходимость, под лозунгом "долой зоопарк, даешь унификацию". И ведь все задумывалось как система инициализации, а сейчас эта срань плавно подбирается к ядру, и вот вот его поглотит.
>> Ядро - необходимость, системда - <придумайте сами>.
> придуманная необходимость, под лозунгом "долой зоопарк, даешь унификацию". И ведь все задумывалось
> как система инициализации, а сейчас эта срань плавно подбирается к ядру,
> и вот вот его поглотит.Если это такая плохая и ненужная вешь, то вы можете ее выбросить. Смелее..
> Если это такая плохая и ненужная вешь, то вы можете ее выбросить. Смелее..Ой, дяденька, как страшно!
# rpm -qf `readlink /proc/1/exe`
sysvinit-2.88-alt5.x86_64
> Если это такая плохая и ненужная вешь, то вы можете ее выбросить. Смелее..Я себе ее не "забрасывал", поэтому и выбрасывать не нужно. :)
> а сейчас эта срань плавно подбирается к ядру, и вот вот его поглотит.Линус уже один раз показал известный жест, и второй раз покажет.
Судя по тому, что "вот это" при всей чудовищности таки взлетело, унификация таки отчаянно нужна, но конкретная реализация в systemd - жуть. Собственно, Поттеринг на этом и выезжает каждый раз - вещи-то делает нужные, но вот _как_ он их делает...
Разница в том, что альтернативное недырявое ядро найти нельзя, а альтернативный недырявый инит - можно.
назовите мне "инит" в котором не было бы найдено не одной уязвимости
Давай лучше ты покажешь local root у sysvinit.
>OpenBSD и FreeBSD смотрят на это высказывание с недоумением.Помнится, во фряхе забытый кавычка в /etc/rc.conf (вроде, уже лет 10 прошло как это юзал) - повод выпасть в singlemode при ребуте. Вот уж крутая система для удалёнки (когда нет ILO или аналогов).
Да не оправдывайся, понятно, что ты с фряхой слабо знаком.
Был бы знаком ближе - вспомнил бы скорее про single-user merge.
> назовите мне "инит" в котором не было бы найдено не одной уязвимостиЗачем нам новый инит с новыми глюками и уязвимостями, да еще закрытый (с точки зрения пользователя - бинарное это закрытое, а баш-скрипт - это открытое) ?
> (с точки зрения пользователя - бинарное это закрытое, а баш-скрипт - это открытое)Что курил? Пользователю вообще пофигу.
Наверное он имел в виду осознанного пользователя, а не овоща, умеющего в четыре кнопки и вконтакт.
На, ищи уязвимость:
https://gist.github.com/rofl0r/6168719
> На, ищи уязвимость:
> https://gist.github.com/rofl0r/6168719Конечно, он же не умеет в сеть, не заменяет sudo, не может запускать что-то в фоне, пока проверяет fsck и при этом показывает порнушку прямо в tty.
> Конечно, он же не умеет в сеть, не заменяет sudo, не может
> запускать что-то в фоне, пока проверяет fsck и при этом показывает
> порнушку прямо в tty.Вот именно. Sysvinit не лезет в сеть, не заменяет sudo, не ведёт бинарные логи. (про "запускать что-то в фоне", так и быть, помолчу)
OpenBSD и FreeBSD смотрят на это высказывание с недоумением.
>OpenBSDhttps://www.opennet.ru/opennews/art.shtml?num=44790
>FreeBSD
>>FreeBSD
> https://www.opennet.ru/opennews/art.shtml?num=45638По ссылке вообще-то про тамошний libc, но на скору руку пусть будет так:
https://www.opennet.ru/opennews/art.shtml?num=39674
https://www.opennet.ru/opennews/art.shtml?num=31887
https://www.opennet.ru/opennews/art.shtml?num=17713PS re #140: выделил жирным специально для жеманящихся...
Ищите за 1999 год!
> Дыра в ядре - бывает. Дыра в systemd - криворукость разрабов. Таков
> двойной стандарт хейтеров.Ленарту и вам, лаверзам, с самого начала говорили, что приведёт весь этот цырк с понями именно к такому результату. Но вы ж и теперь не верите, да-а-а?!
Некоторые даже умудрялись предсказывать, что _именно_ релизы, разлетевшиеся "по рукам" дистрибутивов-лаверзрв *и* заботливо не попавшие в релиз(ы) RHEL будут [по странному стечению, конечно!] более подвержены казачково-диверсионному битроту. Это тоже, конечно, "не доказано" и "двойной стандард", да.
--Праздник у VUAдминов -- на улице Ленарта пень горит. ...если не шапка.
Все равно будет продавливать Редхат всемогущий. :)
> Дыра в ядре - бывает. Дыра в systemd - криворукость разрабов. Таков
> двойной стандарт хейтеров.Ну да, бывает. Форс мажор такой. А то, что кое-кто форсистый и рыжий (не будем невежливо показывать пальцем) размерами кода своей "системы инициализации и менеджера сервисов" обогнал ядро, на котором бегала третья слака:
https://www.linuxcounter.net/statistics/kernel
https://www.openhub.net/p/systemd
http://slackware.cs.utah.edu/pub/slackware/slackware-3.0/тут совершенно никаким боком не относится, просто совпадение такое.
Ведь "больше кода == больше багов" мудрость для простых смертных, но никак не про гениев.
> Ведь "больше кода == больше багов" мудрость для простых смертных,
> но никак не про гениев.Вот кстати. Уважаемый Аноним84701, а можете связаться со мной почтой? Есть вопрос :)
(хотел ответить на https://www.opennet.ru/openforum/vsluhforumID3/110521.html#182 со сравнением gain privileges, но он на данный момент стёрт вместе со вбросом "гостя", похоже)
> Дыра в ядре - бывает. Дыра в systemd - криворукость разрабов. Таков двойной стандарт хейтеров.Очнитесь. В ядре тяжело обнаруживаемые баги, которые отыскивают суровые профессионалы.
А systemd создаёт файлы с правами 07777.
> А systemd создаёт файлы с правами 07777.Да ладно тебе, оно ж не всегда создает, у одних создает, у других не создает, по этому они пишут баг-репорты, что "ниработает". Вообще под системД эксплоиты писать - себе дороже, у половины будет работать, у половины рандомно нет.
> Дыра в ядре - бывает. Дыра в systemd - криворукость разрабов. Таков
> двойной стандарт хейтеров.Угу, только не забывай, что Лёня сам по поводу дыр в ядре хейтерит и называет Линуса криворуким. При этом это его (Лёни) код создаёт проблемы, после чего он (код) был вычищен Линусом.
Потому что с наличием ядра - все согласны, а с наличием монолитного блоба, которые ещё и глючит - немногие.
> монолитного блобаэто ты про ядро linux? Оно же эталон монолитности.
> Потому что с наличием ядра - все согласны, а с наличием монолитного
> блоба, которые ещё и глючит - немногие.А я всё больше замечаю, что фанатики системды обкурены всегда. Гашиш хороший был, а, _hide_? Сравнивать ядро и комбайн инициализации как-то некорректно, не находишь?
>> Потому что с наличием ядра - все согласны, а с наличием монолитного
>> блоба, которые ещё и глючит - немногие.
> А я всё больше замечаю, что фанатики системды обкурены всегда.Сами-то не уфаначивайтесь -- перечитайте внимательно, что _hide_ написал.
> Потому что с наличием ядра - все согласныДа не все согласны. Скорее все смирились. Но непонятно, зачем наступать на те же грабли кубика-рубика монолита ещё один раз. И это при наличии совершенно модульных альтернатив, в том числе и старой системы (sysVinit вообще выступает в роли аналога микроядра).
> Дыра в ядре - бывает. Дыра в systemd - криворукость разрабов.
> Таков двойной стандарт хейтеров.Вы прежде чем набегать и хейтить ядро с его разработчиками -- попробуйте обойтись без ядра, я-то без этого вашего systemg обхожусь. Ну и есть некоторая разница между тем, как поступают со своими косяками ядерные разработчики ("наш код, нам и фиксить") и Леннарт с Кеем (что характерно, этот косяк затыкал тоже кто-то совсем другой).
> этот косяк затыкал тоже кто-то совсем другойДа, не царское это дело...
> Вы прежде чем набегать и хейтить ядро с его разработчикамиУвы, но дедушка Танненбаум не открыл вовремя Minix, а дядюшка Торвальдс не послушал вовремя умного дедушку.
Потому что в таким подходом, как у systemd, к написанию кода дыры - закономерный результат.
> Уязвимость вызвана тем, что выполнение функции touch() приводит к созданию файлов в директории /run с правами 07777кто разбирался - ошибка была в том что дёрнули touch(), а у того по дефолту ставятся права файлу 07777 ?
В нутрях systemd есть функция touch_file, принимающая в том числе mode_t. Она юзалась в src/core/timer.c с нулём в mode_t. А потом товарищ Поттеринг решил использовать вместо нуля MODE_INVALID = -1. В результате файлы стали создаваться со всеми правами.
Фикс: поменяли touch_file, чтобы при MODE_INVALID она использовала 0644.
Отличный хардкод, ящетаю. Откуда взяли 644? Почему не 640? Или не 600?
Охренеть у них логика. Если в touch_file приходит MODE_INVALID, то НЕ НАДО создавать файл вообще, а не создавать его с дефолтными правами. Недоумки.
На сях особо никто не думает о красивой архитектуре, жестком разграничении ответственности, абстракциях и т. д. Логика сишника такова: раз названо touch_file, то и надо создать файл. Поскольку в сях нету исключений, сишнику, чтобы последовать твоему совету, пришлось бы вернуть из touch_file еще одну константу. Допустим, TOUCH_FILE_ERROR_INVALID_MODE_PASSED. Но сишник смотрит: опа, touch_file-то возвращает void, поэтому давай-ка я не буду трогать то, что и так работает, и просто буду считать, что MODE_INVALID -- это то же, что и 644.Ни этому сишнику, ни тебе не пришло в голову вот что: при MODE_INVALID функция touch_file вообще не должна вызываться! Валидация данных должна быть вынесена в другое место.
> Логика Лёни такова: раз названо touch_file, то
> и надо создать файл.Fix
Не надо за всех сишников говорить. На самом деле сишники куда более аккуратные, чем, например товарищи, которые пишут на C++ или Java. По себе сужу.
Так вот кто плодит кривокод на С++ и Java, а потом жалуется.
> Так вот кто плодит кривокод на С++ и Java, а потом жалуется.Лично я не жалуюсь. Лично я молча исправляю.
> Лично я не жалуюсь. Лично я молча исправляю.Коллега, как я тебя понимаю.
Кое-кому очень сильно бомбит с того, что оный ниасил в своё время "неуправляемые" языки.Пиши на Яваскрипте, макака.
Обычная логика похапешника. В непонятной ситуации выбор из "не делать ничего" и "сделать что-нибудь" - выбирается второе.
"не делать ничего" - это в каком ЯП такое?
> "не делать ничего" - это в каком ЯП такое?
> В нутрях systemd есть функция touch_file, принимающая в том числе mode_t. Она
> юзалась в src/core/timer.c с нулём в mode_t. А потом товарищ Поттеринг
> решил использовать вместо нуля MODE_INVALID = -1. В результате файлы стали
> создаваться со всеми правами.Проблема на самом деле кое-в-чём другом. От создания подобных файлов при вызове open вообще-то должен спасать umask, поскольку права файла высчитываются как mode & ~umask (man 2 open)
Поскольку он не спасает, можно сделать вывод, что Леннарт сам себе злобный буратино, umask забил нулями.
Настоящие программисты не совершают ошибок, ага. Зачем настоящим программистам предохранители?
ls -la /var/lib/systemd/timers/
итого 8
drwxr-xr-x 2 root root 4096 янв 4 21:20 .
drwxr-xr-x 8 root root 4096 янв 20 16:40 ..
-rw-r--r-- 1 root root 0 янв 24 11:03 stamp-apt-daily.timer
-rw-r--r-- 1 root root 0 янв 24 15:58 stamp-snapd.refresh.timerнету ничего подобного в xenial 16.04.1 LTS. а свежие билды только у этого человека есть: https://launchpad.net/~pitti/+archive/ubuntu/systemd и то там только основа без шимов и транзишн пакетов для дебиан и убунты (врядли это будет работать с 229 шимами и прочей 229 требухой из дебиана/убунты)+ indicator-session для юнити, но я уполз уже на хубунту, так что полезность данной ппахи равна нулю, а больше никак не обновиться до апстрим 232 в убунте, т.к. дебиановская инфраструктура и просто из апстрима эту штуку с гита не собрать будет (она твикается дебиановскими/убунтовскими мэйнтэйнерами). Но т.к. эти системы не подвержены данной уязвимости, то проходим мимо...
Странное исправление 06eeacb6fe029804f296b065b3ce91e796e1cd0e
Почему не просто "mode == MODE_INVALID ? 0644 : mode"?
Ниже же всё равно есть "if (mode != MODE_INVALID) {r = fchmod(fd, mode);...}
fd = open(path, O_WRONLY|O_CREAT|O_CLOEXEC|O_NOCTTY,
(mode == 0 || mode == MODE_INVALID) ? 0644 : mode);
if (fd < 0)
return -errno;if (mode != MODE_INVALID) {
r = fchmod(fd, mode);
if (r < 0)
return -errno;
}
> Странное исправление 06eeacb6fe029804f296b065b3ce91e796e1cd0e
> Почему не просто "mode == MODE_INVALID ? 0644 : mode"?
> Ниже же всё равно есть "if (mode != MODE_INVALID) {r = fchmod(fd,
> mode);...}Глубокая задумка! Гениальный API!! ПРи передаче на вход mode=0 оно создаёт файл с 0644 и потом fchmod()=ает его в 0000.
---Тот в цирке не смеётся.
> fd = open(path, O_WRONLY|O_CREAT|O_CLOEXEC|O_NOCTTY,
> (mode == 0 || mode == MODE_INVALID) ? 0644 :
> mode);
> if (fd < 0)
> return -errno;
> if (mode != MODE_INVALID) {
> r = fchmod(fd, mode);
> ПРи передаче на вход mode=0 оно создаёт файл с 0644 и потом fchmod()=ает его в 0000.А при передаче любого нормального mode оно создаёт файл с этим mode, а потом делает fchmod ещё раз, ну чтобы уж точно.
Хотя в вашем случае дыра в безопасности, что намного весомее.
> А при передаче любого нормального mode оно создаёт файл с этим mode, а потом делает fchmod ещё раз, ну чтобы уж точно.Ага. Больше сисколлов вкусных и разных. По поводу и без.
А когда эта хрень будет тормозить похлеще рубанка на наждачке, Поттеринг заявит, что вся проблема именно в сисколлах, и systemd на самом деле должен выполняться с привилегиями ядра, чтобы избежать потерь производительности на них. :)
> должен выполняться с привилегиями ядра, чтобы избежать потерь производительности на них.
> :)Он скажет "это проблема ментейнеров", и те системД-фан-бои.system.systemd.potering.unit, которые приняли решение вкрячить ЭТО в свои дистрибутивы - сильно офигеют. Их бог от них отвернулся, да я хочу на это посмотреть :)))
>> ПРи передаче на вход mode=0 оно создаёт файл с 0644 и потом fchmod()=ает его в 0000.
> Хотя в вашем случае дыра в безопасности,Где? Я не спец по безопасностям, думал просто многоярусный бYдлоkод обозначить.
>>> ПРи передаче на вход mode=0 оно создаёт файл с 0644 и потом fchmod()=ает его в 0000.
>> Хотя в вашем случае дыра в безопасности,
> Где? Я не спец по безопасностям, думал просто многоярусный бYдлоkод обозначить.Ммм... Придумал только гонку за world-readable-ом типа-как-бы-0000 файла. После сабжа это не безопасность, это супер-фичный API для ловерзов.
>А при передаче любого нормального mode оно создаёт файл с этим mode, а потом делает fchmod ещё раз, ну чтобы уж точно.Если файл уже существует, то open() не изменит его mode, а fchmod изменит.
Да там весь код такой, тут, помнится, приводили совершенно чудесные образцы парсинга конфига... Я крайне удивлён, что эти уязвимости ещё не косяком идут, код жуткий.
Я приводил, там парсинг командной строки с магическими константами - длинами названий настроек.Об общей адекватности можно судить по тому, что товарищ использует для задачи, выполняемой скриптами, портируемый ассемблер (язык C). В стиле "Вася изучил колун, и теперь всюду его использует".
Я, в общем-то, не вижу особого криминала в том, чтобы для стандартных задач иметь вменяеые декларативные конфиги вместо шелла - но явно не в таком исполнении. Был бы это, например, явно выделенный модуль для парсинга (с нормальным полноценным парсером вместо этой дикости), модульные обработчики на том же Lua с возможностью расширять синтаксис конфига (и сам конфиг помощнее, чем ini-формат) - был бы другой разговор. Ну и масимальная обратная совместимость, конечно, и чётко очерченная зона ответственности в место "заменим всё и вся".А здесь получилось, что признание получила штуковина с паршивой архитектурой и грязным кодом.
Да нет там никакого криминала. Просто в sysVinit'е структура модульная - хочешь пиши скрипты на bash, хочешь - на ocaml, хочешь make. На ocaml'е, кстати, скрипты отлично пишутся (правда должны быть минимум на пол страницы, иначе shell короче). Там тебе и компиляция, и проверка типов, правда нет ленивости :-(.А systemD - кубик-рубик монолит.
Я к тому, что сам инит трогать вообще не надо - ну маленький, отлаженный и висит наверху. А менять - скриптовую систему, на твой Lua или ещё чего разумного.
Актуально для пользователей Arch.Там systemd, конечно, давно уже обновили, но если система хоть раз загружалась с дырявой версией, то в /var/lib/systemd/timers/ будет файл с опасными правами, который можно проэксплуатировать. Кода, который исправляет права на уже существующие файлы, в systemd нет. Поэтому:
# rm -f /var/lib/systemd/timers/*
> # rm -f / var/lib/systemd/timers/*Патч - Леннарту!
Патч Леннарта!
> Патч Леннарта!Трави Леннартов, спасай GNU/Linux!
# rm -fR /home/lennart/src/systemd*Так правильнее.
> # rm -fR /home/lennart/*fix
Тогда уж:
sudo userdel lennart
shutdown -r now
Start-Control Panel-Create a new user- lennart
>>> find / -name lennart -deletefix
> fixfind / -name lennart -exec rm -rf {} +
> Актуально для пользователей Arch.
> Там systemd, конечно, давно уже обновили, но если система хоть раз загружалась
> с дырявой версией, то в /var/lib/systemd/timers/ будет файл с опасными правами,
> который можно проэксплуатировать. Кода, который исправляет права на уже существующие файлы,
> в systemd нет. Поэтому:
> # rm -f /var/lib/systemd/timers/*Спасибо! На ArchLinux в моей системе до сих пор были эти файлы.
> Я тебя наверное огорчу, но любой дистрибутив может работать без systemdНе все дистрибутивы могут работать без systemd! Вернее работать могут не только лишь все, но мало кто может это делать ( с )
OpenSUSE "Leap" 42.2, свежеустановленная:
#rpm -q systemd
systemd-228-19.1.x86_64#stat /var/lib/systemd/timers/stamp-fstrim.timer
Файл: '/var/lib/systemd/timers/stamp-fstrim.timer'
Размер: 0 Блоков: 0 Блок В/В: 4096 пустой обычный файл
Устройство: 900h/2304d Inode: 135650131 Ссылки: 1
Доступ: (7777/-rwsrwsrwt) Uid: ( 0/ root) Gid: ( 0/ root)
Доступ: 2017-01-23 00:00:01.921977000 +0300
Модифицирован: 2017-01-23 00:00:01.921977000 +0300
Изменён: 2017-01-23 00:00:01.917878943 +0300
Создан: -Ппц.
OpenSUSE пофиксили вчера, прилетело в systemd-228-22.1.x86_64
#rpm -q --changelog systemd
…
* Чт янв 19 2017 fbui@suse.com
- Fix permissions set on permanent timer timestamp files (bsc#1020601) (CVE-2016-10156)
…
a59d1ad28 basic: fix touch() creating files with 07777 mode (bsc#1020601) (CVE-2016-10156)в т.ч. это, и хватило ума подтереть за systemd.
С приходом systemd появились проблемы, котрых до прихода systemd не существовало :)
Как если бы этого не хватало, они ещё и сломали systemd 232 на 32-битных системах:https://lists.altlinux.org/pipermail/sisyphus/2017-January/3...
https://github.com/systemd/systemd/issues/4575
https://bugs.archlinux.org/task/51693
> Как если бы этого не хватало, они ещё и сломали systemd 232
> на 32-битных системах:
> https://github.com/systemd/systemd/issues/4575Это Прекрасно! ПотерингоХат и ХромУгль точат лясы в баге, куда небежали "третье-сортные", не энтерпрайсные, не64крутые поломатые ими дистрибутивы. С ноября месяца -- плодотворно обсуждают Переспекетивы Новых Технологий для убогих.