Если ты не в курсе, то POSIX - это описание того, как стек технологий должен работать, а не наоборот.

POSIX включает в себя то, какие функции есть, как их дергать и что получится. А ещё описание опций CLI тулзов.

Прямо как... описание софта FDO :)

Проверки на integer overflow обычно пытаются зашить в фукнции. realloc, calloc и reallocarray() не просто так придумали.

А эти функции точно правильно работают, а то, может, и их надо проконтролировать? А потом и вызовы ядра? Ну, мало ли что.

А эти функции точно правильно работают, а то, может, и их надо проконтролировать?

Прикинь. Их чуваки из glibc тестируют. А ещё люди у себя разного рода интеграционные тесты гоняют, с включенными проверками на поехавший стек. Чтобы не дай боже.

А потом и вызовы ядра? Ну, мало ли что.

Когда-нибудь ты вырастешь и узнаешь про syzkaller.

У тебя есть uid, у него есть три типа значений — ноль (рут), 1 - UID_MAX (юзеры) и все, что выше. И да, их по хорошему стоит проверить. Хотя бы по одному из группы.

Их стоит проверить утилитам типа useradd и polkit (внезапно).

Для systemd это детали реализации вспомогательных утилит. Проверка их unit-тестами на стороне systemd нелогична.

Как например нелогично в юнит-тестах проверять может ли systemd запустить mysql на Ubuntu 16.04.

Этот тест-кейс _можно_ было бы добавить в интеграционные тесты systemd, но отсутствие его там не является криминалом.

То что system взаимодействует с большим количеством сервисов не повод все баги этих сервисов вешать на разработчиков systemd.

Их стоит проверить утилитам типа useradd и polkit (внезапно).

Это называется unit-тестирование. Когда ты проверяешь отдельный компонент. А ещё есть integration-тестирование. Когда ты проверяешь, что все компоненты связаны и работают *В СВЯЗКЕ* как надо. Что ты получаешь *ОЖИДАЕМОЕ ОТ СИСТЕМЫ* поведение.

Для systemd это детали реализации вспомогательных утилит. Проверка их unit-тестами на стороне systemd нелогична.

Ты проверяешь не polkit, ты проверяешь *ЧТО SYSTEMCTL НЕ ПУСКАЕТ ЮЗЕРА, КОТОРОГО НЕ ДОЛЖЕН ПУСТИТЬ СОГЛАСНО ТЕСТОВОМУ ПЛАНУ*. Потому что баг может оказаться на стыке компонентов. Поэтому unit-тестирование и integration-тестирование — разные виды тестирования, часто приводящие к разному результату.

То что system взаимодействует с большим количеством сервисов не повод все баги этих сервисов вешать на разработчиков systemd.

*ФИЧА SYSTEMD* (то есть возможность выполнения привилегированных операций от непривилегированного юзера) — это фича systemd, а не polkit. То, что оно работает через polkit — детали реализации.

P.S. Жирненьким я отметил важные пункты.

Прикинь. Их чуваки из glibc тестируют.

То есть этим чувакам мы можем верить. Это хорошо. А почему, собственно, им верим, а чувакам из polkita нет? В libc багов не бывает? Бывает. Так, почему?

То есть этим чувакам мы можем верить. Это хорошо. А почему, собственно, им верим, а чувакам из polkita нет? В libc багов не бывает? Бывает. Так, почему?

А мы им и не верим, мы регулярно прогоняем наш софт через проверки на целостность памяти. Мы так баги в jemalloc нашли.

это твои домыслы. это могло быть сделано из общих соображений о том, кто какие права должен иметь, либо не иметь. для тех, кто понимает, как и что должно работать - это нормальная практика. дыру в polkit это не отменяет, но следование изначальной идеалогии позволило избежать опасности.

Но ведь не только systemd-run, а вообще можно «выполнить любую команду systemctl»

И? Я вообще могу выполнить любую команду в системе, хоть rm -rf.

Сорри, я отвечал на реплику «systemd-run - отдельный бинарь, он не является частью критического кода PID 0», неправильно прочитав «PID 0» как «UID 0». Но, прочитав дальнейшие сообщения и поняв, что под «критическим кодом» подразумевался init c pid'ом 1, у меня другой вопрос: почему именно init является критическим, а другие процессы — нет? Чем он отличается от остальных помимо того, что является родителем остальных? Я бы ещё понял, если бы речь шла о режиме ядра против против пользовательского режима, но при чём тут init?

Пока нормально проверяются права, в чем проблема?

Так в том-то и дело, что права проверяются ненормально, и пользователь с uid > 0x7FFFFFFF получает привилегии uid 0. Об этом и новость. А если бы права проверялись нормально, то и вопросов не было, как и самой новости.

Я бы ещё понял, если бы речь шла о режиме ядра против против пользовательского режима, но при чём тут init?

Дескать, даже init, который должен быть простым, как валенок, испортить умудрились.

Сама RedHat, судя по новости, считает это багом

Да, только не в systemd, а в polkit.

Я согласен, что основная вина тут лежит на разработчиках polkit. Однако, как здесь уже говорили, разработчики systemd, линковавшиеся с polkit, тоже должны были протестировать свой код, особенно на уязвимости. Я подчёркиваю: свой слинкованный код, а не библиотеку. И если бы они это сделали достаточно тщательно, то обнаружили бы проблему и решили её сразу. Как здесь уже говорили, другие программы, использующие polkit, не предоставляют таких прав простому пользователю с большим uid'ом, потому что сами проверяют этот самый uid. И, ещё раз: я не кричу, что systemd сплошное решето и ужас-ужас, хотя многое и в его архитектуре, и в реакции Поттеринга на любую критику мне не нравится (но не настолько, чтоб уходить с debian и мучиться с devuan). Я только говорю, что это баг, в котором, помимо разработчиков polkit, отчасти виноваты и разработчики systemd.

Но местные хейтеры и слышать/видеть ничего не хотят - у них вегда systemd виноват. Убогие.

Но я прокомментировал даже не сообщения о том, кто виноват — polkit или systemd, — а огромное число сообщений о том, что проблемы вообще нет, потому что таких uid не бывает. И подобных фанатов в теме куда больше, чем хейтеров, кричащих, что systemd — по определению решето. И даже те, кто высказался подобным образом в этом треде, аргументировали свою позицию, в отличие от первых.

Слово «fuzzing» ты, видимо, в первый раз слышишь.

Расскажи, как фаззить многопроцессную программу, один из процессов которой - короткоживущий.

Расскажи, как фаззить многопроцессную программу, один из процессов которой - короткоживущий.

Какие интерфейсы, что фазим? А то вот создание файлика фазить проблемы нет.

почему именно init является критическим, а другие процессы — нет?

Потому что от функционирования init зависит функционирование системы; а падение init - это крах системы.

Так в том-то и дело, что права проверяются ненормально, и пользователь с uid > 0x7FFFFFFF получает привилегии uid 0.

Да. Но это не проблема systemd-run.

А мы им и не верим, мы регулярно прогоняем наш софт через проверки на целостность памяти. Мы так баги в jemalloc нашли.

И, типа, больше ошибок нет и не будет?

Будь последователен: libc - своя, ядро своё и т.д. Причём, каждый последующий слой не верит предыдущему, поэтому таскает с собой ещё одну «безошибочную» собственную реализацию. Чёрт, но ей тоже нельзя верить. В какой момент собираешься остановиться?

Это ты ничего не понял и отвечаешь на условный рефлекс.

И, типа, больше ошибок нет и не будет?

Кто тебе сказал?

Будь последователен: libc - своя, ядро своё и т.д. Причём, каждый последующий слой не верит предыдущему, поэтому таскает с собой ещё одну «безошибочную» собственную реализацию. Чёрт, но ей тоже нельзя верить. В какой момент собираешься остановиться?

Это ты сейчас к чему? Если что, ребята из glibc в том числе проверяют, что с новой версией ядра сисколы не вносят искажений в работу glibc.

Расскажи, как фаззить многопроцессную программу, один из процессов которой - короткоживущий.

Какие интерфейсы, что фазим?

Фазим systemd-run для того, чтобы найти сабжевый баг, естественно. Интерфейсы - CLI systemd-run и DBus-интефейс polkit.

Фазим systemd-run для того, чтобы найти сабжевый баг, естественно. Интерфейсы - CLI systemd-run и DBus-интефейс polkit.

Запускаем контейнер с PID namespace'ом и попердолили. А в чем проблема?

*ЧТО SYSTEMCTL НЕ ПУСКАЕТ ЮЗЕРА, КОТОРОГО НЕ ДОЛЖЕН ПУСТИТЬ СОГЛАСНО ТЕСТОВОМУ ПЛАНУ*

согласно тестовому плану systemd пускает юзера которого ему сказал пустить polkit

Поэтому unit-тестирование и integration-тестирование — разные виды тестирования

Да, и требования к ним разные. Если по unit-тестированию ты можешь наезжать на разработчиков почему они не покрыли такую-то фичу тестами, какие нехорошие люди, это должно быть в системе изначально... то по интеграционному отсутствие тестирования corner-case из совсем другой темы - это не криминал, а нормальная работа.

Весь мир в интеграционные тесты одного проекта не запихнешь и на одну команду разработчиков не повесишь.

И поэтому собственно смешно как по поводу отсутствия интеграционного теста ты тут два дня шумишь, а отсутствие unit-тестов у polkit - ну это ладно, там не Поттеринг же. Даже имени разработчиков их не знаем, вся ненависть на systemd ушла.

согласно тестовому плану systemd пускает юзера которого ему сказал пустить polkit

Любого? Типа политики, которые systemd устанавливает, ничего не значат? :D

Да, и требования к ним разные. Если по unit-тестированию ты можешь наезжать на разработчиков почему они не покрыли такую-то фичу тестами, какие нехорошие люди, это должно быть в системе изначально... то по интеграционному отсутствие тестирования corner-case из совсем другой темы - это не криминал, а нормальная работа.

Не понял, раскрой.

Весь мир в интеграционные тесты одного проекта не запихнешь и на одну команду разработчиков не повесишь.

Поэтому они напихали столько фичей, что не могут их нормально протестировать, и теперь постоянно вляпываются в глупые баги?

Расскажи, как фаззить многопроцессную программу, один из процессов которой - короткоживущий.

Какие интерфейсы, что фазим?

Фазим systemd-run для того, чтобы найти сабжевый баг, естественно. Интерфейсы - CLI systemd-run и DBus-интефейс polkit.

Запускаем контейнер с PID namespace'ом и попердолили.

Ясно.

А в чем проблема?

По описанию «запускаем и попердолили» трудно сказать.

И подобных фанатов в теме куда больше, чем хейтеров, кричащих, что systemd — по определению решето.

куда больше

А слабо посчитать?

По описанию «запускаем и попердолили» трудно сказать.

Ну вот и я не вижу.

По описанию «запускаем и попердолили» трудно сказать.

Ну вот и я не вижу.

Наверное, в «запустить и попердолили» проблем и правда нет. Но задача не в этом.

Это ты сейчас к чему? Если что, ребята из glibc в том числе проверяют, что с новой версией ядра сисколы не вносят искажений в работу glibc.

К тому, что твой софт, например, дёргает функцию системной библиотеки и получает некий результат. При этом, на некоторых входных данных, функция из-за ошибки реализации возвращает неверный результат. Ты утверждаешь, что это ошибка твоего софта, потому что он не проверил данные, которые отправил на вход этой функции. Таким образом, твой софт, мало того, что должен знать все допустимые диапазоны входных данных всех используемых системных функций, так ещё и знать всю конфигурацию системы, потому что поведение системных функций может зависеть от неё. Ничего здесь странным не кажется?

К тому, что твой софт, например, дёргает функцию системной библиотеки и получает некий результат. При этом, на некоторых входных данных, функция из-за ошибки реализации возвращает неверный результат. Ты утверждаешь, что это ошибка твоего софта, потому что он не проверил данные, которые отправил на вход этой функции. Таким образом, твой софт, мало того, что должен знать все допустимые диапазоны входных данных всех используемых системных функций, так ещё и знать всю конфигурацию системы, потому что поведение системных функций может зависеть от неё. Ничего здесь странным не кажется?

Нет. Потому-что в манах действительно прописаны все допустимые значения, которые действительно стоит проверять (во избежание n > ssize_t, например, который ведет к непойми чему). И да, многие вещи (типа работы с изоляцией) требуют определенных настроек системы, которые тоже учитываются при тестировании (вплоть до проверок, доступен ли тебе вообще сисколл). Я так понимаю, в твоей конторе тестировщиков нет?

Ты контролируешь чужой софт? Нет? Тогда результат может быть любым. Ты может либо провести в разумных пределах тестирование своего софта, либо заявить, что ты д'Артаньян. Разумные пределы определяются ожидаемым от софта поведением. А теперь ролевая модель: ты продаешь сборку за деньги. И тут в твоей сборке дыра, причем проявляющаяся при использовании программы, разрабатывающейся у тобой же. Расскажи нам, как ты собираешься рассказывать заказчикам, что виноват не ты, а непонятный хер с горы, потому что его софт не так работает.

Расскажи нам, как ты собираешься рассказывать заказчикам, что виноват не ты, а непонятный хер с горы, потому что его софт не так работает.

А что в этом сложного? «Виноваты вон те парни, но мы можем сделать заплату, если вы пожелаете». Дело житейское. Только не рассказывай про возмещение заказчику убытков и судебную ответственность - не только у заказчика есть юристы.

Если не использовать sudo, потребует пароль:

root@devuan:~# su testingu
$ whoami
testingu
$ pkexec /bin/bash

(process:23938): GLib-GObject-WARNING **: value "-294967296" of type 'gint' is invalid or out of range for property 'uid' of type 'gint'
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run `/bin/bash' as the super user
Authenticating as: root
Password: 

Уже несколько раз сказали, что через pkexec уязвимость не эксплуатируется (из-за ошибки в pkexec, ага).

Не понял, раскрой.

См. выше.

Работает ли mysql-юнит с такой-то версией systemd - это тоже интеграционный тест. Но по умолчанию его никто не будет делать на стороне systemd. Потому что таких интеграций можно придумать миллионы.

Вот если ты придешь и скажешь что это очень ценный юнит, в нём используется вот этот уникальный набор ключей и потому его работа должна быть показательна для systemd, и при этом сам mysql такой весь стабильный что не падает по случайным причинам, поэтому он является хорошим показателем для работы, давайте его сделаем маркером в проекте systemd - это может и сыграет.

Интеграционные тесты вообще часто накапливаются со временем, в том числе из багрепортов, а не пишутся с нуля готовыми в день первого релиза.

Поэтому они напихали столько фичей, что не могут их нормально протестировать, и теперь постоянно вляпываются в глупые баги?

Что ж так тебя плющит-то. Ничего глупого нет в баге в стороннем сервисе. Баг как баг.

И те три «постоянно», про которые тут были баталии до того, точно также никакими «глупыми багами» не были.

Глупая тут только истерия, которая мешает вникать в подробности.

Нет.

Как нет, когда да. Софтину дёрнул пользователь, который уже есть в системе. Как он туда попал, когда и почему, софтине это по-барабану. Софтина только спрашивает другую, должна ли она запуститься под этим пользователем или нет. Та, на основе своих настроек, отвечает. При этом, по твоим словам, правильно спроектированная софтина должна проверить, что такие пользователи в системе могут быть, что им разрешён вход в систему именно в данное время, что у них есть нужные права и т.д. и т.п. И, в конце концов, ещё и проверить, а не наябывает ли её вторая софтина.

Ну, тред до конца ещё не осилил, звиняй.

Как нет, когда да. Софтину дёрнул пользователь, который уже есть в системе. Как он туда попал, когда и почему, софтине это по-барабану. Софтина только спрашивает другую, должна ли она запуститься под этим пользователем или нет. Та, на основе своих настроек, отвечает. При этом, по твоим словам, правильно спроектированная софтина должна проверить, что такие пользователи в системе могут быть, что им разрешён вход в систему именно в данное время, что у них есть нужные права и т.д. и т.п. И, в конце концов, ещё и проверить, а не наябывает ли её вторая софтина.

Нет, это твои слова. Мои слова были про тестирование.

А я бы пошел еще дальше. Ведь это спо. Никто никому ничего не должен. Значит, и разрабы чужой софтины никому ничего не должны. А значит, их софт работает так, как работает.

в первую очередь хочу заявить, что да, системд - говно, но это очевидно :)

а вот, что получается:

sbauer@metabook ~/devel/DE1-SOC/linux-socfpga-4.4 {socfpga-4.4}$ sudo useradd -u 4000000000 testpolit
sbauer@metabook ~/devel/DE1-SOC/linux-socfpga-4.4 {socfpga-4.4}$ sudo su - testpolit
Каталог отсутствует или недоступен, вход в систему выполняется с HOME=/
$ pkexec bash

(process:9277): GLib-GObject-WARNING **: value "-294967296" of type 'gint' is invalid or out of range for property 'uid' of type 'gint'
**
ERROR:../../../src/programs/pkexec.c:692:main: assertion failed: (polkit_unix_process_get_uid (POLKIT_UNIX_PROCESS (subject)) >= 0)
Aborted
$ logout

sbauer@metabook ~/devel/DE1-SOC/linux-socfpga-4.4 {socfpga-4.4}$ sudo -u testpolit pkexec /bin/bash

(process:9630): GLib-GObject-WARNING **: value "-294967296" of type 'gint' is invalid or out of range for property 'uid' of type 'gint'
root@metabook:~#

А я бы пошел еще дальше. Ведь это спо. Никто никому ничего не должен. Значит, и разрабы чужой софтины никому ничего не должны. А значит, их софт работает так, как работает.

А кто спорит? Это правда не отменяет того факта, что можно делать выводы о том, как именно он работает.

Это я к писал к утверждению про использование чужих софтин в своем комбайне. И к тестированию.

Их программный продукт работает правильно:
спрашивает у polkit, можно ли пользователю запустить данную операцию;
получает ответ, что можно;
запускает операцию.
В чём здесь, по-вашему, ошибка?

В классической ошибке программиста. Фича заключается не в том, >чтобы у polkit'а спросить, а в том, чтобы сделать возможным >выполнение привилегированных операций без привлечения рута, но >только тем юзерам, которым явно разрешили.

То есть софт должен сам проверять, допустима ли запрошенная операция, игнорируя ответ других системных компонент. Так и представляю себе: ls, вместо того, чтобы показать список файлов и директорий, лезет в сеть в хранилище ldap и начинает выяснять, а пользователь, который её выpвал, вообще существует?

То есть софт должен сам проверять, допустима ли запрошенная операция, игнорируя ответ других системных компонент. Так и представляю себе: ls, вместо того, чтобы показать список файлов и директорий, лезет в сеть в хранилище ldap и начинает выяснять, а пользователь, который её выpвал, вообще существует?

Нет, не должен, откуда ты это взял? Я про тестирование говорю. Ну, знаешь, нормальные разработчики такое проводят перед выпуском релиза :)

Ну, знаешь, нормальные разработчики такое проводят перед выпуском релиза

Так почему тогда претензии к разработчикам systemd, а не к разработчикам bash? Ведь это bash, получив строку с командой, позволяет получить привилегии администратора? Значит разработчики bash должны были протестировать такое поведение.

Значит разработчики bash должны были протестировать такое поведение.

нет, не значит

Так почему тогда претензии к разработчикам systemd, а не к разработчикам bash? Ведь это bash, получив строку с командой, позволяет получить привилегии администратора? Значит разработчики bash должны были протестировать такое поведение.

Это все Гитлер виноват.

нет, не значит

Фича заключается не в том, чтобы у polkit'а спросить, а в том, чтобы сделать возможным выполнение привилегированных операций без привлечения рута, но только тем юзерам, которым явно разрешили.

А в этом здесь косяк. Но я бы не стал говорить, что это косяк баша. Уязвимость в ядре, увы.

шапконаркоман о токсичной атмосфере

made my day

До этого вводил пароль по запросу sudo?

И подобных фанатов в теме куда больше, чем хейтеров, кричащих, что systemd — по определению решето.

А слабо посчитать?

Ну вот посчитал среди первых 300 сообщений тех, кто говорил (или намекал/язвил/и т. д.) о том, что таких uid не бывает, а значит всё это ерунда. Считал только уникальных юзеров (без повторений тех же мыслей теми же людьми) и только о невозможности таких uid, а не какие-то другие сообщения в защиту systemd (например, о том, что виноват на самом деле polkit). Всего среди первых 300 насчитал 13 таких уникальных сообщений. Вот список:

1. На один хост логинилась половина населения земли и его взломали? Теперь-то мы точно все умрем.
   

   (tailgunner ★★★★★ (11.12.2018 15:07:32))

2. Я такие UID встречал только у пользователей из LXC контейнеров, так они выглядят снаружи. Но пока не придумал, как это использовать изнутри контейнера.
   

   (ls-h ★★★ (11.12.2018 15:09:19))

3. Половина населения земли? Я ставлю на одного наркомана =)
   

   (t184256 ★★★★★ (11.12.2018 15:09:31))

4. так это бэкдур от наркоконтроля?
   

   (anonymous (11.12.2018 15:10:59))

5. позволяет пользователю, чей UID превышает 2147483647
   

   дальше не читал.
   

   (mos ★★★★★ (11.12.2018 15:33:25))

6. Какая ужасная уязвимость. А если пользователю дать uid=0, он тоже будет выполнять команды от рута!!11
   

   (vasily_pupkin ★★★★★ (11.12.2018 15:33:27))

7. Чтобы такой пользователь существовал, его нужно создать, а чтобы его создать — нужны права root. Если админ идиот, то и эксплоиты не нужны.
   

   (mord0d (11.12.2018 15:36:48))

   Проблема, описанная в новости, практически невозможна, а потому повод высосан из пальца.
   

   (mord0d (11.12.2018 15:38:54))

8. А разве есть такие «мудрые одмины», которые такие UID или UID делают?
   

   (mango ★★ (11.12.2018 15:55:45))

9. Стесняюсь спросить, что надо сделать с линуксом, чтобы там появилось больше 2147483647 UID'ов?
   

   (ncrmnt ★★★★★ (11.12.2018 17:10:37))

10. Не совсем понятно, а где в редхате предполагается создание юзеров с отрицательными уидами или уидом в 4000000000? Даже winbind такие диапазоны не использует имхо.
    

    (AVL2 ★★★★★ (11.12.2018 17:20:27))

11. так у тебя что нет пользователя с UID превышающими 2147483647? ну ты лошара ваще..
    

    (Thero ★★★★★ (11.12.2018 19:00:07))

12. Опять таки, если не рутом, то кем внесется пользователь с таким uid
    

    (sehellion ★★★★★ (11.12.2018 20:58:04))

13. Я думал ерунда... А потом прочитал:
    

    не создавать аккаунты с отрицательными значениями UID или UID превышающими 2147483647
    

    и уполз под стол.
    

    (kirill_rrr ★★★★★ (11.12.2018 22:37:28))

Теперь предлагаю тебе посчитать среди тех же первых 300 сообщений неаргументированные уникальные сообщения типа «сустемд решето ще то», не включая, разумеется, сообщения аргументированные, и вывести приблизительно в таком же формате, как у меня, чтоб легко было проверить.

нет, но насторажило не то, что sudo пароль не просил (так и должно быть - ноут «однопользовательский»)

просто, нужно было проверять без sudo, а как-нить через «su -l testpolkit -c /bin/bash»

[upd]
но

sbauer@metabook ~/devel$ sudo useradd -u 4000000000 testpolit
sbauer@metabook ~/devel$ su -l testpolit -c /bin/bash
Password:

то есть ты не отличаешь «невозможность» от «редкости», а «фанатов кричащих что не баг» от людей которые пишут что-то на тему «забавный баг, не знал что такие uid бывают».

Ни один из перечисленных тобой примеров не утверждает что описанная ситуация не баг. Поэтому найденное тобой количество примеров - 0.

и ноль не может быть «куда больше».

ЧТД.