Компания Google объявила (https://security.googleblog.com/2019/03/open-sourcing-sandbo...) от открытии проекта Sandboxed API (https://github.com/google/sandboxed-api/), позволяющего автоматизировать процесс формирования sandbox-окружений для изолированного выполнения произвольных библиотек на языке C/C++. Изоляция кода библиотек позволяет защититься от потенциальных атак на предоставляемые библиотеками обработчики, создавая дополнительный барьер на случае наличия в их коде уязвимостей, которые можно эксплуатировать через манипуляции с поступающими в библиотеку внешними данными. Код открыт (https://github.com/google/sandboxed-api/) под лицензией Apache 2.0.
Изоляция осуществляется при помощи runtime Sandbox2 (https://github.com/google/sandboxed-api/tree/master/sandboxe...), в котором для изоляции применяются пространства имён, cgroups и seccomp-bpf. Вынесенный в sandbox код выполняется в отдельном процессе, для которого ограничивается доступ к системным вызовам и ресурсам, таким как файлы и сетевые соединения. Процессы получают доступ только к системным возможностям, которые непосредственно требуются для выполнения изолируемого кода.
Sandboxed API является надстройкой над Sandbox2, упрощающей портирование существующих библиотек для выполнения в изолированном режиме. Sandboxed API предоставляет промежуточный программный интерфейс, дающий возможность запустить код библиотеки в sandbox-окружении, а также организовать проброс в sandbox-окружение обращений к библиотечным вызовам и обеспечить доставку в основную программу результатов работы библиотеки. Обращение к изолированной библиотеке осуществляется через специализированный RPC, базирующийся на протоколе ProtoBuffs.
Для разработчиков библиотек предлагается набор примитивов, позволяющих из базового приложения обращаться к переменным, файловым дескрипторам, буферам в памяти и функциям изолированной библиотеки, в том числе предоставляются средства для автоматической и управляемой синхронизации памяти для совместного доступа к массивам и структурам. Дополнительно предоставляется API для мониторинга за работой изолированных процессов с библиотеками и их перезапуска в случае сбоев. Кроме повышения защиты, положительным моментом применения изоляции является возможность отдельного регулирования лимитов на потребление библиотекой памяти и CPU, а также защита от сбоев -
сбой в библиотеке не приводит к краху всего приложения.
Для изолируемой библиотеки автоматически или вручную формируется заголовочный файл с правилами изоляции и список с аннотациями изолируемых функций для сборочной системы Bazel. Правила изоляции определяют все разрешённые системные вызовы и операции (чтение, запись, открытие файлов, доступ к времени, возможность установки обработчиков сигналов, поддержка выделения памяти через malloc и т.п.). Отдельно определяются файлы и каталоги к которым должна иметь доступ библиотека.
В настоящее время проект доступен только для Linux, но в будущем обещают добавить поддержку macOS и BSD-систем, а в отдалённой перспективе и Windows. Из планов также отмечается поддержка переноса в sandbox программ, написанных на языках, отличных от C и C++.
URL: https://security.googleblog.com/2019/03/open-sourcing-sandbo...
Новость: https://www.opennet.me/opennews/art.shtml?num=50349
Какая все же славная эта корпорация. Вот, еще одну технологию опубликовали в опенсорс.
На какие же извращенские технологии идут чтобы до сих пор пользоваться небезопасными С/C++... Нет чтобы просто взять и юзать Rust. Я просто не понимаю насколько нужен низкий интеллект у тех кто до сих пор юзает C/C++ для новых систем и сервисов.
> Нет чтобы просто взять и юзать Rust.Ты уже взял и юзаешь? Или, как и большинство растофанов, получаешь зарплату за разработку на ненавистных крестах, а ржавой слюной брызжешь только на форумах?
сильно сомневаюсь, что он пишет на расте, жир протекает через монитор.
https://github.com/vn971?tab=repositories
Что это за ржавые пет-проекты со случайного гитхаб-аккаунта?
Только звёзд у него будет побольше чем у всех местных растоненавистников вместе взятых
Прям про меня...
Твой Раст не юзабильный еще на столько. А синтаксис так он вообще убогий.
Приведи пример на твое мнение хороший синтаксис. Как по мне синтаксис у Rust минималистичен и лаконичен. https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html
И теперь сравни эту простоту с синтаксисом С с поинтерами и особенно разбором конструкций дефайнов с поинтерами на функции... А так же посмотри на темплейты С++.Кажому языку свое время, С и С++ уже изжили себя. Интересно почему до сих пор не пишут на Cobol? (ну кроме допотопных единичных программ на поддержки)
c/c++ изжили себя, php умер и блаблабла
> Приведи пример на твое мнение хороший синтаксис. Как по мне синтаксис у
> Rust минималистичен и лаконичен. https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html
> И теперь сравни эту простоту с синтаксисом С с поинтерами и особенно
> разбором конструкций дефайнов с поинтерами на функции... А так же посмотри
> на темплейты С++.Синтаксис Си на порядок проще синтаксиса Rust'а.
> Кажому языку свое время, С и С++ уже изжили себя. Интересно почему
> до сих пор не пишут на Cobol? (ну кроме допотопных единичных
> программ на поддержки)
Rust не обезопасивает от логических ошибок. Выполнять программу в песочнице — хорошая мысль, даже если программа написана на Rust'е.
Запомни и повторяй как мантру: "ЯП, годного на роль серебряной пули не бывает". Поутру, в обед и перед сном. И поставь себе на смартфон какую-нибудь приблуду, чтобы каждый день выводила тебе на экран рандомную цитату из трудов "Банды четырех" - медитируй над ней и размышляй о своей греховности.Интеллект же у тех, кто юзает C/С++ в промышленной разработке заведомо поболее, чем у культистов очередного модного поветрия. Порог вхождения, хвала Омниссии, не позволяет иначе.
(Дисклаймер - ничего не имею против Rust как такового, пусть развивается, тогда будем посмотреть.)
"Безопасный" Rust? Подскажите пожалуйста, сколько раз в исходниках библиотеки встречается unsafe?
Напиши и отладь тонну либ на расте, затем поговорим
Сперва добейся
Ага, скажете это десяткам разрабов и десятку лет разработки OpenSSL библиотеки и вспомните HeartBleed и другие уязвимости там связанные со спецификой языка, например не очисткой за собой памяти нулями, переполнением буфера, уход за границы массива и т.д. и т.п.
Это лишь один из тысяч примеров когда перепись на Rust просто сразу обеспечивала защиту от подоюных уязвимостей.
> Это лишь один из тысяч примеров когда перепись на Rust просто сразу обеспечивала защиту от подоюных уязвимостей.А что, OpenSSL переписали на Rust?
А что, тысячи других программ уже тоже? Похоже, автор комментария просто забыл сослагательное наклонение использовать.
> На какие же извращенские технологии идут чтобы до сих пор пользоваться небезопасными С/C++Да ладно, для раста такие контейнеры ещё полезнее чем для C++. Ты можешь подключать C'шные либы делать unsafe { unsafe_lib::unsafe_c_func() } и в случае если там какая хрень, то делать что-то в стиле panic!("unsafe code is so unsafe"). Или вместо няшной паники, ты можешь сделать return Err(UnsafeIsSoUnsafe::new()), и в процессе размотки стека этой ошибкой подчистить ресурсы, закрыть правильно файлы, сделать другие полезные вещи, и только после этого няшно спаниковать.
Что за извращение, Rust! Только хардкор, только Erlang! Ну на худой конец - Malbolge.
Проблема Rust в том, что трудовой рынок ещё не до конца сформирован. Разработчиков днём с огнём не сыщешь даже в крупных городах вроде Москвы. Хотя те, кто уже есть уровнем явно выше C++/PHP-макаки.Говорю как пишущий на ржавчине за еду^Wзарплату.
А ничего что в Rust'е есть unsafe и практических во всех "узконаправленных" вещах приходится его использовать? А там вообще что угодно происходит. В C/C++ хоть в стандарте прописано UB, а в unsafe плевать что происходит.
> Обращение к изолированной библиотеке осуществляется через специализированный RPC, базирующийся на протоколе ProtoBuffsА какой транспорт используется для реализации этого RPC, shared memory?
Всё дурака валяют вместо того, чтобы переписать сишный говнокод на няшной ржавчине.
си еще долго будет языком системного уровня. просто потому что... стандарт? у других нет удобства того же питона( хотя некоторые места там спорно) и нет скорости выполнения. плюс библиотек в си/с++ вагон и маленькая тележка. да и правда смотрел я на раст как то ... сомнительная стилистика написания кода. и не сишная и не явская и не питоновская. такой каламбур, что диву даешься. и е походу чем больше модернизируют, тем все более запутанная. походу они в попытках убрать ошибки проектирования языка делают его все ... тяжелее в использовании?
А еще практически во всех ОС ABI все еще от первых Unix и C.
> А еще практически во всех ОС ABI все еще от первых Unix
> и C.Будто что-то плохое.
Да проблема индустрии ж не в языке. И не в синтаксисе ЯП. Проблема в том что давно уже пришла пора написать новый язык вместе с новой ОС. Как в свое время Юникс родился вместе с Си - до этого все ОС писали на АСМ-е или вообще в машинных кодах. Вот давно уже пора написать совершенно новую ОС в которой ВСЕ будет объектами с нативной поддержкой объектных API сверху-донизу, в новом ЯП... Но тут куча проблем, и первая же - где "граница" для этой новой ОС и должно ли сетевое взаимодействие в этом "чудном новом объектном мире" тоже играть по общим "новым правилам"... И как вообще "договориться" между "старым и новым миром"? ... И попытки таких проектов я так понимаю уже были, только ни одна не завершилась коммерческим успехом... Ну а в существующем программном окружении "только костыли, только хардкорд"...
Есть такая ОС (попытка его создать): Фантом ОС https://ru.wikipedia.org/wiki/Фантом_(операционная_система) , где всё есть объекты. Он много раз всплывал в разных конференциях, но дальше обсуждений, вроде не дошло.
firejail?
По описанию похоже на cloudabi