В середине обсуждения замечена типичная реакция известной аудитории - с потоками... удобрений... на поля
С последующим признанием, что никто из них 100% никогда не вляпался бы в эту проблему...
Выявленный случайно за годы использования дефект vs. тем, что я читаю через день в окне обновлений Ubuntu с названиями "Критическое обновление безопасности...". Сегодня меня предупредили, что для моей версии (10.10) обновлений безопасности больше не будет. И где позор?
Теперь по существу вопроса. Есть два понятия в сфере критических систем - safety (безопасность) и security (защищённость). Кроме них, ещё два - работоспособность и безотказность. За подробностями - к любой классике программной инженерии, например, Соммервиллу.
Safe-система - которая при штатных условиях применения не способна причинить вред. Безопасной бритвой невозможно причинить себе существенный вред при бритье. Но вполне можно убить человека, если выломать лезвие.
Security - это устойчивость системы к преднамеренным вредоносным действиям злоумышленника.
Да, в области языков программирования есть значительная связь между безопасностью и защищённостью.
Она связана с тем, что небезопасность языка провоцирует такие ошибки в программе, которые делают возможной её уязвимость извне - передачей специально подобранных данных. Либо сетевая уязвимость, либо межпроцессная (например, возможность вредоносного воздействия на код в нулевом кольце защиты). Пресловутые атаки на переполнение буфера. С точки зрения такой уязвимости обсуждаемый вопрос проблемы не порождает.
Всего лишь есть гипотетическая вероятность написать такой код, который приведёт к отказу. Как и при неправильном использовании SYSTEM. Оценки безопасности не делаются так же, как защищённости. В защищённости логика бинарная - либо есть уязвимость, либо нет. Потому что если есть, то она будет использована. В безопасности оценка вероятностная. Если вероятность случайно вляпаться пренебрежимо мала (и, тем более, на практике никогда не встречалась), то это не является претензией к safety. И не оказывает никакого влияния на работоспособность-безотказность.
Есть другое поле для обсуждения - вопрос компонентного программирования. Здесь safety языка, начиная с работ Вирта, рассматривается как гарантия невозможности разрушительного влияния одного компонента на другой. Тут мы подходим к интересному вопросу - влияния непроизвольного (из-за ошибки) или преднамеренного? С точки зрения непроизвольных влияний всё ясно - была убедительно показана безопасность языка и её преимущества для компонентного программирования.
С точки зрения преднамеренного. На мой взгляд, преждевременно были сделаны выводы о том, что safe-язык отменяет необходимость традиционных механизмов защиты ОС. Эти заключения вывода Вирта и учеников были потом повторены компанией Sun, которая связала safety и security внутри одного пространства памяти, куда "запускается" произвольный пришедший из недоверенного источника компонент. Как известно, много лет спустя были обнаружены уязвимости в их байт-коде, точно так же, как уязвимость через наш WITH.
На самом деле, про security внутри общего пространства памяти стоит забыть. Как минимум, потому, что security включает в себя не только невозможность разрушения системы, но и невозможность несанкционированного доступа к данными. Когда у нас есть единый граф связей, и "всё всюду гуляет", придумать механизмы контроля доступа - это безумно усложнить язык и/или библиотеки и/или рантайм. Поэтому, в сравнении с традиционными механизмами межпроцессной защиты такие попытки "идут лесом".
Просто традионная ОС "Оберон" была однопользовательской локальной. Индивидуальным инструментом. Поэтому ряд вопросов был оставлен за бортом, чтобы сконцентрироваться на других.
Это оправдано и по сей день, если в систему не приходят компоненты из недоверенных источников. Например, если это встроенная система. С серверной системой всё уже не так просто, если мы хотим позволить третьим лицам исполнять на нашей стороне что-нибудь. В частности, в том числе и поэтому я посчитал нецелесообразным опираться в сетевых проектах на ОС A2. В ней нет межпроцессной защиты. Которую я имею, гоняя Блэкбоксы на Линуксе.
Я рассматривал этот вопрос ещё больше года назад в статье в "Объектных системах".
http://ermakov.net.ru/pub/EIE-21-2010.pdfОднако, как всегда, имеется и оборотная сторона медали: размываются границы между зонами ответственности отдельных приложений, затрудняется выгрузка и перезапуск отдельных компонентов (из-за плотной интеграции в «паутину» указателей). Наконец, практически невозможно обеспечить контроль прав компонентов и защиту от злонамеренных действий, либо это ведёт к такому усложнению языка и объектной системы, которое выходит за всякие рамки инженерной целесообразности. Таким образом, наличие раздельных объектных пространств остаётся востребованным для современных систем, за исключением некоторых применений (например, встраиваемых, мультимедийных — как раз тех, в нишу которых направлена ОС А2).
Конечно, проще драть глотку, чем серьёзно и непредвзято разбираться в вопросе.
