В этой серии рассматриваются некоторые технологии, которые мы могли бы применить, если бы сегодня создавали новую платформу. В первых двух частях (<a href=http://www.osrc.info/content.php?article.60>первая</a>, <a href=http://www.osrc.info/content.php?article.69>вторая</a>) рассматриваласьаппаратура и ядро ОС. В этой, третьей части, мы рассмотрим безопасность, файловую систему, управление файлами и, для лучшего объема, вбросим еще несколько случайных идей.<br /><br />
Перевод: Роман Химов aka Roman I Khimov <br />
<a href=http://www.osnews.com/story.php?news_id=7804>Оригинал </a> доступен на OSNews.com.

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

&lt;напыщенность режим=""&gt;Мне сильно не нравится тенденция индустрии ПО винить пользователей в проблемах в безопасности: это отмазка, уход от ответственности Проблемы безопасности созданы компьютерной индустрией и ей их и решать. Вирусы, трояны и другие неприятности существуют уже много лет, так как пользователи могут быть виноваты, когда производители не сделали ничего видимого, чтобы их защитить? Владелецу автомобиля не надо знать о внутреннем устройстве его машины для того, чтобы ее водить, почему же мы должны знать о том как работают внутренности компьютера? Безопасность это непростая тема [Security], но это не извиняет обвинений пользователя.&lt;/&gt;

Если надо загружать заплатки, система должна, по умолчанию, проверять их наличие ежедневно. Конечно, если система была изначально нормально спроектирована, то много заплаток не понадобится. Microsoft предупреждали о потенциальных проблемах в безопасности годы назад, они что-нибудь сделали для этого? Чья это ошибка? Уже говорилось, что существуют более защищенные ОС, нежели Windows, особенно ОС, основанные на Unix, такие как Linux / *BSD и OS X (несмотря на ловко замаскированныепопытки маркетологов сказать иначе).

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

Проверка на вирусы
Сканер вирусов, который должен проверять все, должен быть стандартной частью системы, а не дополнением. Даже если вирусов (или вирей) нет, система должна сканировать приходящие файлы, чтобы проверить, являются ли они или их часть исполняемым кодом.

Все новые файлы - в песочницу
Все файлы, не только присоединенные к электронным письмам или скачанные из веба, таким образом они не смогут нанести никакого вреда. Если исполняемый файл ни разу не запускался, сразу же его помечать таким, чтобы когда его запустят, его можно было сперва поместить в "". FreeBSD умеет это делать через Jail (тюрьмы) [Jail].

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

Не позволять программам удалять все файлы
Также, нельзя позволять программам иметь доступ к резервным копиям файлов (смотри секцию "Файловая "). Это не даст вирусу или заблудшей программе удалить все файлы в вашем домашнем каталоге. Если она пытается это сделать, файлы должны перемещаться в резервные копии, а система должна следить за файловой системой, выявляя такое поведение, предупреждая пользователя об этом факте, и предагать ему возможность восстановления файлов или запрещения приложения, или еще какие-нибудь действия для специальных файлов. Удаление резервных копий должно быть привилегией, которую имеет только пользователь - ни одно приложение не должно иметь такой возможности.

Такой сценарий возможен практически во всех операционных системах, и это случилось со мной в Linux, в далеком 2000-м году. Альфа-версия браузера Opera упала и удалила содержимое моего домашнего каталога, не стоит и говорить, что я был не очень счастлив узнать об этом. Я ожидал, что альфа-версия будет нестабильна, без некоторых функций, но я не ожидал (и не ожидаю), что она может вычистить мой домашний каталог. Если приложение было настолько плохо сделано, что смогло сотворить это, подумайте, что может сделать программист со злыми намерениями. Сегодня приложения по умолчанию могут вызывать столько разрушений в вашем домашнем каталоге, сколько им хочется. Система не должна этого допускать.

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

Не запускать сервисы от имени Root
Этого невозможно достичь на большинстве систем, основанных на Unix, из-за архитектуры ядра. А одно из преимуществ микроядра, в том, что нет необходимости запускать сервисы от имени root [Microkernel], что уменьшает возможности сервисов сделать что-либо зловредное.

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

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

Экспортируемые сервисы
Как только я запускаю веб-сервер, он автоматически становится виден всем снаружи, если только он не был закрыт файрволлом. Я предлагаю добавить в нашу систему "" так, чтобы только те сервисы, которые были специально "" через этот туннель, были видны внешнему миру. Это означает, что веб-сервер придется специально экспортировать, прежде чем он будет доступен снаружи. Туннель также сможет вести мониторинг, так что можно будет отслеживать и смотреть на то, что в систему приходит и уходит, и если будет работать что-то не то, можно будет запретить ему экспорт (автоматический экспорт самими программами должен быть запрещен).

Однако, вопрос о том как реализовать туннель по прежнему открыт. Одна из идей - обеспечить два сетевых стека: внутренний стек будет взаимодействоваь с программами в системе, а внешний стек будет работать с внешними сетевыми интерфейсами. Туннель будет сидеть посередине, соединяя два стека. Вы можете запустить маршрутизатор, файрволл, NAT (Network Address Translation) и другие сервисы на внешнем стеке, в то время как внутренний стек будет полностью изолирован от интернета. А когда вы соедините их, вы сможете идти через NAT, который сам по себе добавляет еще один слой безопасности.

индекс статьи
страница 1 - текущая : страница без заголовка
страница 2 : страница без заголовка
страница 3 : страница без заголовка