Complexity hides insecurity

[vitus_wagner]

Похоже, что желание создать нормальное Free Software, в смысле, такое, которое пользователь действительно свободен модифицировать, потому что способен понять, таки начинает у народа возникать.

Вот, например, Tomb, юзер-френдли инструмент для создания криптованных дисков, написанный на shell. Под лозунгом complexity hides insecurity.

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

Но в общем и целом подход вполне заслуживает внимания.

Comments

[vitus_wagner]

Не существует такого языка, который внушал бы в этом плане доверие. У всех свои плюсы, и свои минусы. Прямо скажем, C, где даже управление памятью - закат солнца вручную, еще хуже в этом плане.

Шелл - язык высокоуровневый. Куда более высокоуровневый чем python или tcl.

И именно поэтому код на нем получается компактным и обозримым.

В принципе, конечно, шелл как язык программирования GUI малопригоден. За 30 лет существования X11 так и не придумали достаточно удобного способа писать на шелле GUI. Но нужен язык сравнимой высокоуровневости.

[mc6312.livejournal.com]

> И именно поэтому код на нем получается компактным и обозримым.

Угу, и состоит из вызовов внутренностей *sh (писанных скорее всего на сях) и внешних программ, писанных на черт знает чём. Т.е. просто заметание мусора под ковёр.

[cross-join.livejournal.com]

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

[max630.livejournal.com]

По-моему, шелл в части безопасности хуже чем даже C, проблемы которого легко обойти, и автоматически проконтролировать что нигде ничего не упущено. Вообще безопасность в первую очередь зависит от того что можно чегко увидеть что делает код и быть уверенным что он делает именно это всегда. С C по моим ощущениям большинство уязвимостей связано с переполнением целых, и это как раз то место где он ведёт себя неочевидно. Шелл же ведёт себя неочевидно примерно везде. Вот там printf в коде. Вы насколько уверены что он именно напечатает строку, а не пошлёт пароль рута в интернет?

Ещё хорошо что они bash не использовали, тот вообще до недавнего времени выполнял произвольные команды из окружения при запуске, да и сейчас механизм импорта функций из окружения такой что в общем случае вообще ничего нельзя передавать из пользовательского ввода, потому что любая переменная может оказаться с тем же именем что и используемая в скрипте команда. Но и zsh тоже такой комбайн что не удивлюсь что там что-то найдётся.

[qkowlew.livejournal.com]

С C по моим ощущениям большинство уязвимостей связано с переполнением целых, и это как раз то место где он ведёт себя неочевидно

facepalm.jpg

- арифметика указателей
- логика помещения в стек параметров и возвращаемых значений
- отсутствие в рамках языка средств контроля адресных пространств

Порождены и упомянутый Вами, и эти спецэффекты именно низкоуровневостью изначальной архитектуры и нежелании (на начальных этапах существования языка) потратить на средства контроля хоть копейку имеющихся ресурсов КАК на этапе исполнения, ТАК и на этапе компиляции.

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

[leotsarev]

Зато мне неоднократно удавалось написать содержательный код на Си, который компилировался в не менее эффективную программу, нежели тот же самый алгоритм, реализованный на ассемблере той же машины.
Вроде как сейчас считается, что опытный программист проигрывает современным компиляторам в попытке написать столь же эффективный ассемблерный код в подавляющем большинстве случаев, и эта попытка в принципе не имеет смысла (а вот посмотреть что компилятор сгенерил и попробовать улучшить в критическом цикле — может иметь смысл).

Кстати, в связи с этим крайне интересен язык Rust. Сохраняя идею «нулевого рантайма» (в смысле ни капли ресурсов на контроль во время исполнения), он пытается проверить и доказать корректность использования указателей на этапе компиляции.

[qkowlew.livejournal.com]

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

Я лично считаю, что опытный программист способен написать и ОТЛАДИТЬ одинаково эффективный код на низкоуровневом языке МЕДЛЕННЕЕ, чем сколь угодно опытный на языке высокого (в смысле контроля) уровня.

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

[max630.livejournal.com]

> арифметика указателей

Вот для арифметики указателей как раз наибольшие проблемы доставляет переполнение всяких смещений. Остальные ошибки как я понимаю, тривиальны и ловятся при минимальном тестировании.

[qkowlew.livejournal.com]

Остальные ошибки как я понимаю, тривиальны

Вашими бы устами...

[ramendik]

Шелл же ведёт себя неочевидно примерно везде.
+1024