SELinux, AppArmor и др. системы безопасности

В меру своих познаний в этом вопросе тоже пытался его провентилировать. Узнал только то, что инженер по имени Nicko van Someren сейчас работает на good.com. До этого был сооснователем nCipher. Одно ли это лицо – мне не известно. В любом случае есть первоисточники, которые могут что-то прокомментировать. (если не боятся оказаться в транзитной зоне аэропорта, разумеется)

p.s. странное дело, страницы в истории браузера за пару дней перестали открываться в полном объеме. Брал: _http://www.nigma.ru/index.php?startpos=10&s=Thales+Someren&srt=1&gl=1&yh=1&ms=1&rm=1&av=1&nm=1&k=ISjT&rg=t%3D%D0%95%D0%BA%D0%B0%D1%82%D0%B5%D1%80%D0%B8%D0%BD%D0%B1%D1%83%D1%80%D0%B3_c%3D%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D1%8F_&rg_view=%D0%95%D0%BA%D0%B0%D1%82%D0%B5%D1%80%D0%B8%D0%BD%D0%B1%D1%83%D1%80%D0%B3%D0%B5 (14.)

unknown:
Понятно, что злонамеренность АНБ может помножить всё на бесконечность, но хотелось бы технические соображения по этому поводу.

Искать криптографические примитивы?
3.0 COVERT CHANNEL IDENTIFICATION

Какое отношение имеет код SELinux к криптографическим примитивам? В статье речь идёт о TCB PRIMITIVE.

unknown:
Какое отношение имеет код SELinux к криптографическим примитивам?

Сложно сказать. Фактов нету. Возможно, никакого. На данный момент отсутствие информации о недокументированных возможностях, связанных с криптографией, SElinux и отсутствие таковых вообще – для меня равнозначно. Мало вероятно, что в реализованном тайном канале данные будут гонять в открытом виде, а количество кода, предназначенных для таких целей, ограничено(?) SElinux-ом. Не?

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

Другое дело, что есть экспериментальные наработки по скрещиванию SELinux с IPSEC (которые у пользователя в большинстве случаев будут отключены, а механизм какого-нибудь троянского включения и отправки будет заметен в коде), но опять же, если какая-то функция, которая не требует использования крипто, будет в коде лезть за криптофункциями, то это будет заметно элементарно. Закладки так тупо не делаются. Можно поспекулировать как их предположительно могут внедрить, один вариант я уже привёл. Могут буть и другие, но не столь примитивные.

Ок. Техническая часть обнадеживает мои скромные познания…

Будем считать, что SElinux не имеет недокументированных возможностей. Т.к. АНБ, являясь государственной конторой, может себе позволить реализовать и использовать "законный" тайный канал. SElinux как система безопасности не будет иметь возможностей для его отключения. Теперь вопрос в том, как реализован этот "законный тайный канал", чтобы подобрать альтернативную систему защиты для его надежного отключения.

Да всё проще и сложнее одновременно.

SELinux, как и любая система — несовершенна. А любое несовершенство можно скрывать, тайно усиливать вместо исправления и использовать по своему назначению.

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

Во-вторых, несовершенство приводит к тому, что не все правила и принципы их построения охватывают все векторы атак. О чём могут преднамеренно умалчивать разработчики, если они знают больше и хотят это скрыть.

В-третьих, какое-нибудь элементарное переполнение, ошибка, опечатка в пару строчек или переменных, которая даёт возможность выполнить запрещённое действие.

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

Команда экспертов, сосредоточенная на поиске эксплойтов под Tor, GnuPG, OpnSSL, что-угодно, да ещё имеющая своих инсайдеров в этих открытых проектах (чтобы лучше разбираться в теме и знать, какие вопросы и как решаются в проекте изнутри) может даже не размещать туда никаких закладок, а просто более грамотно анализировать код, чем рядовые исследователи, которые иногда этим занимаются лишь от случая к случаю и поверхностно.

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

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

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

unknown уже написал, но тоже выскажусь. Зачем добавлять в selinux криптографию, когда она уже есть практически в любой системе. Достаточно осуществить взлом системы через любое сетевое приложение (пользуясь припрятанным "багом"), а потом воспользоваться например ssh.

Да и вообще какой смысл анб делиться мощным средством безопасности с открытым сообществом, которое у него как кость в горле? Те, чья профессия – красть информацию, вдруг озаботились её сохранностью. Это противоречит здравому смыслу – как вор озаботился вашим благосостоянием.

«О том, почему конкуренция исследовательских программ (по взлому и по защите) является выигрышной стратегией. Разные части одного ведомства могут плодотворно работать друг против друга».

Потому что "любая криптография будет торчать, как заячьи уши" :) Их трепыхание будет привлекать с себе внимание. Криптографические функции, реализованные внутри большого проекта не так заметны. Это в плане дискуссии.

Я же пока остаюсь при том мнении, что АНБ нет необходимости *шифроваться*. Если почитать цветные книги, это становится очевиднее.

В ядре есть cryptoAPI.

За формулировками теряется что-то важное. Не пойму что…
http://ru.wikipedia.org/wiki/Скрытый_канал

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

Стеганографию мы относим к криптографии? Если да, тогда она(стеганография) в скрытых каналах реализуема через cryptoAPI ядра?

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

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

Немного кривая метафорическая аналогия.
Если в городе можно спрятать что-то в доме иди дереве, то если в городе растут деревья, возможен вариант тайника и в них. А если в лесу нет домов, то какой бы большой он ни был, но его можно обойти и наткнуться на дом, который сразу заметен, как посторонний объект, то где лучше спрятать тайник — в доме или дереве?

Из интервью Рутковской:

за последние несколько лет только один раз было публично сообщено об использовании уязвимости в Xen с целью взлома: это был код, написанный NSA (управление национальной безопасности) с целью реализации расширений, направленных на безопасность (какая ирония!).

http://www.thg.ru/software/joa.....ka_interview-01.html

Т.е. в Xen была лишь одна уязвимость и она создана анб. И тоже в расширении безопасности (аналогия с selinux). Как вообще можно всерьёз рассматривать в качестве средства безопасности ПО написанное в спецслужбе? unknown тут как-то писал, что для любого серьёзного проекта необходима репутация, одного лишь открытого кода мало, и от анонимов добавления не принимаются. Репутация анб как профессиональных жуликов хорошо известна, но тем не менее их продукты и стандарты почему-то широко используются и пропагандируются.

На другой странице там же:

Однако, мы прекрасно понимаем, что Qubes никогда не станет системой для домашнего использования. Установить её правильно будет слишком сложной задачей для обычных пользователей.

А дальше идёт фейспалм:

Мне, например, нравится продукция Apple. Однако, для безопасности данных я готова использовать другой ноутбук, не Mac.

THG.ru: А используешь ли ты Qubes в качестве основной системы? Или в паре ещё с какой-то ОС?
Джоанна: Да, я использую Qubes в качестве основной системы. Я полностью перешла на неё в марте 2010 года

Основной разрботчик ОС перешёл на использование этой ОС. Давно так не ржал. :)

Сейчас я использую Sony Vaio Z в качестве основного ноутбука, на нём установлен Qubes. Этот компьютер имеет некоторые преимущества перед MacBook

Для разных задач вроде чтения новостей, составления списков покупок, ведения ежедневника, фото, слайдов и так далее я использую iPad 2

Ужас. Я даже не знаю, что из этих трёх вещей хуже и более зловредно: Sony Vaio, MacBook или iPad. Они все друг друга стоят.

Имеем случай ещё одного разработчика одной разработчицы, которой «нечего скрывать».