В пакете sudo, применяемом для организации выполнения команд от имени других пользователей, выявлена уязвимость (CVE-2025-32463), позволяющая любому непривилегированному пользователю выполнить код с правами root, даже если пользователь не упомянут в конфигурации sudoers. Проблеме подвержены дистрибутивы, использующие файл конфигурации /etc/nsswitch.conf, например, возможность эксплуатации уязвимости продемонстрирована в Ubuntu 24.04 и Fedora 41...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63505
04/01/2025: Vulnerability report sent to Todd Miller (Sudo maintainer).07.05.2025 В Ubuntu 25.10 решено задействовать аналог sudo, написанный на Rust https://opennet.ru/63197-ubuntu
В Ubuntu оказывается неспроста начали менять sudo на sudo-rs.
В целом логичный шаг после замены дыряшечных coreutils, но да, забавно.
Мудро то оно может и да, но похоже что этот вид багов вполне можно и на rust допустить
Да, тут никаких переполнений буфера, use-after-free итп нет, ошибка логическая, никакой язык программирования от этого не спасёт
Сишники выдохнули с облегчением: наконец-то уязвимость, которая не вызвана некорректной работой с памятью! И раст объявляется автоматически плохим, потому что "именно от этой уязвимости бы не спас". Вот такой вот полет сишной мысли.
Комментатор на opennet пишет:> Да, тут никаких переполнений буфера, use-after-free итп нет, ошибка логическая, никакой язык программирования от этого не спасёт
и тут же прибегает хрусто-фанатик, жалуйющийся на каких-то сишников, который теперь выдыхают слишком свободно:
> Сишники выдохнули с облегчением: наконец-то уязвимость, которая не вызвана некорректной работой с памятью! И раст объявляется автоматически плохим, потому что "именно от этой уязвимости бы не спас". Вот такой вот полет сишной мысли.
Анон совсем не сектант, видящий везде атаку на своё божество, единственно верный ЯП rust, да... Не сектант!
Растобесие оно такое.
Это платные. У них набор нарративов. Стройность нарратива - не метрика. Количество - метрика.
>Анон совсем не сектант, видящий везде атаку на своё божество, единственно верный ЯП rust, да... Не сектант!Разумеется в мире только два языка c/c++ и rust. Ни ocaml, ни go, ни haskell, ни java, ни кучи других языков попросту не существует. А если Idris или ATS вспомнить, то сишников вообще инфаркт хватит.
>и тут же прибегает хрусто-фанатик, жалуйющийся на каких-то сишников, который теперь выдыхают слишком свободно:Правильно и делает. Поскольку сишник выдыхающий свободно - это сишник, активно препятствующий развитию типизации. Если о том, чтобы использовать беззнаковые числа в качестве указателей плохо, уже даже крестовики начали, то вот идея, что строка не годится для файловых путей и тем более для корней файловой системы - вот тут уже загвоздка.
Вот вам самый простейший пример:
Eio_main.run (fun env -> Eio.Path.read_dir (Eio.Path.(Eio.Stdenv.cwd env / "../")))
Данный код прямо в рантайме проверит, есть ли возможность писать по данному пути, и выкинет ошибку, так как осуществляется выход за границы разрешённой облоасти. Попрошу заметить, что данную проверку с помощью символических ссылок вы не обойдёте. Да, здесь есть куда расти, но кодеры на ocaml уже сделали важнейший шаг вперёд, который сишники не сделали и за полвека - догадались перестать использовать сырые строки. Но сишники хотят плодить баги, ибо у них даже строк до сих пор нет, что уже о специальных типах говорить.
> хрусто-фанатикНе вижу в его словах ничего связанного с хрустом. Он точно фанатик?
Так и есть. Как Сишник, я счастлив.
Я много и давно пишу на C и C++. Не помню, чтобы вообще были проблемы с памятью. Проблемы с памятью -- это логические ошибки и полную ответственность за них несет исключительно программист.
Есть несколько простых правил, следование которым снижает вероятность ошибок с памятью, полученной из кучи, реально до нуля. И всегда memcheck не взирая ни на что. Также не забываем, что у нас есть VLA и небольшие области памяти можно выделять в стеке вместо кучи. Не всегда, но тем не менее.
Здесь использование юниксового легаси говна nsswitch, есть большая вероятность что в новом софте такая дрянь не будет поддерживаться и проблемы не будет.
А что будет вместо?
Очень даже может спасти. Rust прививает хорошие практики программирования. Отсюда и логику проще увидеть. Я бы ещё функциональщину рассмотрел, Haskell там...
Да ты насмешил. Ты видел код на расте, его синтакасис? Человек, у которого привиты хорошие практики, на расте писать не будет. Без обид. Это база.
Да, видел код. Мне понравилось. Никто не приводил на opennet примера, поэтому предположу, что им "рыбки" не понравились. А вообще там столько сахара и других удобств, что синтаксис простителен.
С другой стороны, если какой-то класс ошибок полностью предотвращён, остаётся больше времени для поиска и предотвращения ошибок из других классов. Помимо этого наличие встроенного мощного анализатора и прочей инфраструктуры так же помогает в отлавливании ошибок. Даже такие штуки, как единый стиль форматирования кода, вносят свою лепту.Так что при сравнимых трудозатратах, код на Rust будет содержать меньше логических ошибок. Возможно на языках вроде Haskell в этом плане ситуация ещё лучше, там нужно быть аутистом высшего порядка, что в свою очередь является порогом входа. Это работает и в другую сторону. Языки вроде JavaScript в среднем содержат большее число логических ошибок и для подобных языков обязательно нужны средства вроде сборки мусора. Среднее качество этих программистов ниже и вероятность, с которой они начнут портить память, стремится к единице.
> Мудро то оно может и да, но похоже что этот вид багов
> вполне можно и на rust допуститьНе правда, по мнению opennetовцев Rust не умеет динамическую линковку, а тут баг как раз с ней
Шах и мат, эксперты.
> не умеет динамическую линковку
Во-первых, у Rust нет стабильного ABI, что требует при его использовании перекомпиляции всей системы и всех установленных в ней приложений при выходе новой версии компилятора, что на практике не реализуемо. Но C ABI он поддерживает. Само собой, как только начинается C ABI, сразу заканчивается встроенный в Rust механизм безопасной работы с памятью.Во-вторых, даже в случае Rust ABI, в его текущем виде, при динамическом связывании нет поддержки дженериков.
Во-третьих, баг не с динамическим связыванием, а с алгоритмом его использования.
К сожалению, сообщество Rust очень мало уделяет внимание этой проблеме. Пожалуй, только разработчики Rеdox озабочены этой проблемой. В первую очередь Anhad Singh, за что я ему очень благодарен. Но его решение всё же является костылем через C ABI, а не средством, предоставляемым компилятором.
>и всех установленных в ней приложений при выходе новой версии компилятора, что на практике не реализуемо.Более чем реализуемо. Но разумеется не в допотопных арчах и дебианах.
Ну да. Я слышал о гентушниках, пересобиравших мир с LibreOffice, KDE и т.п. по несколько суток. Естественно, обычны были ситуации, когда оно просто так не собиралось. Сколько процентов таких пользователей?И точно знаю, что больше половины населения планеты скачивать по сотне гигабайт кем-то пересобранных всех своих приложений с системой каждые три месяца позволить себе не могут. Это не считая того, что подавляющее большинство поставщиков программного обеспечения, включая компьютерные игры, пересобирать и распространять свои продукты бесплатно не станут. Особенно с учетом того, что переход на новую версию Rust компилятора и stdlib часто приводит к необходимости правки кода.
>Я слышал о гентушникахБинарный кеш изобретён.
>больше половины населения планетыЭто кто?
>скачивать по сотне гигабайт кем-то пересобранных всех своих приложенийДаже если пересобирать буквально весь софт, сотни гигабайт не будет. Посмотрите на размер ISO образов, там даже восьми гигабайт за раз нет.
>с системой каждые три месяца позволить себе не могутДля условной убунты или дебиана, замораживающих версии на весь релиз это вообще никак не повлияет.
>Это не считая того, что подавляющее большинство поставщиков программного обеспечения, включая компьютерные игры, пересобирать и распространять свои продукты бесплатно не станут.nix давным давно изобретён, когда несколько библиотек сосуществуют без ручного вмешательства.
>Особенно с учетом того, что переход на новую версию Rust компилятора и stdlib часто приводит к необходимости правки кода.У раста давным давно изобретены editions. Хватит людей вводить в заблуждение.
Рекомендую, хотя бы изредка смотреть в календарь. 1970-ые давно прошли.
>>Я слышал о гентушниках
> Бинарный кеш изобретён.И чем он поможет, если необходима полная перекомпиляция?
>>больше половины населения планеты
> Это кто?Это те ~5 миллиардов населения планеты, которые не имеют доступа к широкополосному интернету. Поинтересуйтесь тарифами на мобильный интернет хотя бы в РФ. А к проводному интернету в РФ имеют доступ менее 40 миллионов человек. Тоже явно меньше половины населения страны.
>>скачивать по сотне гигабайт кем-то пересобранных всех своих приложений
> Даже если пересобирать буквально весь софт, сотни гигабайт не будет. Посмотрите на
> размер ISO образов, там даже восьми гигабайт за раз нет.Вы пользуетесь исключительно голой системой? У той же Ubuntu 24.04 размер репозитория больше 2ТБ. Со сторонними репозиториями будет на порядок больше.
А на NAS у сына только дистрибутивы игр уже в 4 ТБ не помещаются.
Особенно интересно узнать, что Вы предлагаете делать с программными продуктами, которые необходимы в работе, но уже давно не поддерживаются по причине прекращения деятельности их производителя? Закупать новый МРТ за 100 миллионов рублей только потому, что в какой-то системной библиотеке обнаружена уязвимость, а поставщик свой софт уже пару лет как не обновляет?
Ваш призыв к столь глобальному вендор-локу уж очень сильно противоречит идеологии opennet.> nix давным давно изобретён, когда несколько библиотек сосуществуют без ручного вмешательства.
Исключительно благодаря стандартизированному C ABI. Вы вообще понимаете разницу, между сменой версии библиотеки и глобальному изменению ABI во всей системе и всех приложениях?
>>Особенно с учетом того, что переход на новую версию Rust компилятора и stdlib часто приводит к необходимости правки кода.
> У раста давным давно изобретены editions. Хватит людей вводить в заблуждение.Редакции редакциями, а крейты - крейтами. Ошибки и уязвимости даже в stdlib исправляются исключительно в новых версиях. Не говоря уже о прочих крейтах.
Вы вообще на Rust ведете разработку или только теоритезируете? Мне, как минимум, дважды в год приходится вносить правки в свой код из-за необходимости переходить на новые версии крейтов.
Последний сюрприз был в Rust 1.85, когда core::ffi::c_char из i8 превратился в u8.
>И чем он поможет, если необходима полная перекомпиляция?Это может быть проблемой только для тех, кто поддерживает бинарный кеш, но не для конечных пользователей.
>Это те ~5 миллиардов населения планеты, которые не имеют доступа к широкополосному интернету.Теперь осталось как-то выяснить, у кого из них есть компьютеры, при чём не на 98 винде.
>Поинтересуйтесь тарифами на мобильный интернет хотя бы в РФ.Тарифы в РФ довольно щадящие, в некоторых обласях сразу 100 Гб за месяц можно купить, без дополнительных пакетов. Так что ищите другие страны.
>А к проводному интернету в РФ имеют доступ менее 40 миллионов человек. Тоже явно меньше половины населения страны.Опять же, нужно узнать, скольки из них вообще используют компьютеры. Ибо у одних компьютера не будет, будет только смартфон, а у кого-то и смартфона не будет.
>Вы пользуетесь исключительно голой системой? У той же Ubuntu 24.04 размер репозитория больше 2ТБ. Со сторонними репозиториями будет на порядок больше.Я сомневаюсь, что легко будет найти человека, который будет использовать все эти 2 Тб за раз. Тем более, что в репозитории будет куча софта на других языках, типа python, java, и так далее.
>Особенно интересно узнать, что Вы предлагаете делать с программными продуктами, которые необходимы в работе, но уже давно не поддерживаются по причине прекращения деятельности их производителя? Закупать новый МРТ за 100 миллионов рублей только потому, что в какой-то системной библиотеке обнаружена уязвимость, а поставщик свой софт уже пару лет как не обновляет?Ну а сейчас что вы делаете? Я крайне сомневаюсь, что кто-то сейчас будет трогать мрт лишний раз, так как денег за это не платят. Тем более, что самостоятельное вмешательство в код для мрт может как окирпичить сам аппарат, так и нарушить целостность кода, за которой следит защита от пиратов. Много вы условный фотошоп или идею патчите?
>Ваш призыв к столь глобальному вендор-локу уж очень сильно противоречит идеологии opennet.Хватит придумывать вендорлок там, где его нет.
>Исключительно благодаря стандартизированному C ABI.Си ABI здесь совершенно не причём. Nix умеет собирать воспроизводимые окружения так, чтобы несколько библиотек с разными ABI могли сосуществовать вместе, на одной машине. Там требования к коду минимальны, типа номеров системных вызовов, abi условного xorg-а. У вас просто будет столько версий библиотек, сколько нужно, чтобы запустить всё это дело.
>между сменой версии библиотеки и глобальному изменению ABI во всей системе и всех приложениях?Если api поменять, то abi тоже неизбежно изменится. Можете даже не надеяться, что если код под qt4, не собирающийся под qt6, сохранит abi.
>Мне, как минимум, дважды в год приходится вносить правки в свой код из-за необходимости переходить на новые версии крейтов.Крейты не зависят так сильно от версии компилятора. Можно обновить версию компилятора, не меняя трейты, можно обновить трейты, не меняя версию компилятора. Всегда есть какой-то минимальный диапазон, в пределах которого можно пользоваться двумя разными версиями компилятора.
> Я сомневаюсь, что легко будет найти человека, который будет использовать все эти 2 Тб за раз.Спасибо, что доказали, что Вы демогог или слишком глупы, что отличить 5% от 100%:
>>>скачивать по сотне гигабайт кем-то пересобранных всех своих приложений
На том дискуссию можно считать завершённой )
> Во-вторых, даже в случае Rust ABI, в его текущем виде, при динамическом связывании нет поддержки дженериков.И как ты это видишь?
Есть библиотека:
pub fn print_smth<T: Display>(value: &T) {
println!("{value}");
}
pub fn init() {
print_smth("The library has been initialized");
}Библиотеку собрали, print_smth для нужд библиотеки мономорфизировало для &str
Внешний пользователь хочет передать в этот метод u32
Вопрос - откуда в этой библиотеке возьмётся мономорфизация print_smth для u32?
> И как ты это видишь?Для начала нужна хотя бы поддержка RTTI в ABI. И речь далеко не только о POD типах.
В Rust сейчас нет способа указать, для каких типов должен быть скомпилирован код в динамически загружаемой библиотеке. И нет встроенных средств рефлексии, чтобы во время выполнения выяснить, какие типы поддерживаются в динамически загружаемой библиотеки. Крейт rtti в данном случае лишь костыль.
> Для начала нужна хотя бы поддержка RTTI в ABI. И речь далеко
> не только о POD типах.Ну допустим для динамической диспатчеризации добавят RTTI (Хотя для Rust это и не нужно, у тебя же нет иеархии классов)
Что делать со статической? И какое это отношение имеет к генерик типам (шаблонам в случае плюсов)?
> Хотя для Rust это и не нужно, у тебя же нет иеархии классовНо есть виртуальные таблицы и дженерики. Отсюда и этот костыль https://docs.rs/rtti/latest/rtti/
Или этот https://docs.rs/vtable/latest/vtable/> какое это отношение имеет к генерик типам
Читйте внимательней:
>> для каких типов должен быть скомпилирован код в динамически загружаемой библиотеке.
>> И нет встроенных средств рефлексии, чтобы во время выполнения выяснить,
>> какие типы поддерживаются в динамически загружаемой библиотеки.В рамках идеологии Rust вполне реализуема поддержка дженериков в динамически загружаемой библиотеке, пусть и с ограничением не только на реализованные трейты, но и на типы, для которых будет скомпилирован код. Причем, с развитым RTTI можно поддерживать не только POD типы, но и структуры и перечисления, налагая определенные требования на присутствие только некоторых полей или типов в них.
Этой истории не первый год. Например, два года назад определенные попытки предпринимались joshtriplett в виде эксперимента с crabi https://github.com/rust-lang/rfcs/pull/3470
Но воз и ныне там (> шаблонам в случае плюсов
Шаблоны в C++ превращаются в боль на крупных проектах, когда малейшая правка требует многочасовой перекомпиляции всего кода. Поэтому я веду речь не о шаблонах, а об аналоге Itanium ABI для Rust.
> Но есть виртуальные таблицы и дженерики.Но ты же понимаешь что эти вещи ортогональны?
Там где у тебя generic типы - там у тебя статическая диспатчеризация
fn print_smth<T: Display>(v: T) {...}
fn print_smth(v: impl Display) {...}
Оба случая идентичны, и тут у тебя в рантайме никогда не будет vtable
В плюсах аналогом будет
template<typename T>
void print_smth(const T& v) {...}Никакой RTTI тебе тут не поможет, шаблон должен инстанцироваться в каждой библиотеке что хочет вызывать эту функцию
fn print_smth(v: &dyn Display) {...}
А вот тут уже будет vtable, и в плюсах код выглядит так:
interface Display {...}
void print_smth(Display& v) {...}
Тут уже действительно будет RTTI, и плюсовое ABI (которого, напоминаю, по стандарту не существует) это описывает, однако это не то как пишется большая часть Rust библиотек, в Rust таки почти везде применяется статическая диспатчеризация.
В плюсах у тебя конечно vtable всегда с собой есть, потому что не факт что девиртуализация в оптимизаторе gcc/llvm сработает, однако в Rust это не так, и vtable есть только тогда, когда она используется
Более того, в Rust у тебя инстансы структур с собой vtable не имеют, когда требуется vtable - оно передаётся вместе со структурой в fat pointerе
>> Но есть виртуальные таблицы и дженерики.
> Но ты же понимаешь что эти вещи ортогональны?В текущей реализации.
> Там где у тебя generic типы - там у тебя статическая диспатчеризация
Перечитайте:
>> В рамках идеологии Rust вполне реализуема поддержка дженериков в динамически
>> загружаемой библиотеке, пусть и с ограничением не только на реализованные трейты,
>> но и на типы, для которых будет скомпилирован код.И то, с чего начиналось:
>>>> В Rust сейчас нет способа указать, для каких типов должен быть скомпилирован код
>>>> в динамически загружаемой библиотеке. И нет встроенных средств рефлексии,
>>>> чтобы во время выполнения выяснить, какие типы поддерживаются
>>>> в динамически загружаемой библиотеки.
> В плюсах аналогом будетОпять у Вас проблемы со чтением:
>> я веду речь не о шаблонах, а об аналоге Itanium ABI для RustНо в C++ есть наследование и перегрузки, что позволяет весьма гибко обходиться без шаблонов. А в Rust этого нет.
Поэтому опять прошу Ваc научиться читать:
>> с развитым RTTI можно поддерживать не только POD типы, но и структуры и перечисления, налагая определенные требования на присутствие только некоторых полей или типов в них.
> Но в C++ есть наследование и перегрузки, что позволяет весьма гибко обходиться без шаблонов. А в Rust этого нет.Потому что это разные языки с разными подходами к решению проблем
В Rust нет необходимости обходиться без генерик типов, и все ими везде пользуются> В текущей реализации.
Нет, вообще нет. Даже задача сравнения идентичности двух типов нетривиальная, TypeId в Rust не работает стабильно в присутствии нескольких крейтов по разному инстанцирующих один тип, и это не та проблема которую кто-то планирует решать в языке, потому что это чисто архитектурно требует больших издержек.
Вместо этого кто хочет может реализовать свой механизм, посмотри на bevy например, у него и рефлексия, и UUIDы для типов, и всё прочее есть
Без всякой поддержки со стороны языка.
> В Rust нет необходимости обходиться без генерик типов, и все ими везде
> пользуютсяВот именно. Поэтому отказ от дженериков при динамическом связывание на решение проблемы никак не тянет.
>> В текущей реализации.
> Нет, вообще нет. Даже задача сравнения идентичности двух типов нетривиальная, TypeId в
> Rust не работает стабильно в присутствии нескольких крейтов по разному инстанцирующих
> один тип, и это не та проблема которую кто-то планирует решать
> в языке, потому что это чисто архитектурно требует больших издержек.Как раз решать пытаются так или иначе. Ну и ссылаться на размер издержек можно для локального проекта, но уж никак не для повсеместно используемого компилятора.
> Вместо этого кто хочет может реализовать свой механизм
И получаем динозавров, совместимых исключительно с самими собой.
> посмотри на bevy например,
> у него и рефлексия, и UUIDы для типов, и всё прочее
> естьЧто-то не вижу, как подключить к нему динамически связываемый модуль о котором он не знал ничего на этапе компиляции. Это возвращаясь к топку и PAM/NSS, в случае реализации их на Rust.
Ну и на стандарт он никак не тянет. Не предлагаете же Вы его затаскивать, например, в аналог OpenWRT на Rust, исключительно в целях поддержки динамического связывания?
> Этой истории не первый год. Например, два года назад определенные попытки предпринимались joshtriplett в виде эксперимента с crabi https://github.com/rust-lang/rfcs/pull/3470
> Но воз и ныне там (Только это совсем не то, про что ты говоришь
Оно не избавляет от необходимости явно описывать внешние функции, потенциальное crABI не будет дефолтом
Это лишь идея про то, что основные структуры в языке должны иметь какое-то стандартное представление, чтобы их можно было передавать через FFI boundary не конвертируя туда-сюдаОднако это всё рушится о то, что Rust намеренно не стабилизирует такие вещи, чтобы можно было всё оптимизировать, и это самое crABI всё равно требует данные туда-сюда копировать, чтобы структуры были совместимы с вещами вроде niche optimizations, и это "ABI" по итогу будет лишь удобным способом такие конверсии автоматизировать.
И зачем оно в таком случае нужно, если есть условный bindgen, который уже умеет это автоматизировать, но при этом не требует создавать некий crABI и поддерживать его на уровне языка?
> Только это совсем не то, про что ты говоришьЭти вопросы подняты тут https://github.com/rust-lang/rust/issues/111423
> Оно не избавляет от необходимости явно описывать внешние функции, потенциальное crABI не
> будет дефолтомcrabi даже как экспериментальная возможность пока не принято. А по уму, нужно несколько разных подходов и сравнение между ними, прежде чем один из них станет не экспериментальным.
> Однако это всё рушится о то, что Rust намеренно не стабилизирует такие
> вещи, чтобы можно было всё оптимизироватьНо цена этого - фактический отказ от встроенной в язык безопасности работы с памятью при динамическом связывании. Даже в Redox пришлось для этого изобретать костыли через C ABI.
> И зачем оно в таком случае нужно
Например для того, чтобы тот же sudo в coreutils-rs могли работать с PAM/NSS, написанными на Rust, без утери контроля компилятором над безопасностью при работе с памятью на стыке C ABI.
И само собой, без требования перекомпиляции всего мира одной конкретной версией rustc.
Если Вы не понимаете, зачем нужен стабильный Rust ABI, то попробуйте поработать с кодовой базой размером хотя бы свыше гигабайта.
> Эти вопросы подняты тут https://github.com/rust-lang/rust/issues/111423Какие вопросы? Я говорю про то что crabi не решает и половины проблем со стабильным abi, это лишь прослойка чтобы вообще все типы не превращать в C-совместимые
> crabi даже как экспериментальная возможность пока не принято. А по уму, нужно
> несколько разных подходов и сравнение между ними, прежде чем один из
> них станет не экспериментальным.Есть несколько проектов которые на макросах реализуют безопасный FFI как с Rust, так и с другими языками, зачем подобное встраивать в язык?
> Но цена этого - фактический отказ от встроенной в язык безопасности работы
> с памятью при динамическом связывании. Даже в Redox пришлось для этого
> изобретать костыли через C ABI.Проблема решается без изменения языка, почему же это костыль? Отказа от безопасности тут никакого нет при правильно выбранных абстракциях.
> Например для того, чтобы тот же sudo в coreutils-rs могли работать с
> PAM/NSS, написанными на Rust, без утери контроля компилятором над безопасностью при
> работе с памятью на стыке C ABI.У Rust вся сила в абстракциях, никто тебе не мешает использовать C ABI, но в безопасной обёртке. Да можно даже по обе стороны ffi boundary иметь zero-copy сериализацию/десериализацию, для передачи данных этого более чем хватит, и порвать такой кондом не выйдет, и при правильной реализации потреблять больше чем "правильный" ffi оно не будет.
А также это будет реально безопасно, потому что как ты собираешься иначе гарантировать что у тебя по обе стороны ffi boundary никто не менял порядок полей в структуре, и при проходе через ABI она не превратилась в тыкву?
> Если Вы не понимаете, зачем нужен стабильный Rust ABI, то попробуйте поработать
> с кодовой базой размером хотя бы свыше гигабайта.Ежедневно работаю
Гигабайта исходников конечно нет, но 200мбайт найдётся, если зависимости не считать, зачем нужно crabi мне не понятно.
>> Эти вопросы подняты тут https://github.com/rust-lang/rust/issues/111423
> Какие вопросы?А Вы всё же постарайтесь не быть чукчей-писателем и почитать то, что написано по ссылке.
> Я говорю про то что crabi не решает и половины
В первых пяти PR - да.
> Есть несколько проектов которые на макросах реализуют безопасный FFI как с Rust,
> так и с другими языками, зачем подобное встраивать в язык?Вы уж простите, но такой "безопасный" FFI реализуем вообще на любом языке. В том числе на C/C++. И тогда возникает резонный вопрос, а зачем тогда нужен Rust )))
"Безопасный" в кавычках, потому что на стороне динамически связываемого модуля без развитого RTTI нет никакой возможности определить, насколько корректные параметры пришли на вход через C ABI.
Если на пальцах, как в динамически связываемом модуле узнать, что вместо
enum DeviceAddr {
AD0,
AD1,
}
передан
enum DeviceAddr {
AD0,
AD1,
AD2,
}
?Естественно, я хочу, чтобы динамически связываемый модуль, ничего не знающий о AD2, успешно работал с параметром типа DeviceAddr, когда он принимает значения только AD0 и AD1. Но возвращал ошибку, если вдруг обнаруживал в enum неизвестный ему подтип. Отдельный вопрос с переменным количеством параметров.
Или мы опять приходим к необходимости перекомпиляции и разворачивании кода всей инфраструктуры, лишаясь преимуществ динамического связывания.
Естественно, на фазе прототипирования подобные проекты реализуются вручную, дублируя метаданные, которые уже известны компилятору. Это как слоты, сигналы и компилятор метаданых в Qt, которые были необходиимы в отсутствии стандарта C++ ABI. Вот только на стандартное средство взаимодействия, применимое в любых проектах, оно ну никак не тянет.> ffi boundary иметь zero-copy сериализацию/десериализацию, для передачи данных этого более
> чем хватит, и порвать такой кондом не выйдет, и при правильной
> реализации потреблять больше чем "правильный" ffi оно не будет.Не надо мне D-Bus рекламировать. Он, конечно, хорош, но потребляет явно больше, чем ABI. Даже MS COM он по производительности проигрывает. Для десктопных задач он применим, но для высоконагруженных систем - уже нет.
> как ты собираешься иначе
> гарантировать что у тебя по обе стороны ffi boundary никто не
> менял порядок полей в структуре, и при проходе через ABI она
> не превратилась в тыкву?RTTI
>> Если Вы не понимаете, зачем нужен стабильный Rust ABI, то попробуйте поработать
>> с кодовой базой размером хотя бы свыше гигабайта.
> Ежедневно работаю
> Гигабайта исходников конечно нет, но 200мбайт найдётся, если зависимости не считать, зачем
> нужно crabi мне не понятно.Только не уточнили, что код на Rust из этого занимает пару мегабайт? Или речь о сотне мелких проектов?
Даже сотня мегабайт кода без динамического связывания не взлетит в продуктиве. А использование кастомного динамического связывания, как в Redox, превращает проект в динозавра совместимого только с самим собой. И здравствуй nostd.
>>> Эти вопросы подняты тут https://github.com/rust-lang/rust/issues/111423
>> Какие вопросы?
> А Вы всё же постарайтесь не быть чукчей-писателем и почитать то, что
> написано по ссылке.
>> Я говорю про то что crabi не решает и половины
> В первых пяти PR - да.Вообще не решает, всё что добавляет crabi вполне решается и другими средствами
> Вы уж простите, но такой "безопасный" FFI реализуем вообще на любом языке.
> В том числе на C/C++. И тогда возникает резонный вопрос, а
> зачем тогда нужен Rust )))Потому что FFI это малая часть любой программы, не везде нужны плагины
> Но возвращал ошибку, если вдруг обнаруживал в enum
> неизвестный ему подтип.Исходя из этого требования мы понимаем что ты хочешь сериализацию, а не ABI
Потому что это не ABI> Не надо мне D-Bus рекламировать. Он, конечно, хорош, но потребляет явно больше,
> чем ABI. Даже MS COM он по производительности проигрывает. Для десктопных
> задач он применим, но для высоконагруженных систем - уже нет.D-Bus не zero-copy, и он не через ffi boundary работает а через сокеты, естественно он медленнее
COM с его IDL по ближе (не работал с ним), но всё ещё не то. Я скорее про Cap'n Proto/Flat Buffers/прочее
ABI это по сути и есть zero-copy сериализация/десериализация, просто в данной сериализации у тебя очень мало поддерживаемых типов> Только не уточнили, что код на Rust из этого занимает пару мегабайт?
> Или речь о сотне мелких проектов?
> Даже сотня мегабайт кода без динамического связывания не взлетит в продуктиве.Работаю в большой кодбазе, тут много крейтов связанных статически
Время линковки конечно неприятно, однако для дебаг билдов можно использовать mold/wild - и это уже не становится существенной проблемой.Моя кодбаза проприетарная, однако опенсорс тоже есть подобных масштабов, и успешно живёт, вот как пример - https://github.com/paritytech/polkadot-sdk, да даже сам Rust динамическую линковку использует крайне условно (rustc-driver работает используя обычное Rust ABI)
Зачем в одной кодбазе использовать несколько версий компилятора вообще? Или ты говоришь про монорепы, в которых гугл и прочие себе сами кучу проблем создают?
>> А Вы всё же постарайтесь не быть чукчей-писателем и почитать то, что
> Вообще не решает, всё что добавляет crabi вполне решается и другими средствамиПрочитайте внимательно всё же по ссылке. Особенно пункт про дженерики.
>> Вы уж простите, но такой "безопасный" FFI реализуем вообще на любом языке.
>> В том числе на C/C++. И тогда возникает резонный вопрос, а
>> зачем тогда нужен Rust )))
> Потому что FFI это малая часть любой программы, не везде нужны плагиныБез них можно обходиься только в небольших или в нетиражируемых проектах. Иначе начинается большая боль.
>> Но возвращал ошибку, если вдруг обнаруживал в enum
>> неизвестный ему подтип.
> Исходя из этого требования мы понимаем что ты хочешь сериализацию, а не
> ABI
> Потому что это не ABIItanium ABI без проблем позволяет работать с объектами унаследованных и перегруженных классов.
>> Не надо мне D-Bus рекламировать. Он, конечно, хорош, но потребляет явно больше,
>> чем ABI. Даже MS COM он по производительности проигрывает. Для десктопных
>> задач он применим, но для высоконагруженных систем - уже нет.
> ABI это по сути и есть zero-copy сериализация/десериализация, просто в данной сериализации
> у тебя очень мало поддерживаемых типовВы вообще знакомы с Itanium ABI?
> Работаю в большой кодбазе, тут много крейтов связанных статически
> Время линковки конечно неприятно, однако для дебаг билдов можно использовать mold/wild
> - и это уже не становится существенной проблемой.Ну не верю. И время сборки тут не столь критично, сколько время на разворачивание на множество инстанцов или POD-ов. Если при динамическом связывании патчи почти всегда накатываются вообще без простоя системы, то без него доступность системы начинает очень сильно страдать.
Я уже молчу о том, на хостах k8s без динамического связывания потребление памяти возрастает в несколько раз, если не на порядок. А хост с 256ГБ RAM и хост с 2ТБ RAM - уже очень различаются по стоимости.> Зачем в одной кодбазе использовать несколько версий компилятора вообще?
Например, для того, чтобы не деплоить в десятки тысяч мест суммарно терабайты, ограничиваясь распространением только изменений.
Если на пальцах, возвращаясь к теме топика. Что проще, исправив ошибку в sudo, распростанить только sudo, или распространять всю систему со всеми установленными в ней приложениями, чтобы всё было собрано одной версией компилятора?
Тут программист не в звездочках заблудился а в слешах. Это пофиксят в NGR (NextGenRust), пока же раст как обычно бессилен. Программист победил.
А как это поможет если sudo-rs такой же комбайн как sudo?
Но безопасТный комбайн.
Все в порядке, он не такой же.
Авторы заявляли что конечной их целью является поддержка дефолтного конфига популярных дистрибутивов.А там root = (ALL) ALL
и больше ничего нет.
Ну, разработчики doas не смогли и этого...
А они и не спят!(и да, удивительно уродский синтаксис, при том что синтаксис конфига это единственное достоинство как раз sudo, и даже описание его есть в виде, готовом к скармливанию в транслятор. Но нет, надо было вот то череззадничное нечитаемое в принципе притащить.)
> А они и не спят!
> (и да, удивительно уродский синтаксис, при том что синтаксис конфига это единственное
> достоинство как раз sudo, и даже описание его есть в виде,
> готовом к скармливанию в транслятор. Но нет, надо было вот то
> череззадничное нечитаемое в принципе притащить.)Не, ну если (В след за авторами) предполагать, что правил у тебя будет - ну вот ДВА (И те - дефолтные) - то жить наверное можно; а вот портянка этого вперемешку - боль, конечно. Еще и нет возможности из conf.d правила заинклудить ансибляторам на радость, ага.
Хотя - кто крупный haproxy крутил - такого не боится ).
Одно с другим не связано. Здесь логическая ошибка. Rust никаким образом здесь не помог бы.
Этот баг вызван не ошибкой в работе с памятью. Тут rust никак не помог бы.
"Безопасная работа с памятью" как-то обезопасит от детских ошибок с выбором не того файла?
> В Ubuntu оказывается неспроста начали менять sudo на sudoТут раст не причём. Вообще не по делу комментарий
Блин, ну ты новость-то почитай прежде чем комментарии писать, тролль.
Я начинаю видеть некоторую мудрость людей из OpenBSD, породивших doas.
Да, doas рулит, а для рядовых задач и вовсе хватает su.
> Да, doas рулит, а для рядовых задач и вовсе хватает su.Как бы это сказать... su _принципиально_ не подходит для задач, отличных от "однопользовательских локалхостов" по причине невозможности гранулярного управления полномочиями и отсутствию какого-либо вменяемого аудита.
doas в этом плане несколько лучше - но малопригодный для автоматизированной работы синтаксис или хотя бы отсутствие возможности заинклудить свои правила из отдельного файлика в conf.d изрядно портят впечатления.
>> Да, doas рулит, а для рядовых задач и вовсе хватает su.
> Как бы это сказать... su _принципиально_ не подходит для задач, отличных от
> "однопользовательских локалхостов" по причине невозможности гранулярного управления
> полномочиями и отсутствию какого-либо вменяемого аудита.
> doas в этом плане несколько лучше - но малопригодный для автоматизированной работы
> синтаксис или хотя бы отсутствие возможности заинклудить свои правила из отдельного
> файлика в conf.d изрядно портят впечатления.Есть ли разница создавать ansible'ом два файла или писать через шаблон в один? Все равно руками никто серверы не конфигурирует уже много лет.
>>> Да, doas рулит, а для рядовых задач и вовсе хватает su.
>> Как бы это сказать... su _принципиально_ не подходит для задач, отличных от
>> "однопользовательских локалхостов" по причине невозможности гранулярного управления
>> полномочиями и отсутствию какого-либо вменяемого аудита.
>> doas в этом плане несколько лучше - но малопригодный для автоматизированной работы
>> синтаксис или хотя бы отсутствие возможности заинклудить свои правила из отдельного
>> файлика в conf.d изрядно портят впечатления.
> Есть ли разница создавать ansible'ом два файла или писать через шаблон в
> один? Все равно руками никто серверы не конфигурирует уже много лет.Ну, как? Одно дело атомарная операция вида "добавил готовый файлик с правами на группу - - удалил файлик", другое - работа с изрядно кривым\косым синтаксисом в котором хрен пойми, сколько никак и ничем не отличающихся друг от друга опций и аргументов.
>Ну, как? Одно дело атомарная операция вида "добавил готовый файлик с правами на группу - - удалил файлик", другое - работа с изрядно кривым\косым синтаксисом в котором хрен пойми, сколько никак и ничем не отличающихся друг от друга опций и аргументов.Реально никакой разницы. Первое ещё и удобнее, потому что шаблонизируется.
Ну, если вы так говорите...
Но пока ни в одном из тырдырпайсов do-ass'ов не видел, и не думаю, что в ближайшее время увижу.
> Ну, если вы так говорите...
> Но пока ни в одном из тырдырпайсов do-ass'ов не видел, и не
> думаю, что в ближайшее время увижу.Это слегка ортогональные вещи. Не увидишь ты его не потому что там нельзя файлик положить.
>> Ну, если вы так говорите...
>> Но пока ни в одном из тырдырпайсов do-ass'ов не видел, и не
>> думаю, что в ближайшее время увижу.
> Это слегка ортогональные вещи. Не увидишь ты его не потому что там
> нельзя файлик положить.Твоя правда.
Их мудрость в том, что вышеупомянутый косяк sudo изначально в опене не работает в виду отсутствия условий для этого :)
Неуловимого Джо вы начинаете видеть.
Это настолько феерично, что я никогда в жизни не поверю, что это не закладка.
Поражает воображение, насколько ВСЁ дырявое..
Так что согласен про закладки. Иначе, нужно быть полными лохами, чтобы за столько десятилетий не закрыть их все, раз уж пишешь этот софт с умным.
Не факт. Это скорее следствие так называемой "bazaar" методологии разработки. Вместо того, чтобы пользоваться системными либами, оно само тупо лезет в этот файл. А поскольку это, как водится, делается "напролом" - вот и косяки прут косяками.
И ещё отсутствия достаточного количества юнит-тестов (не тестов всей программы). На языках типа C/C++ это делается сложнее чем языках без управления памяти. А значит часто забивают.
> На языках типа C/C++ это делается сложнее чем языках без управления памяти.Абсолютная глупость.
Ни в коем случае, сэр.
Закладка, внедренная под предлогом новой фичи.
Скажу наивность - microsoft давно владеет sudo. Нынешний разработчик, Todd C Miller, является иноагентом ^W^W давно понял в чем суть опенсорца и получает финансирование от мелкомягких. Причем опенбсдшники это давно поняли и выкатили doas. Тут закладка, тут не ошибка.
> Скажу наивность - microsoft давно владеет sudo. Нынешний разработчик, Todd C Miller,
> является иноагентом ^W^W давно понял в чем суть опенсорца и получает
> финансирование от мелкомягких. Причем опенбсдшники это давно поняли и выкатили doas.
> Тут закладка, тут не ошибка."I also work on OpenBSD"(С), ога. Ох, это другое!
Уязвимость - жуть.Только что проверил полностью пропатченную Fedora 42:
./pown.sh
woot!
[root@zen /]# id
uid=0(root) gid=0(root) groups=0(root),39(video),63(audio),1010(testuser) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023Жаль, нет такой для Android.
Любая админ утилита вообще это шкатулка-разгадайка. Можно напхать туда "ребусов" как такой условный пароль до рут данной утилиты и эксплуатировать для себя.
>./pown.sh
>woot!
>[root@zen /]# idЯ так понимаю, что root создается внутри чрута woot, в котором (сюрприз!) необходимо иметь права записи и удаления. Т.е. для поднятия привелегий требуется уже иметь их.
Как обычно очередной академический "сферический конь".
"Но в песне не понял ты, увы, ни...чего"(С)
А если все-таки попробовать включить голову и подумать (с)
"... да и было ли ему чем?"(С)
chroot - это всё равно, что папку через cd сменить, он рута не изолирует от ресурсов системы от слова совсем. После чрута в пустую папку (только с нужными файликами для взлома жепы), делаете mount -t devfs devfs /dev и получаете доступ ко всем девайсам подключенным к системе.
>После чрута в пустую папку ... делаете mountТы хоть понимаешь, что такое chroot? Откуда в пустой папке возмется mount?
В школу, за парту.
>>После чрута в пустую папку ... делаете mount
> Ты хоть понимаешь, что такое chroot? Откуда в пустой папке возмется mount?ну так положи его туда!
За чем дело стало?
Сам то пробовал этот скрипт?
Я вот попробовал, и у меня корневая директория доступна под рутом
Потому что chroot не сработал, но root выполнил зловред из папки доступной для записи пользователю.
И к чему это? Мне пофиг как сработает, рут появился в руте. Изначально вопрос был chroot, который я вообще не заметил в скрипте
> И к чему это? Мне пофиг как сработает, рут появился в руте.
> Изначально вопрос был chroot, который я вообще не заметил в скрипте"Молчи, смерд! Мы обсуждаем идеального, метафизического таракана!"(С)
Коллеги, так сколько там лап у животного? Аристотель писал, что 8...
> Изначально вопрос был chroot, который я вообще не заметил в скриптеа он там - есть.
(chroot не меняет cwd. Учитывая что этот дятел забыл про nsswitch - он наверное и про это тоже забыл. )
нет там chroot, ты понял неправильно.
нужное создается в /tmp/sudo.stage.... и chroot из sudo на /tmp/sudo.stage....
Сколько не обновляйся все равно пользователя, извиняюсь за выражение, отымеют
по такой логике и заборы не нужны, их же перелезут кому припрёт
> позволяющая любому непривилегированному пользователю выполнить код с правами rootТы должен был бороться со злом, а не примкнуть к нему!.. (c)
Впрочем ничего нового)
В ляликсе уже сколько утилит и разных способов, а вот и ныне тем.
Есть примеры, где через подобные "уязвимости" своровали данные/навредили инфраструктуре.Не в сферическом вакууме это все не работает. Т.е. в реальном мире никто не будет локально прописывать ребусы, чтобы завладеть своим же серваком))
Это все уже давно устарело.. а данные копятся уже в облачных хранилищах, где манипуляции с вашими данными никак не зависят. есть ли какой то эксплоит или нет.
Т.е. те же облачные сервисы это удаленная ОС. А на локальный корень Вашего ПК им абсолютно равнодушно.
Ну вот есть такой kernel.org, ага. Там с годик назад выяснилось, что вот на Самом Главном Сервере через интерактивный ssh тусовалось 100500 дiдов и у пары из них вот ключики того-с. Утекали-с.
если ключи были не беспарольные и пароль не похож на словарный, то можно плюнуть.
> если ключи были не беспарольные и пароль не похож на словарный, то
> можно плюнуть.https://www.opennet.me/opennews/art.shtml?num=61186
"И так сойдет!"(С)
/etc/os-release:VERSION="24.04.2 LTS (Noble Numbat)"
sudo 1.9.15p5-3ubuntu5.24.04.1 amd64...
sudo: you are not permitted to use the -R option with woot
...сп#здели
за тебя просто Убунту все уже сделала.
Зоркий глаз и не заметил, что у него автоапдейт включен и новый пакет уже сам приехал.
Так я не понял, если пользователя упомянуть в sudoers то он и так получает root. А без упоминания sudo, из под этого пользователя, запустить не получится?
Нет. Он может быть упомянут в sudoers для выполнения одной единственной команды, а не для root доступа.
Читайте внимательнее. Это другая уязвимость - заодно исправленная.
А в sudo-rs есть такая уязвимость?
Растовые утилиты никому не интересны.
Там много других - ещё не выявленных. Сложнее компилятор - больше непредсказуемости. Ассемблерный листинг программ, написанных на Rust читать, анализировать, проверять намного сложнее. чем GCC.
Вдобавок, могу привести такой тезис: Зачем Вы показываете мне этот открытый код, если за компилятор стоит непонятный backend?
а как там run0 поживает?
Приближается к run1. А дальше синхронизация с нумерацией версий systemd.
Уже давно везде внедрён. Правда создавали её в первую очередь для systemd-run, а не для прямого использования
Ты что-то путаешь, потому что run0 это как раз обёртка над systemd-run с интеграцией polkit для поднятия привилегий, и она предназначена для людей (она даже tty в красный перекрашивает)
Гремучая смесь.
первую же мою попытку применения run0 dnf на последнем 10 клоне красношляпы пресёк selunux.
> первую же мою попытку применения run0 dnf на последнем 10 клоне красношляпы
> пресёк selunux.Значит политики неправильные. Для run0 даже правила не нужны особо сложные, потому что это не suid, и работает он намного проще с точки зрения безопасности
Конечно, проще. Что же может быть проще, чем правило "разреши этому бинарнику ВСЁ".
> Конечно, проще. Что же может быть проще, чем правило "разреши этому бинарнику
> ВСЁ".run0 по dbus идёт в systemd и форвардит запросы polkit
Он не занимается повышением привилегий, он через systemd создаёт отдельный pty в отдельном сервисе и форвардит его тебе
> Он не занимается повышением привилегийА я где-то утверждал обратное?
> форвардит запросы polkit
У которого в правилах разрешить можно только всё или ничего. Потому что механизм передачи параметров запуска программы от systemd к polkit нормально не продуман. И любой неправильно понятый systemd-ой параметр - потенциальная брешь. Да что там, даже имя программы-сервиса зависит от ревизии луны.
> systemd создаёт отдельный pty в отдельном сервисе
Угу, генерирует что-то налету. Я бы даже рад сам написать сервис и ограничить, но xpен угадаешь его смямлингенерированное имя.
Вот, кстати, тут все сокрушаются, "какой sudo сложный комбайн". А в связке systemd + dbus + polkit никого сложность не смущает? Напомнить как убийство polkit-agent-а приводило к полному рут-доступу (через polkitd) любого приложения с включенным gvfs-admin? А сколько ещё сюрпризов таит его js-движок для разбора правил, ммм..
> У которого в правилах разрешить можно только всё или ничего. Потому что механизм передачи параметров запуска программы от systemd к polkit нормально не продуман. И любой неправильно понятый systemd-ой параметр - потенциальная брешь. Да что там, даже имя программы-сервиса зависит от ревизии луны.Если речь про white-list команд которые можно дёргать, то sudo тут не лучше. Сложно сказать что такая-то утилита точно не дырявая, и её можно запускать через sudo не боясь что юзер вдруг даст ей ввод, который утилита неправильно распарсит и исполнит что угодно
В любом случае нужно прописывать какие-то ограничения для работы запущенной программы, и systemd/PAM с этим справляются лучше. Ну собственно и используя PAM можно настроить о чём тебя polkit спросит, как программу изолирует, и какие права сбросит.> Вот, кстати, тут все сокрушаются, "какой sudo сложный комбайн". А в связке
> systemd + dbus + polkit никого сложность не смущает?Баги в этой связке намного проще найти и исправить чем в программе которая запускается от рута (suid), парсит неопределённое количество конфигов своего собственного кривоватого формата, затем грузит непонятные библиотеки из системы (NSS, PAM опять же и прочее), затем проверяет все доступы, и если все доступы совпали передаёт управление юзеру
Поверхность атаки как раз таки ниже, потому что та связка изначально имеет ко всему доступы и загружает всё что нужно при старте системы
Более того, если используется демон systemd-userdb, то все проверки прав доступа выполняются в отдельном процессе, и даже если вдруг юзер чот и сможет проэксплуатировать - он это проэксплуатирует в удалённом процессе без прав, и нужно будет ещё что-то поднимать от основного юзера чтобы та уязвимость тебе чего-то дала> Напомнить как
> убийство polkit-agent-а приводило к полному рут-доступу (через polkitd) любого приложения
> с включенным gvfs-admin?Честно говоря звучит как неправильные политики/баг в gvfs, можно ссылку?
> Если речь про white-list команд которые можно дёргать, то sudo тут не лучше.Намного лучше! В sudoers можно /даже/ аргументы командной строки регулярками выбирать. А в polkit я могу проверить группу, пользователя, "unit" и "verb" (если заранее завернул в сервис). И для такой (бесполезной) ерунды зачем-то нужно писать код на JavaScript. Но с тьюринг-полным языком почему-то нельзя выразить однострочник вида "installer ALL = (root) NOPASSWD: /usr/bin/pacman ^-S(|u)(| --) -$" или "Cmnd_Alias PACMAN_REM = /usr/bin/pacman ^-R[cnsu]*( --|)( -|( [a-z0-9][[:graph:]]*)+)$".
Там где sudo справляется лишь за счёт "POSIX extended regular expressions", комбайн со встроенным браузером^W интерпретатором команд столкнулся с непреодолимым препятствием на ровном месте.> Сложно сказать что такая-то утилита точно не дырявая
Обе "дырявые". Перефразируя Страуструпа: "Есть два типа программ - те, в которых находят уязвимости, и те, которыми никто не пользуется."
Но у sudo дыры локализованы в её коде, и она часто переиспользует обкатанные, стандартные и традиционные, функции/механизмы системы.
А у polkit-а дыры размазаны тонким слоем по овер-велосипедам без пробега: systemd, dbus и самому polkit. И ещё куча дыр в тех местах, где они примотаны друг к другу изолентой или приклеены жевачкой.> Ну собственно и используя PAM
Так для того и sudoers, чтобы не писать (и конпелировать) правила на Си, там где можно обойтись простыми декларациями и POSIX ExRegex.
OffTopic. Зато для настройки сети, которую в большинстве случаев можно парой команд одной программы (ip {link,addr,route} ...) в systemd тащат чудовищный systemd-networkd. Нуда-нуда..> Баги в этой связке намного проще найти и исправить чем в программе
> которая запускается от рута (suid), парсит неопределённое количество конфигов своего собственного
> кривоватого формата, затем грузит непонятные библиотеки из системы (NSS, PAM опять
> же и прочее), затем проверяет все доступы, и если все доступы
> совпали передаёт управление юзеруDAC-атрибуты файла (SUID bit) на сложность исправления багов не влияют. А вот искать их легче, когда вместо десяти процессов с асинхронным многопротокольным IPC-взаимодействием, требующих отдельного инструмента отладки для каждого протокола (типа dbus-inspector), чтобы распутать всю цепочку, у нас есть один - последовательно исполняемый, с общим адресным пространством, предсказуемый.
SUID-программу можно обезвредить, просто выкинув из песочницы (например, с веб-браузером). Можно такжу смонтировать / с nosuid, чтобы избежать случайных прилётов из пакетов (хотя за этим сопроводители обычно внимательно, tool-assisted, следят). А через sudoers рут-доступ раздаётся централизованно, админом, без сюрпризов и, главное, дозированно.
А вот polkit-правила каждая программа носит с собой (в пакете), сама себе всё (ВСЁ) щедро разрешает. Причём эти программы могут содержать кучу зарытых в коде сюрпризов (см. gvfs-admin ниже или недавний udisks - https://www.opennet.me/opennews/art.shtml?num=63424). И сработают эти сюрпризы в самом неожиданном месте. Причем, игнорируя защиту namespace-песочниц (systemd.service, bubblewrap, flatpak, firejail и т.п.).
Да и в самом Polkit-е полно ошибок (не меньше чем в sudo, который pwnkit-разрабы любят попрекать). Вот, к примеру, исправленные:
https://www.opennet.me/opennews/art.shtml?num=56580
https://www.opennet.me/opennews/art.shtml?num=55269
https://www.opennet.me/opennews/art.shtml?num=52340Про конфиги. В sudoers весьма простые правила, выразимые простой EBNF-грамматикой (man sudoers.5), плюс, egrep-подобные регулярки. Опций много - это да. Но программы за тем и пишутся, чтобы решать самые различные проблемы, а не предлагать одно топорное решение на все случаи жизни (как принято у редхат-поклонников, а чуть что: "ну заверните это в Bash, в Python, в Javascript, в утку, в зайца, а потом всё вызовите из самописной программы на Си"). И пользоваться сразу всеми никто не заставляет.
А что polkit? Парсит XML (уж не через glib2 => libxml2, а?) и интерпретирует JavaScript-код (duktape). То что дохтур прописал для утилиты, раздающей рут-доступ в системе. Мало комбайнов богу комбайнов, чтобы, всего-то, распарсить конфиги.А про то, кто-что грузит, ну я даже не знаю. Почему, использующиеся повсеместно со времен неолита, разделяемые библиотеки (NSS) и механизмы аутентификации (PAM), вдруг, стали "непонятными"?
А рожденные в Роковой горе, сумрачным гением Редхаты, для злодейских планов по приватизации мира, постоянно висящие в процессах, daemonы systemd-*++ + dbus + polkitd + libpolkit-agent + libpolkit-gobject + some-strange-pkcheck-impl-auth-plugin, вдруг, стали такими родными и понятными? И чёрт его знает, какие зависимости они там ещё загружают. Половина тех библиотек сопровождается одинокими стареющими энтузиастами, обходящими автобусы с неправильной стороны, а вторая - написана скучающими корпоративными рабами, на коленке, чтобы быстренько заткнуть функциональное отверстие в Убер-Всем-продуктам-Продукте, и с тех давних пор в этот код никто, кроме злоумышленника, ни разу не смотрел. И я сейчас даже не выдумываю. История изменений открыта. Запаситесь корвалолчиком и изучайте эти древние курганы.> Поверхность атаки как раз таки ниже, потому что та связка изначально имеет
> ко всему доступы и загружает всё что нужно при старте системыИ раздаёт их любому, кто просит, а не кому требует админ.
> он это проэксплуатирует в удалённом процессе без прав, и
> нужно будет ещё что-то поднимать от основного юзера чтобы та уязвимость
> тебе чего-то далаА больше ничего и не нужно. Там каждая вторая уязвимость (gvfs-admin, udisks, machined) про запись в файл с root:root из-под user:user. Достаточно, чтобы получить всё остальное.
> Честно говоря звучит как неправильные политики/баг в gvfs, можно ссылку?
https://www.opennet.me/opennews/art.shtml?num=49871
https://gitlab.gnome.org/GNOME/gvfs/-/commit/d8d0c8c40049cfd...
Баг в gvfs-admin, да. Он игнорирует результат аутентификации. А правило org.gtk.vfs.file-operations.rules, щедро раздающее рут-доcтуп таким "хитрецам", выглядит совершенно безобидно. Комар носа не подточит. 10 лет никто не замечал.
> Угу, генерирует что-то налету. Я бы даже рад сам написать сервис и ограничить, но xpен угадаешь его смямлингенерированное имя.Btw, если тебе надо systemd-run указать своё желаемое имя, то там есть --unit аргумент)
> Btw, если тебе надо systemd-run указать своё желаемое имя, то там есть --unit аргумент)И что оно при вызове "чего угодно" с этим аргументом аутентификацию по указанному имени пройдёт и даже рута не спросит? Определенно: FEATURE, NOT A BUG.
Ты прав
Я почему-то был абсолютно уверен, что это часть systemd-run
Жесть, детская уязвимость которую может эксплойтнуть любой школьник и поставляется со всеми серверами мира. Расчехлили еще один бэкдор красношляпы.
Это с какими "всеми" ? В дебиане такого нет ! Да и во фряхе тожеж.
Супергерой,спасающий мир от свежего софта, опять успел вовремя?(в целом, конечно, для sudo НУЖЕН такой супергерой)
Во фре была похожая уязвимость лет 10 назад в ftpd.
Да уж знатный фейл. Запускать что-то с привилегиями root не из соответствующих каталогов.
Где были эти "миллионы глаз"?
Где были российские линуксы с ФСТЕК сертификацией
Не первая ошибка, только... никто от sudo не отказался после прошлой ошибки. Как-то не удобно. До сих пор есть множество сценариев и рекомендаций использовать sudo вместо su. И я пока особо не видел где-то сценариев для настройки/установки чего-либо где бы sudo заменили на run0 или sudo-rs. Впрочем алиас никогда не поздно сделать.
> Не первая ошибка, только... никто от sudo не отказался после прошлой ошибки.Ну я начал планомерно выпиливать после sudoedit.
К сожалению, на мультиюзерных хостах от него не получится отказаться. А площадь атаки уменьшить стоит. Поэтому вероятно таки придется везде ставить самодельный пакет с минимумом включенных при сборке вреднофич.
> Впрочем алиас никогда не поздно сделать.
неработающий. Потому что обе под[д]елки несовместимы ни по синтаксису, ни по возможностям.
> Ну я начал планомерно выпиливать после sudoedit.Правильно, даёшь паникёрство! С проверенных программ с исправленными уязвимостями все срочно переходим на неуловимых джо с неисправленными/ненайденными уязвимостями.
А для редактирования конфигов ничего лучше Visual Studio из-под рута ещё не придумали.
> С проверенных программ с исправленными уязвимостямичо? Вот тебе свежайшая уязвимость - от проверенно безнадежно дырявой программы.
А там где у меня (после очередного напоминания что она дырява) ее не осталось - нет никакой уязвимости. Сечешь разницу?
Принцип - зачем использовать дополнительно потенциально уязвимое ПО, если можно обойтись без него.
> я пока особо не видел где-то сценариев для настройки/установки чего-либо где бы sudo заменили на run0 или sudo-rs.Я сейчас раскрою тебе секрет. Только ты никому не говори. Если ты сделаешь su, перед началом сценария, а потом из всех команд сценария удалишь sudo, то всё просто магически сработает.
>> Я сейчас раскрою тебе секрет. Только ты никому не говори. Если ты сделаешь su, перед началом сценария, а потом из всех команд сценария удалишь sudo, то всё просто магически сработает.Читать научись для начала.
Да всем по...современный ИТ (любой, на любой ОС, хоть open-source, хоть корпоративный) это дырка на дырке. Нет времени думать, нужно делать фичи.Однако есть и нормальные альтернативы - https://github.com/LeChatP/RootAsRole
RootAsRole. Ой, на Rust 😱😱😱
Всего лишь следствие капитализма и корпоративизации отрасли. Изначально айти была академической, но слишком молодой, чтобы выработать лучшие практики. Сейчас же лучшие практики есть, но в угоду kpi и прочей дряни, что на качество кода забивают.
Иными словами, принцип неопределенности: либо медленно и качественно, либо быстро и плохо.
> Сейчас же лучшие практики естьМожно парочку ссылок того, что вы считаете лучшими практиками? А то я столько споров видел, когда обе стороны считали, что именно их практика - лучшая. А по факту просто способ сидеть и 90% времени тратить на рефакторинг, по сути сводящийся к "мне так читабельнее, а кто против - неправ".
Это где-то нет стандарта кодирования? В котором все и прописывается, а кто не соответствует - депремируется и правит код...
В смысле "где-то нет"? Речь же шла не о случайных стандартах кодирования, которые, да, есть везде. И везде свои. Речь шла о "лучших практиках". Лучшие - они для всех одинаковые. И вероятно, хотя бы с минимальной аргументацией "лучшести".
> Однако есть и нормальные альтернативы - https://github.com/LeChatP/RootAsRoleЧто-то 17 мая там коммиты подозрительно закончились. Хотя до этого активненько шло.
Автор закончил [s]школу[/s] университет.
да, я тоже хотел написать - экзамены же ж в школах.
Если б университет - наоборот, было бы экстенсивное развитие, чуваку ж надо на собеседованиях показать свой шитхаб.Ну ладно, может поступит куда и сделает из него курсовик.
так и чего не написал, раз экзамены?
This project was initiated by IRIT and sponsored by both IRIT and Airbus PROTECT through an industrial PhD during 2022 and 2025IRIT Computer Science Research Institute of Toulouse
Финансирование/грант/PhD закончился.
Но насколько я помню там всё сделано (3.0.0 версия).
А, от оно чего. Про phd-то я и не подумал.> Но насколько я помню там всё сделано (3.0.0 версия).
вот это я понимаю, как стонхендж - на тысячелетия.
Не то что этот Тодд, каждые пол-года что-то доделывает.(это вот все потому что он кандидатскую не написал!)
На первое время можно бинарник sudo удалить/спрятать.
в нормальных дистрах уже обнова приехала
не приехала
Тебе же говорят, в нормальных дистрибутивахhttps://mirror.yandex.ru/mirrors/manjaro/stable/core/x86_64/...
$ cat /etc/hosts | grep yandex | wc -l
32
> любому непривилегированному пользователю выполнить код с правами root,
> даже если пользователь не упомянут в конфигурации sudoersНу спасибо убунта, при том это уже не в первый раз. То им sudoedit какой-то спичил - и тоже рута всем раздавал, теперь это.
Элегантная дыра
sudo: invalid option -- 'R'по-видимому это ненужное-ненужно добавлено только в распоследних убунтах. И вероятно надо его выпилить отовсюду вместе с -h
А знаете, в чём причина вот таких косяков?
А причина - нарушение "Unix way", когда разрабатываются простые утилиты для простых задач. Изначально sudo разрабатывалась как простая утилита, но потом под тяжестью фич стала совершенно непростой
Это цена эволюции ... Вспомни динозавров.
> Изначально sudo разрабатывалась как простая утилита,нет. она изначально была очень неудачной и тяпляперами написанной. Ну им можно простить, в 80е все так делали.
А с тех пор как ей в одно жало стал распоряжаться тяпляпер Тодд (кстати, угадайте где еще он подвизается) там вообще все стало плохо (т.е. с девяностых аж - но я видел код до того, тоже был не айс). Плагины какие-то, какой-то нахрен ненужный sudoedit и так далее. Походу ему очень нужны бабки, а за поддержку несломанного не капает.А теперь вон и вовсе - добавил новую фичу с детской ошибкой. Сброс привиллегий должен всегда быть ПЕРВОЙ же операцией после chroot - по-моему это должны вбивать в голову еще на подготовительном факультете или в кружке "программирование хеловротов под юникс", с демонстрацией сотни примеров как это бывает, когда сделали неправильно (там и sshd отметился в свое время и еще дофига подобного).
>Сброс привиллегий должен всегда быть ПЕРВОЙ же операцией после chroot - по-моему это должны вбивать в голову еще на подготовительном факультете или в кружке "программирование хеловротов под юникс"Никто никому ничего не должен. Единственная причина, почему люди до сих пор не перешли на условный idris/ats - возможность писать абсолютно любой говнокод и не переживать об этом.
Да, sudo доверия нет, но от openbsd'шников я 100% ожидаю таких же проблем, так что doas - не замена. Не понятно чем теперь пользоваться.
> Да, sudo доверия нет, но от openbsd'шников я 100% ожидаю таких же
> проблем, так что doas - не замена. Не понятно чем теперь
> пользоваться.Ну они вряд ли затолкают в doas поддержку chroot с nsswitch.
кто бы мог им помешать? Ты в курсе где харчуется автор sudo?
(nsswitch, если что, обрабатывает libc. Просто она не рассчитана на запуск от рута в untrusted окружении - понадобился sudo чтобы этого добиться.)
Да я бы вообще ничему не доверял даже памяти, см когнитивные искажения. Там только про память больше 20 штук (где 20 число с потолка).
Глазам тоже не стоит доверять. Читал, что глаз видит и передает в мозг только часть картинки. Остальное (периферию) "додумывает" мозг. Вспоминается фильм "Вечное сияние чистого разума", где фирма стирала память о человеке, через воздействие на узлы, отвечающие за память об этом человек. Делала это фирма, когда человек спал. Таким образом, через воздействие на мозг во сне возможно искажение картинки, которую видит человек. )
> файл /etc/nsswitch.conf загружался в контексте нового корневого каталога, а не системного каталогаГы... какая прелесть!
А зачем пользователю нужны привилегии рута?Установку, настройку, обновление - все можно выполнить в рутовой консоли.
Ну у меня, например, стоит запуск openvpn от моего пользователя через sudo без пароля. То есть я хочу, чтобы у меня спрашивало пароль рута для установки/обновления софта, но НЕ для запуска впн. Но за 20 лет похожих кейсов было штук 5 максимум.
а зачем тебе openvpn от рута? Это же не дырявый положительно globalprotect.
От непривилегированного пользователя не запускалось. Вроде. Точно не скажу, настраивал последний раз уже лет пять назад.
А оно с маршрутами без рута как то не так работает :-/
> Установку, настройку, обновление - все можно выполнить в рутовой консоли.А зачем пользователю рутовая консоль? Установку, настройку, обновление - всё можно выполнить в консоли пользователя. Почему это удобнее - потому что не нужно дополнительно настраивать окружение рута (от шелла до .vimrc), и история не размазывается по пользователю и руту.
> А зачем пользователю нужны привилегии рута?
> Установку, настройку, обновление - все можно выполнить в рутовой консоли.Ну вот понимаешь - этих самых "пользователей", или, вернее, "администраторов" бывает больше одного. Есть вот "отдел инфраструктуры", который отвечает за VM+ОС, есть "отдел поддержки ИС" - который ведает собственно тем полезным, что в этой ИС вертится, у ИС есть СУБД, за которую отвечают вот вообще DBA - а где-то рядом гордо реет ИБ, которым "А можно всех посмотреть?!" ("Зойчем?!" они сами не знают, но ТАК ПОЛОЖЕНО).
И вот у всех этих нет, даже не товарищей, а отделов - есть определенная текучка кадров - и вот как ты себе представляешь замену пароля root'а при увольнении Уаси из "поддержки производственных систем" и как будешь отвечать на вопросы "А что Уася делал на этих серверах в последние две недели?" от г-д из ИБ (Доступ у них, напомню, есть - но лапки, лапки...) - я лично не знаю, но надеюсь HR тебе их не задаст.
"Коллеги, а как зайти на сервер-нахерн-был-ненужен.но.вот? - Там старый рутовый пароль! - Я пробовал, не пускает! - Не тот старый, а тот который до увольнения Васи в позапрошлом году! - А я тогда ж еще не работал! - Ща, найду пришлю. - А, ооок."И разумеется все эти пароли и ключи кучкой под ковриком (под десятком ковриков, на каждого по два), потому что запомнить и один такой невозможно, а с позапрошлого года их накопилось с десяток. И при аварии их надо вбивать быстро, пока она не эскалировалась до начальства.
И да, иногда еще хочется дать возможность техподдержке что-то посмотреть и может даже перезапустить, но не rm -rf / набрать.
1. админ пароля root знать не должен, ssh: заходит по ключу, а не паролю, sudo-ится без пароля NOPASSWD2. с уходом админа -- вычищается учетка или его ключ
3. пароль root-а меняется Ansible-ом или puppet-ом на всех хостах переодически или по необходимости.
> 1. админ пароля root знать не должен, ssh: заходит по ключу, а
> не паролю, sudo-ится без пароля NOPASSWDНуэээ да - не должен. Его как сгенерякали, так вот распечатали на бумажечке, сунули ту бумажечку в конвертик и отдали в ИБэ с наказом "не открывать до страшного суда или следующего аудита системы" - в зависимости от того, что произойдет раньше.
И нет, за NOPASSWD ты с этими самыми Бэ - не договоришься (В данном случае даже правильно).> 2. с уходом админа -- вычищается учетка или его ключ
Ненене. Это вот вы сами. Обычно машина - в домене, открытый ключ вот в расширенных аттрибутах схемы, а на машине есть одно большое НИЧЕГО. Событие увольнения из кадровой системы триггерит отключение УЗ а в AD и, собственно, усё.
В случае когда "совсем-все-пропало-шеф! Сети-нет-AD-нет-налоговая-у-дверей!" Вместе с бланком объяснительной из конвертика достается der parol root'а - и все заверте...> 3. пароль root-а меняется Ansible-ом или puppet-ом на всех хостах переодически или
> по необходимости.Не-не. Тут штука в том, что он на всех хостах вот прям совсем-совсем разный и его примерно "нигде" (Кроме как в конверте, в роли которого может оказаться и какой-нибудь bitwarden ИБ) нет. Варианты с регулярной заменой в рамках "регламента эксплуатации" я видел - но больше в том самом "регламенте" - проще контролить события входа в систему от соответствующего пользователя на уровне SIEM чем упражняться в этом вот кувыркании на регулярной основе.
> Ненене. Это вот вы сами. Обычно машина - в доменесеть отвалилась после обновления фирмварей - исправить ничего нельзя, ведь зайти на хост теперь невозможно.
Про валяющиеся по всей fs keytab'ы при таком подходе - уже и не будем.
> 3. пароль root-а меняется Ansible-ом или puppet-ом на всех хостах переодически или
> по необходимости.вот это обязательно, да. А сам файлик который его меняет вместе со всеми паролями - не забудьте еще закомитить и запушить в гитляп и гитшляп, для надежности. Все так делают!
> Вместе с бланком объяснительной из конвертика достается der parol root'а
за это время не то что дверь вынесут, а и половину срока отсидишь
В общем, так себе концепция. Обычно этот рут нужен когда что-то серьезно поломалось, и тут надеяться на внешние авторизации - ну такое себе.
>> Ненене. Это вот вы сами. Обычно машина - в домене
> сеть отвалилась после обновления фирмварей - исправить ничего нельзя, ведь зайти на
> хост теперь невозможно."В случае когда "совсем-все-пропало-шеф! Сети-нет-AD-нет-налоговая-у-дверей!" Вместе с бланком объяснительной из конвертика достается der parol root'а - и все заверте..."(Ц)
> Про валяющиеся по всей fs keytab'ы при таком подходе - уже и
> не будем.Ээээ... зачем кейтаб? Какой кейтаб? Неэээ, керберос мы не будем - проблемное оно в линуксовом изводе примерно со всех сторон.
AuthorizedKeysCommand, который этот самый key из LDAP'а налету дергает вполне себе работает - даже можно сказать "in какой-никакой scale">> 3. пароль root-а меняется Ansible-ом или puppet-ом на всех хостах переодически или
>> по необходимости.
> вот это обязательно, да. А сам файлик который его меняет вместе со
> всеми паролями - не забудьте еще закомитить и запушить в гитляп
> и гитшляп, для надежности. Все так делают!Некоторые даже джва раза, ага.
>> Вместе с бланком объяснительной из конвертика достается der parol root'а
> за это время не то что дверь вынесут, а и половину срока
> отсидишьТут главное "объяснительная", отсутствие у тебя регулярного доступа к этому der parol - ну и процедура обязательной смены после каждого доступа к. А будет это у тебя пароль на бумажке в конвертике у ИБ, аппаратный ключик в сейфе или вот вовсе какой vault - дело второе.
> В общем, так себе концепция. Обычно этот рут нужен когда что-то серьезно
> поломалось, и тут надеяться на внешние авторизации - ну такое себе.Ну вот как раз в случае "аварии" когда нужен именно "root", а не его права - никаких "внешних"-то и нет.
> все можно выполнить в рутовой консоли.И получить `rm -rf /` из-за ошибки в шелл-комплишн. Или скрипте/плагине текстового редактора. Или даже в собственноручно набранной команде (нулл-глоб или забытые кавычки вокруг параметра с пробелом). И т.д. и т.п.
Опять в однопользовательской локалхостной системе что-то ломается когда хостов или пользователей нужно больше одного. Новость-то в чём?
Хотя делов то, поставил систему и удалил sudo, а ещё под root'ом сделать chmod u-s /bin/su. Права root пользователю ни к чему, а рутовские дела делаются больше всего при установке, больше они не нужны.
root на каждый чих требуется в линуксах.
Технологией File CAP можно обойтись. Аккуратным DAC.Это современному сыстемды надо root.
А лет 15 назад ещё были лимоны GNU/Linux с изолированным init, который сам мониторитл пользовательские события и выключал перегружал комп.
Влажную уборку комнаты проводить надо регулярно.
А если серьёзно, то чем вы там занимаетесь в Линуксе, что надо регулярно под root'ом заходить?
У меня это несколько дней за целый год: обновления. Ну и когда только поставил, то /etc/fstab и всякие подобные конфиги под root'ом правятся, проги нужные ставятся и всё.
> Влажную уборку комнаты проводить надо регулярно.
> А если серьёзно, то чем вы там занимаетесь в Линуксе, что надо
> регулярно под root'ом заходить?
> У меня это несколько дней за целый год: обновления. Ну и когда
> только поставил, то /etc/fstab и всякие подобные конфиги под root'ом правятся,
> проги нужные ставятся и всё.Ну вообще конечно "да" - видел я место, где "интерактивный вход пользователя в систему" являлся "значительным нарушением информационной безопасности" и требовал вот прям отдельного расследования с заполнением соответствующих актов в процессе - но работать ТАК умеют\могут не только лишь все.
Причём здесь место работы? У меня именно на домашнем компе sudo удалён лично мною, а на /bin/su sticky bit поставлен в ноль (чтобы нельзя было из под пользователя выполнить su -).
На работе же если пользователю позволяется лезть в админку, то лучше по достижении минимально необходимого для лёгкого поиска работы опыта сразу же увольняться и искать нормальную работу.
> Причём здесь место работы? У меня именно на домашнем компе sudo удалён
> лично мною, а на /bin/su sticky bit поставлен в ноль (чтобы
> нельзя было из под пользователя выполнить su -).Да при том, что на твой комп всем пофиг от слова "совсем". Хоть с перфокарт управляй - никто слова дурного не скажет. А вот при попытке распространить сию практику могут обнаружить нюансики, ага.
> На работе же если пользователю позволяется лезть в админку, то лучше по
> достижении минимально необходимого для лёгкого поиска работы опыта сразу же увольняться
> и искать нормальную работу.Ну, администраторы - всего лишь категория пользователей с расширенными правами, не?
и как же снятие sticky bit добавляет вам безопасности ? почитали бы маны прежде чем чушь писать....
Легко и непринужденно.
Ну как минимум sudo emerge ... - систему обновляю, sudo blkid - посмотреть какие диски по каким именам\уидам, sudo cp ... скопировать свежесобранное ядро на boot раздел или ебилд скопировать для редактирования в /usr/local/portage. Это то что нужно было за последние 2 недели. Иногда sudo -E gparted - разделы поглядеть на флешке\диске. Ну и sudo systemctl restart servicename.service периодически.
Вот для чего стоит попробовать создать нейросеть, так для выявления таких ошибок.
Правда я уверен уже создали и уже используют.
Не осилят. Они обработку ошибок одной функции не могут написать так, что бы придраться не к чему было.Ну не любят программисты ошибки обрабатывать. И делают это спустя рукава - вот нейронки и не могут это сделать нормально.
А я напоминаю, что эта уязвимость локальная, то есть на уровне проникшего в хату соседа с молотком.
Дык если бы сосед ... а тут мимкрокодил
ну как бы если подтвердится (пока на моих системах не получалось) что это таки работает от юзера, отсутствующего нафиг в sudoers вообще - то любое rce от nobody автоматически перерастает в катастрофу общесерверного масштаба.так себе в общем новость.
"У меня все работает (Ц)"
На бубунте 24.04 скрипт из новости без изменений отрабатывает на 5+.Там в скрипте есть одна "ненужная" строка, без нее тоже работает на бубунте.
Есть подозрение, что на других системах, возможно, надо еще одну строчку добавить к той, лишней, что бы работал не упомянутый в sudoers пользователь. Но я не рыл так сильно.П.С. По моим наблюдениям, полностью "боевые" эксплоиты на паблик не выкладывают, PoCи всегда имеют неточности, надо допиливать напильником.
Как же замечательно на бсд-подобных системах с doas. Продолжайте использовать софт, в котором легаси идет уже с 80-ых годов, удачи.
На bsd системах только используется sudo. И на openbsd, да-да. Потому что к openbsd'шным поделкам доверия не больше чем к этому вот решету.
лучше использовать дырявый эксплойт от редхата, замаскированный под утилиту для получения доступа к пользователям?
Так в дефолтной настройке всё хорошо? Проблема только у нетакусиков??
>Уязвимость проявляется в конфигурации по умолчанию и подтверждена в выпусках sudo с 1.9.14 по 1.9.17 (потенциально затрагивает все версии, начиная с 1.8.33).
Вообще считаю, что sudo в базовой системе это дичь какая-то, продвинутая убунтоидами (видите ли, сложно запомнить пароль рута). Да, она имеет свои применения (разрешить пользователям отдельные команды от рута без пароля), но в конфигурации по умолчанию полностью заменяется обычным su с паролем рута. И никакой doas не нужен.
>но в конфигурации по умолчанию полностью заменяется обычным su с паролем рутаТолько в однопользовательских системах.
Добавить кого-то в sudoers - отдать ему рута. Ничто не мешает сделать дальше что угодно (при конфигурации по умолчанию). Можно просто дать пароль рута и всё.Для более разумного использования всё равно надо настраивать, тогда же sudo можно и поставить. Нафига оно в базе?
>Добавить кого-то в sudoers - отдать ему рутаВот чем хороши старые прожжёные эникейщики - 0% знаний, 100% уверенности. Нет это далеко не значит, как минимум список команд можно настраивать. Правда там будет целая проблема с аргументами, но да ладно.
>Можно просто дать пароль рута и всё.Пароль у рута один, пользователей, с повышенными правами может быть несколько. С sudo можно отозвать у одного пользователя за раз полономочия, с su - полномочия отзываются сразу у всех, так как рутовый пароль общий.
>Нафига оно в базе?Предполагается, что софт нормально написан, а не сетка рабица.
и тут мы вспоминает selinux с его MAC
Ну сорри если у тебя окно контекста составляет одно предложение. Я дальше явно написал, что это дело надо настраивать. В линуксе вообще много полезных вещей, которые надо настраивать. Но мы же не тащим всё в базовую систему? Кому надо, тот поставит и настроит.
> Ну сорри если у тебя окно контекста составляет одно предложение. Я дальше
> явно написал, что это дело надо настраивать. В линуксе вообще много
> полезных вещей, которые надо настраивать. Но мы же не тащим всё
> в базовую систему? Кому надо, тот поставит и настроит.Кому не надо - удалит, ага?
>Я дальше явно написал, что это дело надо настраивать.Что надо настраивать? Как только вы добавляете нового пользователя в группу sudo, всё настройка уже завершена, у двух пользователей уже два разных пароля.
> Пароль у рута один, пользователей, с повышенными правами может быть несколько. С sudo можно отозвать у одного пользователя за раз полономочия, с su - полномочия отзываются сразу у всех, так как рутовый пароль общий.И как часто такой функционал востребован на какой-нибудь убунточке? Как ты полагаешь, каков процент от общего числа инсталляций использует эту функциональность? Хотя бы 1% наберётся?
И из-за этого одного процента, 99% получают дефолтом переусложнённый, дырявый и ненужный им кусок софта.
Это антипаттерн для создания систем. Это как C, который делает 100% кода unsafe ради того 1% случаев, когда это действительно надо. Это мышление дидов из 70-х годов, от которого девелоперы unix до сих пор не могут излечиться.
>> Пароль у рута один, пользователей, с повышенными правами может быть несколько. С sudo можно отозвать у одного пользователя за раз полономочия, с su - полномочия отзываются сразу у всех, так как рутовый пароль общий.
> И как часто такой функционал востребован на какой-нибудь убунточке? Как ты полагаешь,
> каков процент от общего числа инсталляций использует эту функциональность? Хотя бы
> 1% наберётся?
> И из-за этого одного процента, 99% получают дефолтом переусложнённый, дырявый и ненужный
> им кусок софта.
> Это антипаттерн для создания систем. Это как C, который делает 100% кода
> unsafe ради того 1% случаев, когда это действительно надо. Это мышление
> дидов из 70-х годов, от которого девелоперы unix до сих пор
> не могут излечиться.Ну, предполагаю, что примерно 100% корпоративных инсталляций, да? Т.е. примерно "все", кто платит ).
>Как ты полагаешь, каков процент от общего числа инсталляций использует эту функциональность? Хотя бы 1% наберётся?Мне не нужно, значит никому не нужно - типичная логика тыжпрограммиздов с опеннета.
> Мне не нужно, значит никому не нужно - типичная логика тыжпрограммиздов с опеннета.Может быть это и так. Но ты не ответил на вопрос: каков процент инсталляций действительно полагается на функционал sudo так, что его нетривиально заменить на su?
Нет ответа, значит ты сам не знаешь? И заменяешь аргументы по сути на ad hominem? Нушо я могу сказать. Малаца. Гораздо интеллектуальнее чем "типичная логика тыжпрограммиздов с опенета".
>Может быть это и так.Не может быть, а так и есть.
>каков процент инсталляций действительно полагается на функционал sudoСам по себе процент не будет говорить вообще ни о чём. Есть школьник, поставивший gnu/linux в виртуалку поиграть, которому что su, что sudo - всё равно. Имеет смысл равняться на данного школьника или нет? А если целая школа школьников? А на админа в фирме, обслуживающего десяток заказчиков?
>Нет ответа, значит ты сам не знаешь?Такой ответ можно дать только если в 100% случаях будет включена телеметрия.
>Нушо я могу сказать.Ну я, например, использую, сразу на нескольких системах. Что дальше?
> Только в однопользовательских системах.Причем в этих системах всем наплевать на увизгвимости в суду - их wsl и так в безопастности, на него ходит только васян с локалхоста под виндой (а он и так рут)
Как же неудачно. Только добавили закладку, а её сразу нашли. Ничего, в следующий раз спрячут получше.
че то ссыкотно, красношляпка на 4 дня обновление инфраструктуры делает и из за этого ни koji ни bodhi недоступны. Страшно очень страшно. Если бы мы знали что это такое. 4 июля как раз у супостатов главный праздник. Обожаю конспирологию.
В debian 12 уже исправлено. Вообще sudo не использую
trixie опять запаздывает от остальных.
run0 замечательная замена sudo и намного безопасней
ложь
Нет sudo - нет проблем. Не стесняюсь залогиниться рутом, если чего надо поадминить.
Ну, заадминь там себе Remmina если такой умный. Даже интересно как вы такие в никсах живёте без VNC...
а ещё нужен gcc ?
Собери на другом компе и создай arхивчик
Переходим на run0? В secureblue только его и используют.
Позволю себе процитировать croco:Если вы из-под аккаунта с одними полномочиями осуществляете доступ к аккаунту с другими полномочиями, то с точки зрения безопасности компрометация первого автоматически влечёт компрометацию второго. Из этого следует, что в сеансе работы нельзя повышать полномочия. Понижать можно, повышать нельзя. Вообще нельзя, понимаете? Никаким способом. В этом плане sudo вообще попадает под категорический запрет, а su остаётся в системе (без suid-бита) для понижения полномочий при возникновении такой потребности. "Вместо" них пользоваться нельзя ничем, ssh root@localhost тоже делать нельзя. Если нужны права root'а, в систему следует изначально зайти под root'ом. Если машина локальная, то переключиться на текстовую консоль и на ней зайти. Если удалённый доступ, то ssh root@remote-host, только следует при этом понимать, что тот аккаунт, под которым вы работаете на своей рабочей станции и из-под которого делаете этот вот ssh root@somewhere, охранять надо аки зеницу ока, уж во всяком случае браузеры под ним гонять нельзя совершенно точно.
А уж как надо беречь root на такой станции — ну, можно не объяснять. Почему-то часто встречаются админы, которые уверены, что аккаунты серверов надо беречь сильно-сильно, а аккаунты на личных машинах "типа фиг с ними". Ну так вот они заблуждаются: компрометация любого аккаунта означает компрометацию всего, к чему из-под него осуществляется доступ. Компрометация личного админского ноута означает компрометацию всех серверов, которые он админит.
у меня довольно обширный опыт коллективного администрирования серверов, и я на собственном опыте знаю, что sudo совершенно не нужен (плюс к тому -- см. выше, он ещё и недопустим, притом категорически). Разумеется, сообщать пароль рута нельзя никому, пароли вообще никогда никто и никому сообщать не должен. Вообще, понимаете? Никогда, никто, никому. Человек сам себе ставит пароли и никогда их никому не говорит. Но это и не нужно, и sudo тут ни при чём.
Просто у каждого админа должен быть СВОЙ аккаунт с нулевым uid'ом. В коллективах, где работал я, обычно мы такие аккаунты называли с префиксом r_. Например, мой личный root на всех машинах назывался r_croco.
Что касается логгинга выполняемых команд -- польза от него несравнима с зияющей дырой в безопасности, которая открывается из-за наличия sudo.
А ещё -- если использовать криптоключики и authorized_keys, то можно обойтись и одним аккаунтом рута.
>Позволю себе процитировать croco:Его надо не цитировать, а забыть как кошмар.
>Из этого следует, что в сеансе работы нельзя повышать полномочия.В юниксе исторически почти всё требует root. Потом, со времением это немножко поправили, но далеко не до конца. Тот же самый ping без root прав послать не получится, потом это замаскировали через suid, а потом и через capabilities. Но сам по себе root из этого абсолютно никуда не делся.
>Если нужны права root'а, в систему следует изначально зайти под root'ом. Если машина локальная, то переключиться на текстовую консоль и на ней зайти.Это, мягко говоря, крайне неудобно, если вы занимаетесь хоть чем-то сдожнее, чем вбиванием apt update. Как например, этот персонаж планирует писать какой-то сложный текст, типа конфига или копировать приватный ключ? Будет запускать мессенджер под рутом?
>уж во всяком случае браузеры под ним гонять нельзя совершенно точно.А почему это только браузеры?
>у меня довольно обширный опыт коллективного администрирования серверовТот самый случай, когда опыт данного персонажа работает во вред. https://www.linux.org.ru/forum/talks/17863538
>Столяров эти рассказы воплотил в жизнь, начав писать CMS мечты и допустив постыднейшую ошибку в безопасности. http://stolyarov.info/node/428
>Вывод: Столяров — это классический, можно сказать, эталонный системный администратор из 90-х. Человек, который отказался развиваться, отринул курсы повышения квалификации и навсегда остался в сладком возрасте 20 лет в рамках того давно ушедшего социума, его стереотипов и правил.
>Книги Столярова — это книги 90-х, хотя они написаны через четверть века, в конце 2010-х. Это памятник эпохи начала массовой компьютеризации в России. Это надо понимать при работе с ними. Читая работы Столярова, надо давать «поправку на ветер», и всё будет хорошо.----
>Просто у каждого админа должен быть СВОЙ аккаунт с нулевым uid'ом.Давайте каждому админу дадим абсолютно полный доступ сразу ко всей системе.
>А ещё -- если использовать криптоключики и authorized_keys, то можно обойтись и одним аккаунтом рута.Ещё один вредный совет. У пользователя может быть несколько ключей, как он собирается проверять, что удалены сразу все ключи? Тем более, что редактировать authorized_keys через текстовой редактор - явно не лучшая идея.
Советы данного автора - вырожденны уже на сам момент совета, даже по меркам 90-ых, не имеют практической ценности, зато являются бессмысленными ртиуалами, в перемешку с мазохизмом.
> В юниксе исторически почти всё требует root.как и в винде - админа. (просто там есть удобный и довольно надежный механизм проверить что ты админ, и у тебя не увели еще сессию, а не этовотвсьо)
Потому что на самом деле этот рут - подтверждение того что тебе на самом деле можно это делать (трогать устройства, занимать привиллегированные порты и т д), а другого у нас нет.
Т.е. либо тебе доверили пароль, эквивалентный рутовому, либо процессу с которым ты работаешь доверили - запуском от имени кого-то кто такой пароль знает.
И страдать фигней совершенно незачем.
Мы не работаем постоянно от рута только затем чтоб оставались какие-то возможности контроля и логинга, и ненароком самому себе чего-нибудь не сломать. (был когда-то еще и софт ломавшийся при работе от рута, но сейчас такое 25 лет уже немодно)
Там где то и другое неважно, работай от рута, твоя wsl в безопастносте.> Советы данного автора - вырожденны уже на сам момент совета, даже по меркам 90-ых, не
> имеют практической ценности, зато являются бессмысленными ртиуалами, в перемешку с
> мазохизмом.+1
Не, ну если у вас количество админов равно количеству серверов, каждый из них "админ ВСЕГО", сколько-нибудь централизованного управления этим "всем" нет и не предвидится - то, наверное, можно и так. Но ЗАЧЕМ?!
для sudo уже нужно отдельную группу создавать, кому им можно пользоваться)
до некоторых линуксоидов вдруг стало доходить, что кое-как написанный софт толпой энтузиастов не становится безопасным просто потому, что его код открыт. А как же "опенсорс - защита от бэкдоров и багов, ведь их тут же увидят и исправят"? Это что, получается, что опенсорс никак не влияет, ведь никто не читает этот код? =))
Когда уже появится systemd-sudo?!