В ядре Linux в реализации файловой системы OverlayFS выявлена уязвимость (CVE-2023-0386), которую можно использовать для получения root-доступа на системах, в которых установлена подсистема FUSЕ и разрешено монтирование разделов OverlayFS непривилегированным пользователем (начиная с ядра Linux 5.11 с включением непривилегированных user namespace). Проблема устранена в ветке ядра 6.2. Публикацию обновлений пакетов в дистрибутивах можно проследить на страницах: Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora, Arch...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=58857
Перемудрили они конечно с этими setgid/setuid. Такое количество абстракций, что не удивительно что где-то логику не продумали.
setuid/setgid это вообще чудовищный костыль родом из 80-х. Целый механизм файловой системы поддерживается уже 40 лет, но используется только для одной программы - sudo.
Справедливости ради, судо вообще костыль и мало где применим. Это механизм для запуска бинаря с чужими правами, поэтому применятся пользователями в многопользовательских конфигурациях, а не то, что ты подумал. Как это может использовать софт, по-твоему? Ну вот стим например от другого пользователя запускаешь, что файрвол мог его контролировать.
> судо вообще костыльКостыль, да. Но удобный, и исключительно поэтому еще жив.
> и мало где применим
В каком смысле? Он применим везде, где его применяют.
Дальнейший ваш поток сознания у меня расшифровать не получилось.
Ни разу в жизни не использовал судо. Чем он удобный? Костыль костыльный, есть 100 способов сделать нормально не создавая уязвимость.
Назовите хотя бы два из этих 100.
Не проблема: libcap и libcap-ng, policykit и т.д.
Поддержка libcap должна быть предусмотрена заранее, произвольный бинарник так не запустишь, так что это не аналог sudo.
polkit - да, в общем и целом согласен.
>Поддержка libcap должна быть предусмотрена заранееДолжна.
>произвольный бинарник так не запустишь
Вообще ненужно его запускать.
Год назад в polkit была уязвимость (CVE-2021-4034, до сих пор название помню, т.к. курсач про неё писал) с повышением привилегий, pkexec там только запрашивает разрешение, запускает сам, поэтому ему нужен suid-бит.
Если скорректировать причинно-следственные связи, то это ядру нужно знать, привилегии каких потоков исполнения допустимо повышать. suid-бит ставится на файл, причём произвольный. Задачу возможно решить аккуратнее, создав список разрешённых файлов и их хешей. К такому, кстати, и идёт RedHat с цифровыми подписями.
А почему костыль то? Костыль - это обходное временное решение взамен нормального. Судо вполне самодостаточное решение, решающее свою задачу.
Так это и есть дёшево и сейчас, переложив целиком всю заботу вон на тех ребят, мол, не наши проблемы. Из убунтят уже выросли поколения хипстеров по песню "коко под рутом низя работать лучше вот вам ALL=(ALL) NOPASSWD: ALL".
Не только sudo./usr/sbin/pam_timestamp_check
/usr/sbin/unix_chkpwd
/usr/sbin/userhelper
/usr/sbin/mount.davfs
/usr/sbin/grub2-set-bootflag
/usr/sbin/usernetctl
/usr/lib/polkit-1/polkit-agent-helper-1
/usr/bin/fusermount
/usr/bin/at
/usr/bin/sudo
/usr/bin/chfn
/usr/bin/pkexec
/usr/bin/firejail
/usr/bin/mount
/usr/bin/chage
/usr/bin/crontab
/usr/bin/chsh
/usr/bin/passwd
/usr/bin/umount
/usr/bin/gpasswd
/usr/bin/su
/usr/bin/newgrp
/usr/bin/fusermount3
/usr/libexec/dbus-1/dbus-daemon-launch-helper
/usr/libexec/ddccontrol/ddcpci
/usr/libexec/qemu/qemu-bridge-helper
/usr/libexec/Xorg.wrap
/opt/google/chrome/chrome-sandbox
chrome-sandbox? Ему-то нафига setuid?
Очевидно, что бы повышать привилегии
> /opt/google/chrome/chrome-sandboxкак иронично
да,зачот.
Хром для изоляции запускает контейнер, а для запуска контейнера во многих дистрибутивах требуются права рута (а в тех, где не требуются, для этого используются USER_NS, которые тоже то ещё минное поле в плане безопасности). Поэтому эта песочница получает права рута через setuid, запускает контейнер, после чего сразу же лишает себя и прав рута, и возможности получить их снова. Это стандартный подход, и setuid почти всегда используется именно так: сразу после запуска получил права рута -> открыл ресурс, необходимый для работы, но доступный только руту -> лишил себя прав рута и возможности получить их снова, но ресурс сохранил -> начал работать.
эт всё понятно, но недоверие к методам корпорации бобра у меня уже лет пятнацт.
А в правельных дистрибутивах так:
ls -l /sbin/unix_chkpwd
-rwx--x--x 1 root root 38624 Feb 23 2020 /sbin/unix_chkpwd
getcap /sbin/unix_chkpwd
/sbin/unix_chkpwd = cap_dac_override+i
/etc/security/capability.conf:
cap_dac_override vasya
none *
Ну, без этого костыля было бы сложно apache запускать cgi/fast_cgi от имени пользователя, а не apache/www-data. А так есть апачик, который дёргает suexec(приложуху, что имеет setuid и запускает fastcgi от нужного юзверя), и у нас апачик от одного юзера работает, а обработчики php от другого запускаются. И таких приколов, когда костыль нужен, много. Емнип, у exim бинарь с подобными правами. Запускается от одного юзера процесс, выполняется от имени другого.
Шёл 2023-й год, а люди всё еще обсуждают проблемы shared hosting.Ещё 10 лет назад эта проблема решалась запуском динамических php-fpm-пулов, по пулу на пользователя, и mod_fcgid (хотя в большинстве случаев - если это не невменоз с километром реврайтов в htaccess - достаточно nginx).
Сейчас же проще просто назапускать контейнеров.
Что удобно, так это то, что этот же suexec позволял запустить от другого пользователя не только php. Незаменимая вещь, когда рута от сервака нет, а поадминить хочется.
> используется только для одной программыЭто не так. В разных дистрах по разному. Многие уже используют CAP. В многопользовательских системах subit на группу необходим для некоторых каталогов, для ACL нужен.
SUID оказывается и CAP необходим для понижения привилегий root: https://www.opennet.dev/openforum/vsluhforumID10/5622.html#12
По теме, в нормальных дистрах монтирование дисков в режиме записи, на рабочей системе, запрещено.
> в нормальных дистрах монтирование дисков в режиме записи, на рабочей системе, запрещено.Как и OverlayFS с FUSE.
> но используется только для одной программы - sudoЕсли ты не в курсе, что chromium устанавливает setuid бинарь. И много кто ещё, тот же firejail к примеру или xorg.
А в openwrt можно где-то посмотреть публикацию обновления пакетов?
У тебя на OpenWRT есть пользователи, которые могут монтировать файловые системы.
Звучит жутковато
Не уберегли, не досмотрели...
Бывает, чо...
А как запретить OFS на старых ядрах?
0 дней без уязвимости в непривилегированных user namespace
>принадлежащий пользователю root исполняемый файл с флагами setuid/setgid, доступным всем пользователям на записьЧего вы все привязались к setuid/setgid? Есть ли идиоты, у которых в системе исполняеме файлы "доступные всем пользователям на запись"?
Идея в том, чтобы создать образ ФС с такими файлами на другой машине, где есть root, а потом скопировать на другую, примонтировать его через FUSE и дальше по инструкции в новости.