В развиваемом компанией Red Hat фоновом процессе tuned, выполняющем автоматическую оптимизацию настроек оборудования и ядра в зависимости от текущей нагрузки, выявлена уязвимость (CVE-2024-52336), позволяющая локальному непривилегированному пользователю выполнить любые команды с правами root...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62307
У кого tuned включен, скажите - есть от него толк?
От scx_bpfland и ananicy импакт очень ощущается, про существование автотюнинга sysctl узнал только что.
> От scx_bpfland и ananicy импакт очень ощущается, про существование автотюнинга
> sysctl узнал только что.Во, ставь эту штуку :). Желательно необновленную конечн - и доступ по ssh вывеси, будь мужиком, запили CTF сервер, во! :)
Сам будь мужиком, попробуй в систему без пароля рута проникнуть.
> Сам будь мужиком, попробуй в систему без пароля рута проникнуть.Так я и не просил пароль рута, сабжа как раз вполне хватит и без него, так что системный тюнинг в подарок :)
Сабжа не хватит для удаленной эксплуатации. Как ты локальный доступ по ssh получил?
Я поставил. С профилем лоу летенси нетворк пинги действительно уменьшаются больше чем на порядок, локальные и до вертуалок превращаются в 5-7мкс вместо 70-100мкс.
Не знаю делает ли он что-нибудь сам по себе, но я на ноуте использую tuned-ppd чтобы управлять режимами энергосбережения из гнома
>У кого tuned включен, скажите - есть от него толк?если пароль рута забыл, то есть толк ) эффект подсчитать сложно, когда нагрузка неровная.
в целом, очередной пруф что не зря я сижу на OL8 до сих пор.
Я боюсь тебе рассказать про кровавый Ынтырпрайз на Cent7.
Новые уязвимости в продуктах редхат, не удивлен честно говоря...
Какая-то детская дыра. Просто создали dbus-ручку для запуска скриптов из под root'а. Архитектора на мыло.
> Какая-то детская дыра. Просто создали dbus-ручку для запуска скриптов
> из под root'а. Архитектора на мыло.Судя по гитхабу - это лабуда написаная на пиотне какими-то джунами. Архитект - слишком громкое слово для вот этого всего.
Как можно запускать сторонний код под root'ом?
Неплохо было бы, чтобы прилагался манифест безопасности по листу systemd-analyze security.
Какие caps нужны?
> Как можно запускать сторонний код под root'ом?Ну, как, теперь любой пользак может - вот - вызвать gdbus и выполнить все что пожелает. Заметьте, какая оптимизация! Теперь su и sudo нафиг не нужны - и можно вообще без пароля логинииться под рутом. Сплошные бонусы.
Тоже можно сказать про run0, systemd-run, pkexec и прочие "безопасные технологии" редхаты. Главное, что от "небезопасного", чужого, а также - неприятельски-неподконтрольного, sudo в дистрибутивах избавляются, а в своих дебусоподелках черные дырени, размерами с галактику, не видят.
Не дыра, а технологическое отверстие.
> В развиваемом компанией Red Hat фоновом процессе tuned, выполняющем
> автоматическую оптимизацию настроек оборудования и ядра в зависимости
> от текущей нагрузкиОтличная между прочим оптимизация, я всячески одобряю :). Пожалуйста не забывайте ставить продукцию супернужных питонистов от редхата :)
Вот и попались! Недавно на системе с арчем отвалился стандартный power-profiles-daemon, почитав, узнал что он уже не поддерживается и желательно поставить новую разработку от красной шапочки под названием tuned, которая еще и удобно обратно-совместима с предыдущей. Сразу удивился c количества новых фич и задумался о реализации всего этого добра, а вот оно и полезло! Опять рептилоиды-иллюминаты и агентства на три буквы лезут ко мне на локалхост!
> Недавно на системе с арчем отвалился стандартный power-profiles-daemon, почитав, узнал что он уже не поддерживается и желательно поставить новую разработкуТак в этом весь линoops. Хорошая иллюстрация для тех, кто рассказывает про то, что оно уже якобы готово для десктопа :-)
У меня не отвалился. ЧЯДНТ?
DBUS пора в ядро в виде KDBUS. Хоть аудит пройдет нормально.
Ушедшему работать в M$, Торвальдс когда-то показал палец на такое предложение.
Ядро итак превратилось в свалку. ИМХО, абсолютно тупиковый путь, полностью противоречащий концепции микроядер.
Линукс никогда не следовал этой концепции.
Так он нахер не сдался никому в ядре, kdbus будет тормозить ядро из-за лишних syscall, dbus сам по себе не оптимальный протокол по производительности с определенными архитектурными проблемами, нехватало еще, чтобы его в ядро впихнули, как критическую службу, которая будет отжирать ядерное процессорное время и вытеснять процессы. Все только проиграют от этого. Нужная нормальная и более производительная альтернатива dbus. И баг сам по себе не в DBUS, а в tuned. DBUS это лишь служба сообщений ни больше не меньше, со своими подписчиками и отправителями, слушатели подписываются на определенные сообщения и обрабатывают их, а отправитель может отправлять определенные типы сообщения. Тот же polkit агент во всех DE использует dbus для связи с polkit для повышения привилегий. Мне собственно все эти polkit и rtkit не нравятся, я их первым делом удаляю, и пересобираю компоненты зависящие от них, и ничего не запускают от обычного пользователя с правами root. Благо sway позволяет выкинуть весь этот хлам. Тому же pipewire не нужен rtkit, и он может быть собран без него, и нужные приоритеты процесса может через systemd получить. Меня вообще раздражает сам факт, что популярные дистрибутивы и DE начали запускать десятки не нужных мне служб, когда можно оставить только парочку и удалить не нужные компоненты и сделать систему более безопасной. Раньше всего этого не было, но последние годы это приобрело какой-то нездоровый характер, что разработчики дистрибутива хотят впихнуть все для малограмотных юзеров, и сделать вторую венду с управлением через ГУЙ.
Да он в юзерспейсе-то не тормозит.
> популярные дистрибутивы и DE начали запускатьВсегда так было, всякие индексаторы оптимизаторы и прочая, сам X кривокосой и состоит из сплошных костылей, наличие ГУИ меняет поведение системы, логику меняет, например, некоторые демоны запускаются по систем-д, но после установки графики их запускает ДЕ, и в систем-д их можно включать или отключать, не влияет никак. Конечно, можно заморачиваться пересобиранием, но зачем? отследить все не получится, проще утащить данные на отдельную систему - предсказуемую и подконтрольную, и подключаться с десктопа, ноута или телефона, и если гуи сломается, взломается, взбесится и объявит человекам войну, ну пусть, переустановить и ладушки.
Мне достаточно того что и в userspace DBUS может повесить всё на свете. На десктопе его убивал спектакль, на серверах - забыл что (может БД какая-то). В обоих случаях это неприемлемо. А на ноуте, когда резко ЦПУ уходит в 100% и ты не можешь сохранить документы, вообще опасно.
Ну там, где фодора-редхат-системд да, наворотили, сам видел. У меня в gentoo живет dbus спокойно.
Я всегда убивал dbus на всех системах. Теперь понятно что не зря.
А как у тебя софт общался друг с другом? Ну там где в зависимостях жестко оный требуется.Или ты просто админ локалхоста, и ставишь линуксы только в графическом режиме, потому что так тебе удобней?