Безопасность IDE

Скорее всего есть. Прецедент то был.

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

Безопасность, говорили они....
Впрочем, что можно ожидать от людей, вместо IDE запускающих ЖРАУЗЕР
Поделом!

вместо IDE запускающих ЖРАУЗЕР

Как раз хотелось бы видеть в ide механизмы защиты наподобие браузерных - отношение к lsp/прочим внешним сервисам как к недоверенному коду и запуск этого кода в изолированном окружении.

А то открыл в ide проект с тем же растом - получил rce в хост окружении.

Кстати, было бы вполне логично lsp серверы пускать в каком-нибудь контейнере/chroot под seccomp изоляцией

Браузер тут ни при чем. Даже в Емаксе можно скрипт вставить, он читает dir-locals и исполняет код

Жетбрейновские ИДЕ теперь спрашивают при открытии проекта, доверяю ли я ему) Видимо это и есть фикс)

Напомнило офис, спрашивающий о безопасности макросов в документе XD

lsp тогда как wasm и делов то раз уж браузер

Вроде видел что-то подобное про вскод - тоже спрашивает. Но это прям куллфикс.

Просто удивительно, насколько всё плохо. Либо у меня с осведомлённостью, либо в индустрии с безопасностью.

Однако в emacs’t есть и механизмы против этого. Нужно явно разрешить исполнять левый код не спрашивая, чтобы так пострадать.

А вот режимы запускать в песочницах очень бы хотелось …

Редактор тут не причём. Там выполняются вредоносные макросы из кода, т.е. считай зумеры переизобрели макровирусы из MS Office 97.

В качестве решения, собирай код в контейнере или виртуалке и подключайся редактором туда.

Нет в Emacs механизмов против этого, потому что это не дыра редактора. Это дыра сборочной системы.

Проблема связана с раскрытием процедурных макросов во время начального анализа кода. Аналогичного эффекта также можно добиться во время компиляции с использованием команды «cargo build».

Редакторы при чём. Не нужно запускать что попало и как попало(и далее на вопросы отвечать - это не мы, это левый код, а то что мы его по своей воле запустили - то не считается). Это крайне несерьёзный подход, особенно спустя 4 года существования уязвимости.

С таким же успехом браузер ни при чём - это всё крафченный хтмл/плохой жс. Тут же ни у кого не возникает мысли «пускай браузер в виртуалке и подключайся туда».

А что ты тут исправишь. Ничего не исправишь. Не надо открывать что попало.

Редакторы не запускают ничего кроме LSP сервера. И вот ему нужна песочница в первую очередь.

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

Браузеры выполняют JS в песочнице как раз.

Где тег rust?

Спрашивают, хорошо. А что дальше? Отвечаешь нет - не открывают проект. Отвечаешь да - отправляют ~/.ssh/id_rsa?

Редакторы не запускают ничего кроме LSP сервера. И вот ему нужна песочница в первую очередь.

Так у тебя ничего работать не будет. Челы же сделали возможность в макросах подключаться к базам не чтобы ssh ключи тырить, а чтобы генерировать код из схемы БД, например.

В принципе очень многие нетривиальные проекты подобное делают.

Ну не запустится у тебя код из редактора. Запустится, когда ты билд запустишь. Ты же явно скачал исходники не только для того, чтобы в IDE их открыть. Всяко будешь собирать.

Так что правильный подход тут один - разрабатывать всё в контейнере. Чтобы там всё было. И сборка, и IDE и LSP-сервер, и всё остальное. Но в то же время чтобы ничего ценного там не было.

Нет, не только lsp. И вот зпуск lsp/cmake/прочего с изоляцией я и хотел бы видеть. А ты зачем-то мне пишешь «у редактора проблем нет».

Челы же сделали возможность в макросах подключаться к базам не чтобы ssh ключи тырить, а чтобы генерировать код из схемы БД, например.

Шта? Так никто вообще не делает.

Так что правильный подход тут один - разрабатывать всё в контейнере. Чтобы там всё было. И сборка, и IDE и LSP-сервер, и всё остальное. Но в то же время чтобы ничего ценного там не было.

А дальше? Если у тебя зловред в исходниках, что ты будешь защищать-то и как? Макросами тут дело ведь не ограничивается.

Добавил по просьбам.

А дальше? Если у тебя зловред в исходниках, что ты будешь защищать-то и как? Макросами тут дело ведь не ограничивается.

Исходники иногда просто смотрят, а вовсе не компилируют и тем более не запускают. Например могут смотреть как раз для того, чтобы определить - можно ли запускать или нет.

А дальше? Если у тебя зловред в исходниках, что ты будешь защищать-то и как? Макросами тут дело ведь не ограничивается.

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

Ну или вообще ничего не защищать и надеяться на то, что ничего плохого не случится. А если и случится, то не критично плохое. Как в основном все и делают в общем-то.

Так что правильный подход тут один - разрабатывать всё в контейнере. Чтобы там всё было. И сборка, и IDE и LSP-сервер, и всё остальное. Но в то же время чтобы ничего ценного там не было.

Ну да, только не разрабатывать, а пускать всё в контейнерах. Тоже не особо хорошо, но хотя бы не настолько дыряво.

Нет, именно разрабатывать. См. dev containers. Популярная тема. Это больше для удобства разворачивания окружения сделано, но и для безопасности тоже полезно.

Нет, именно пускать. См. web browser. Популярная тема. Это больше для удобства просмотра контента сделано, но и для безопасности тоже полезно.

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

CVE-2024-53920: Versions before GNU Emacs 30.1 are vulnerable to arbitrary code execution when a user performs code completion on untrusted Emacs Lisp source, triggering unsafe Lisp macro expansion.

CVE-2024-39331: Emacs before version 29.4 contains a code injection vulnerability in Org mode's org-link-expand-abbrev function, which improperly expands links specifying unsafe functions.

CVE-2024-30202: Versions before Emacs 29.3 are affected by this vulnerability, allowing arbitrary Lisp code evaluation when enabling Org mode for a file due to the mode trusting file content by default

Надо пытаться защищать всё.

Если у тебя в коде проекта зловред, защищать уже поздно, не?

Я всё больше склоняюсь к тому, чтобы вендорить все зависимости и проверять их как свой код.

Вы не понимаете, это другое! Я только насчёт «читает dir-locals и исполняет код» отвечал. А CVE да, бывают, тут уж ничего не поделаешь, только emacs целиком на rust переписывать.

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

Это не теперь, это давнишняя тема. Года этак 24

Они открывают недоверенный проект и ты можешь его почитать. Они скрипты из него не запускают и конфиги не применяют. Когда убедишься, что все ок можешь обратно включить, ибо в этом режиме работает совсем куций функционал иде.

Да, извиняюсь, CVE все действительно про моды