авторы SELinux считают, что создание модели безопасности на основе путей, а не модификации файловой системы и введения доменов безопасности — неполноценно и демонстрировали, как можно обходить AppArmor. Модель безопасности AppArmor заведомо ущербна и содержит в себе концептуальный изъян.

Но как компромисс в сторону упрощённости в обмен на меньшую безопасность сойдёт.

Вы слишком редко участвуете в срачах на pgpru

демонстрировали, как можно обходить AppArmor

Реклама от Новелла^[link6], какой сложный и неудобный SELinux.

Статья^[link7] с мнениями двух сторон. Поверхностная, технические детали освещены слабо, но как можно проводить эскалацию привилегий в AppArmor показано.

Просто, когда тыкают в ужасный код модулей SЕLinux, не понимают, что он описывает не просто права доступа, но все возможные потенциальные действия компонентов программы, включённых в домены безопасности (например — не положено такой-то проге иметь выход в сеть или положено только определённым образом, порты, сокеты, доступ к ресурсам ядра и др. и сделано это не по путям, метки принадлежности к домену проставлены на уровне ФС, а никто из домена не сможет сбросить контекст для перехода к пользователю в другом домене, если не прописаны переходы доменов, так что даже получив эксплойтом рута за пределы этих политик не выйти).

В сети есть демо-машинки с рутовым доступом по ssh для желающих помучать SELinux, никто вроде не взломал за много лет.

Есть ещё концепт безопасности от Джоанны Рутковской

Скорее малореально, полистайте пэдээфку к работе в конце страницы: http://qubes-os.org/Architecture.html

Много всяких наворотов, чтобы безопасный буфер обмена работал, чтобы это всё не тормозило и т.д.

Ну и концепция виртуализации для защиты раньше оценивалась скептически. Докажет ли Рутковская обратное — неизвестно.

Для безопасности API в ядре был выбран SELinux, другие альтернативы рассматривались (в том числе AppArmor):
http://lwn.net/Articles/181508/

Вот подробное описание^[link8] неполноценности ограничивающих моделей ACL по путям (AppArmor, etc).

Работа, которую привели выше^[link9] интересна тем, что на практике показывает, что реально используемые правила AppArmor немного безопаснее SELinux, но там рассматривается доступ, который злоумышленник может получить к дополнительным утилитам только определённым способом и не рассматриваются другие возможные способы.

Судя по количесту багов даже в правилах, поставляемых самими разработчикам SELinux, вполне возможно, что он хорош в теории, а на практике многое в плачевном состоянии.

Скорее малореально, полистайте пэдээфку к работе в конце страницы

Ну и концепция виртуализации для защиты раньше оценивалась скептически. Докажет ли Рутковская обратное — неизвестно.

Судя по количесту багов даже в правилах, поставляемых самими разработчикам SELinux, вполне возможно, что он хорош в теории, а на практике многое в плачевном состоянии.

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

А вы уже пробовали как-то работать хотя-бы с готовыми политиками? Про всякие тонкости с "domain transition" внятно себе представляете?

Пробовал, но познания у меня пока поверхностные на уровне SELinux User Guide от Федоры
http://docs.fedoraproject.org
Что такое "domain transition" знаю, про возможные тонкости – нет.
Спасибо за комментарии и ссылки.

завязан на закрытые проприетарные стандарты Intel

идёт упор поддержки виртуализации на аппаратном уровне от Intel для ёщё чего-то

как так получается, что Xen — полностью свободен и открыт, а Qubes, на нём основанный, жизненно требует каких-то "закрытых проприетарных стандартов"?

почему бы и нет – сделать на основе открытой вещи что-то специализированное

что можно сказать про аналогичные решения усиления безопасности для платформы FreeBSD?

Но хоть какая-то защита (по принципу — в плане защиты SELinux не делает хуже, он может сделать "лучше, чем ничего" или ничего не сделать).

Продолжение обсуждения от /comment52970^[link18]

чтобы и не глючил, и лишнее не позволялось

А что ему может позволяться? Боитесь, что потрёт файлы чужих программ, или тех, с которыми работает? Если среда враждебная до такой степени исключительности, а данные настолько критичны, запускайте его от отдельного юзера, где больше ничего нет, предварительно дав ему копию файла для чтения. Если боитесь local root, запустите виртуалке, где ничего кроме него нет. И даже это, пожалуй, будет сделать намного проще и надёжней, чем самопальные правила для SELinux, собранные на коленке.

В итоге толку от обоих может быть мало — один плохо настраивается и толком не работает, другой добавляет столь мало безопасности, что иногда больше создаёт её иллюзию. ☭^[link20]

Работа, которую привели выше интересна тем, что на практике показывает, что реально используемые правила AppArmor немного безопаснее SELinux, но там рассматривается доступ, который злоумышленник может получить к дополнительным утилитам только определённым способом и не рассматриваются другие возможные способы.

Судя по количесту багов даже в правилах, поставляемых самими разработчикам SELinux, вполне возможно, что он хорош в теории, а на практике многое в плачевном состоянии. ☭^[link21]

Всё зависит от степени параноидальности настроек. Но по большому счёту, да эти security-панцири не панацея, а не более чем костыль. ☭^[link22]

Сложность — в создании правил компактного описания разрешений/запретов из-за сложности самого ядра. ☭^[link23]

Only two remote holes in the default install, in a heck of a long time! ☭^[link24]

Что касается основного детища TdR, OpenBSD, в ней на local root сквозь пальцы смотрят

1. Безопасность критична только на серверах (десктопы пока не ломают, т.к. нет чёрного рынка малваре под Linux-десктопы в силу его малой распространённости — экономически невыгодно разрабатывать зловреды).
2. Доступ к шеллу имеют только доверенные лица, потому ломать они ничего не будут (на хостингах доступ либо в виртуалку, либо на dedicated server — ни то, ни другое не является ОС'ью, из которой ведётся админское управление всем хостингом). И даже если они захотят что-то ломать, они вряд ли надёжно сотрут логи, к тому же они обычно неанонимны. А раз так, опасность получить по шапке их должна остановить.
3. Зловредная прикладная программа, эксплуатирующая дыру вида local root — фантастика (с чем трудно не согласиться), и, опять же, считается, что такая программа имеет куда больший риск появиться на десктопе, чем не на сервере (далее см. пункт 1).
4. К времени на закрытие local root дыры относятся намного более спокойно, чем к закрытию remote-дыры. Боюсь наврать, но, кажется, могли исправлять несколько дней в некоторых open source ОС.

Кого будет волновать утечка серийников железа, MAC-адресов сетевых?

К времени на закрытие local root дыры относятся намного более спокойно, чем к закрытию remote-дыры

With NetBSD 5, which greatly improves disk I/O and network I/O performance over NetBSD 4, some guest Operating Systems running under Xen are known to operate faster than when installed natively on the same hardware without NetBSD and Xen behind the scenes. ☭^[link33]

Under Hyper-V hypervisor virtualization a program known as a hypervisor runs directly on the hardware of the host system in ring 0. The task of this hypervisor is to handle tasks such CPU and memory resource allocation for the virtual machines in addition to providing interfaces for higher level administration and monitoring tools.

Clearly, if the hypervisor is going to occupy ring 0 of the CPU, the kernels for any guest operating systems running on the system must run in less privileged CPU rings. Unfortunately, most operating system kernels are written explicitly to run in ring 0 for the simple reason that they need to perform tasks that are only available in that ring, such as the ability to execute privileged CPU instructions and directly manipulate memory. One solution to this problem is to modify the guest operating systems, replacing any privileged operations that will only run in ring 0 of the CPU with calls to the hypervisor (known as hypercalls). The hypervisor in turn performs the task on behalf of the guest system.

Это какой-то дешёвый гипервизор, раз он в ring 1

1 != -1
правда ring -1 у amd вроде только

Разве? Ну системные квоты же есть. Их можно заранее постестировать на эффективных fork-бомбах типа

если атаковать скажем по нагруженному запросу сервер( для удобства пусть будет запрос к БД), то либо БД займёт все ресурсы если на неё квот нет, либо она будет очень плохо работать когда ресурсы есть. Даже двухуровневые квоты не спасают, это основная проблема серверов openvz

Как же тогда хостинги живут в такой агрессивной среде? Любой клиент виртуалки может повесить весь хостинг?

Ну, наверное, на хостинге считают дыры в гипервизорах исключительным явлением?

Хотя unknown писал, что и к виртуалкам его прикручивают.

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

Для удобства рассматриваем XEN HVM.

А насколько сложно на практике поддерживать виртуализированную ОС в актуальном состоянии со всеми апдейтами и пр.?

Точно также, как обычную ОС на выделенном сервере

Сложность не только первоначальной установки/настройки, но и регулярного обновления/обслуживания используется как один из аргументов в пользу AppArmor/SELinux/etc.

AppArmor и SE не заметят такой виртуализации. Настройка гостевой ОС не требуется почти никогда( конечно ОС внезапно могут понадобиться какие нибудь железки, которые XEN не виртуализирует. Тогда будет плохо )

Если в системе есть какие-то стабильные сервисы, которые надо защищать в первую очередь (к сожалению, tor не очень стабилен, но проблемы с ним в SELinux разрулить оказалось несложно), то можно их обновлять, и если применять на пользовательской машине параллельные иксы или квазивиртуализацию LXC, то достаточно делать стандартным образом каждый раз только одно обновление для общей системы.

В данном вопросе ситуация с hvm равнозначна ситуации с несколькими физическими серверами. Т.е. если tor у нас на отдельной машине, то хватит одного обновления.

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

есть xenconsole и вообще у всех гостевых ОС есть устройство терминал и сетевая карта, которые может дёргать хост. Вопрос в том как передать правильные обновления гостевым ОС. Можно настроить NAT, чтобы гостевые системы могли обновляться. Тут конечно вопрос насколько надёжен NAT и система обновления, но это от виртуализации не зависит. Хоть на реально изолированных серверах будет тот же вопрос.

Я имел в виду, что звука на будет, например

Это что-то типа

В NetBSD по умолчанию у гостевых ОС нет ни доступа к терминалу, ни к сетевой карте

SELinux не может быть использован для блокирования проблемы, так как он делегирует qemu отправку ioctl для дисков, без привязки к отдельным разделам.

1.2. Why new OS?

Authors of this document do not believe that, at any time in the foreseeable future, we would be able to patch all the bugs in the software we use, as well as detect all the malicious software. Consequently we need a different approach to build secure systems.

Obviously building a new OS can be a very time consuming task. Thats why, with Qubes OS, we reuse as much ready-to-use building blocks as possible, in particular the Xen hypervisor. This in turn implies the use of virtualization technology, which is used for two primary reasons: offering excellent security isolation properties, as well as the ability to reuse the large amount of software, including most of the applications and drivers written for mainstream OSes, like Linux or Windows.

But still, all the other Qubes security mechanisms, such as AppVM separation, work as usual, and you still end up with a significantly secure OS, much more secure then Windows, Mac, or Linux, even if you don't have VT-d'''

Везде сейчас понавтыкали, что же ставить, debian?

Наивный подход к виртуалкам ведёт к ресурсоёмкости и затратности: при обновлениях системы нужно обновить каждую виртуалку. Как у неё это там автоматизировано — не знаю. Переходить на другую параллельно загружаемую ось для безопасной работы — это надоедливый дуалбут.

Что ещё неприятно с виртуалками — всевозможные /dev/(u)random для сильного противника в них превращаются в тыкву. Даже если подключить доверяемый аппаратный ГПСЧ, то нужен специальный демон-брокер энтропии, который корректно транслирует энтропию внутрь каждой виртуалки. Никто всерьёз это не воспринимает и не использует.

Интереснее подход с псевдовиртуалками (LXC). Сами по себе они не дают безопасности (рут в LXC = рут в системе и выход из псевдовиртуалки). Но для LXC уже сейчас есть специальные правила SELinux, которые исключают такую возможность, делая их допустимо безопасными. Стоит отметить, что проблема анонимности за счёт профилирования железа при этом не решается.

В будущем LXC планируется допилить до безопасного состояния, чтобы даже SELinux был не нужен. Это имеет не только перспективы для безопасности, но и коммерческого применения (хостинги на однотипных версиях ОС). И всяко больше шансов интеграции с обычной ОС.

Можно сделать одну систему, которая будет снапшотом для остальных, и все гостевые системы клонировать с этого доверенного снапшота (одного или нескольких).

1. Нужно повторять процедуру клонирования снэпшотов при каждом обновлении пакетов в системе, что бывает довольно часто при обновлениях безопасности. Вот включил комп, увидел, что надо обновиться и всё готово одной командой. А с виртуалками — это будет каждый раз морока. Скриптование не поможет: см. ниже.
2. В каждом склонированном снэпшоте может потребоваться применить разный профиль настроек. После клонирования их придёться накатывать заново. Скорее всего с разбором вручную. Эта проблема есть даже без виртуалок в TBB, поскольку он не идёт пакетом, его приходиться распаковывать и заново настраивать в разных анонимных профилях. Хватит гемора хотя бы только с ним, а не со всеми пакетами системы. А настройки могут быть разными. Где-то нельзя иметь закладок и сохранённых документов, а где-то наоборот — некритично и желательно для удобства. Ладно, когда это только один TBB. А когда много пакетов? При первом же признаке нехватки времени и усталости самого продвинутого пользователя — лень победит паранойю. Должен быть компромисс в сторону средней степени удобства. По принципу: хотя бы один раз помучаться с настройками, а затем всё работает.
3. В разных профилях могут быть не только одинаковые пакеты с разными настройками, но и может быть разный набор пакетов с разными настройками. Где-то нужен, например, GIMP или LaTeX, или Office, или ещё чего, и в каждом профиле свои настройки. Как это расклонировать, сохранять и накатывать настройки каждый раз?
4. Ресурсоёмкость. Даже один TBB в последних версиях тормозит на слабых ноутах. А если запустить несколько параллельно, да ещё в виртуалках, чтобы пока один чего-то качает, в другом смотреть другие сайты, не пересекаясь профилями? Плюс масса тяжеловесных повторяющихся пакетов для каждой виртуалки тупо занимает место.

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

На свете есть хоть один человек, который идеально знает ядро Linux, и потому у него не вызывает каких-либо проблем настройка SELinux под любую задачу? Вы писали, что, например, всё Debian-коммунити, вместе взятое, так и не осилило базовые патчи SELinux под последний релиз.

В конце концов, SELinux — это тоже программы, в них самих могут быть баги.

1. В нулевом доме нет ничего, кроме firewall'а и разруливания сети. Это сугубо административная система. Там даже иксы не факт, что должны быть (видеокарту можно пробросить в дом U?).
2. В домах U сидит всё: и анонимные профили и неанонимные. Не думаю, что под каждую софтину нужно выделять свой дом, скорее нужно расклассифицировать софт и задачи по группам, и каждой группе назначить свой дом. Как мне представляется, n-цать домов не наберётся, но, как минимум, нужны следующие дома:
   1. Дом без электрификации в тайге сети. Т.е. просто дом, в который можно прийти и поработать, где сеть не нужна. Ремонтировать обновлять его можно редко.
   2. Абсолютно анонимный дом. Обновления будут сравнительно частыми.
   3. Абсолютно неанонимный дом. Да, такое тоже бывает нужным.
   4. Частино анонимный дом.
   5. <ещё какие-то задачи>
3. Дома могут быть со снапшотами и без.
   1. Дом без сети можно вообще не обновлять.
   2. С абсолютно анонимным домом всё так, да: к нему хранится персональная чистая копия, по сути — вспомогательный дом. Чистую копию время от времени обновляем. Перед началом работы в доме его состояние каждый раз клонируется из чистой копии, т.е. из снапшота. Сохранение любой информации внутри дома возможно только на дополнительный виртуальный диск, информация из которого вычищается по окончании работы и перемещается в тот дом, который с сетью не работает вообще. Если для сеанса работы нужна какая-то уже имеющаяся информация, она предварительно вносится на виртуальный диск. Если такая информация нужна постоянно, её можно сделать частью снапшота (чистой копии). Можно реализовать и патчами к чистой копии, это зависит от задачи. Обычно требуется набор каких-то файлов. Заскриптовать команду cp -Rv не трудно.
   3. Абсолютно неанонимный дом можно обновлять как обычную ОС в реальном времени. Снапшота не будет, чистой копии тоже. Точнее, чистые копии должны быть для профилей конкретных пользователей, работающих в этом доме. Этого достаточно.
   4. Частично анонимный дом можно сделать по образцу B с какими-то поблажками. Или по образцу C с какими-то усилениями.
4. Пусть D делается так же, как B, тогда можно оценить сверху число нужных машин: A — 1, B — 2, C — 1, D — 2. Итого имеем 6 домов, из которых 2 вспомогательных. Число разных ОС: B, C и D должны иметь разные ОС; опционально для С и D можно использовать одну ОС, в крайнем случае. Остальные могут иметь ОС, совпадающие с какой-то (например, какая разница, что в A, если доступ в сеть дом А не имеет?). Итак, регулярно нужно обновлять где-то 3 разных ОС, из которых только 2 через вспомогательные чистые копии, а одну — напрямую без заморочек.
5. Там, где нужно клонирование снэпшотов или конкретных профилей, увы, этого не избежать, зато это даёт небывалую гибкость и защиту. Надо приучить себя к амнезии, т.е. не копить мусор. Всё, что важно, после работы переносить в статичную БД, остальное сносить. Всё браузерное, что работает с интернетом, должно иметь амнезию либо на уровне всего дома, либо на уровне конкретного пользователя.

Запрет доступа к программам хорош, когда те суидны. Если же не суидны, то вопрос надо ставить не о доступе к готовым программам, а о доступе к определённым библиотечным вызовам.

Например, dmesg не суиден. Кто такому пользователю запретит написать собственный dmesg, скомпилить его сорсы и запустить?

Циммерманн не был акционером

А кто утверждал, что он был акционером? Вы о чем-то о своём…

That company was acquired by Network Associates (NAI) in December 1997, and Zimmermann stayed on for three years as a Senior Fellow.

Он по умолчанию почти везде отключен и реально крайне мало где используется. Стоило тратить столько сил на попытки с помощью него что-то протроянить или скомпрометировать. Выбрали бы что-нибудь более популярное.

Microsoft, Google, IBM, Intel^[link58] написали куда больше кода в Linux-ядро, чем подрядчики АНБ. А типа никому неподконтрольные энтузиасты-одиночки^[link59], на которых якобы держится Open Source — аж 16% кода. Linux — это больше продукт крупных коммерческих, подконтрольных корпораций.

Во первых, всегда можно выключить. И оно не сработает.
Во вторых, эксплойт или закладка в SELinux должна сделать минимум три вещи:

1. Дать выполнить произвольный код.
2. Получить привилегии рута.
3. Обойти защиту SELinux, опять же тремя, как минимум путями: полным отключением SELinux; повышением привилегии из под связанного до несвязанного (unconfined) пользователя; возможностью сделать что-то вредное даже будучи в связанном (confined) состоянии.

Технически, если первые два пункта решаются обычным набором эксплойтов, то третий пункт означает просто такую же ситуацию, как и отсутствие SELinux. Если включенный SELinux даёт возможность осуществить все три пункта так, что при выключенном такой возможности нет, то это очень заметно и злонамеренно выглядит. Наконец, с третьим пунктом и всеми его тремя подпунктами тоже довольно сложно и ограниченно. Явный переход confined → unconfined нигде не предусмотрен, ухитриться сделать безобидно выглядящую ошибку для него, да ещё связанную со всеми тремя пунктами — сложно.

Понятно, что злонамеренность АНБ может помножить всё на бесконечность, но хотелось бы технические соображения по этому поводу. Иначе, из таких же соображений можно всё отпараноить: GnuPG финансируется немецкими властями, Tor (и значительная часть исследований в области Crypto) — американскими. А шифрпанки и энтузиасты, когда дело касается безопасности, часто пишут такой код, что никаких троянов не надо. Реально, только если есть продукт смешанного открытого коммунити.

… IBM, … написали куда больше кода в Linux-ядро, чем подрядчики АНБ. А типа никому неподконтрольные энтузиасты-одиночки, на которых якобы держится Open Source — аж 16% кода. Linux — это больше продукт крупных коммерческих, подконтрольных корпораций.

Для данной темы, это оффтоп, поэтому вкратце.

Компании под одним названием с энтузиастом-одиночкой Ф.Циммерманном и без него – две разные компании. Становиться ли энтузиасту-одиночке юридическим лицом – это вообще формальность.
Многодесятилетнего ресурса железячных компаний, как IBM, хватает, чтобы успешно вести патентные войны. Их достижения на софтверном рынке сомнительны. Зачем поддерживать опенсорсный Linux, когда есть своя OC(?)

тестерТьюринга, ставь BSD.

Пока заинтересовали исследовательские операционки. Такие, как http://www.coyotos.org/history/index.html

Our research goal is to produce the first open source system with an ``open proofs'' trail and the tools necessary to allow a third party to independently verify our results.

ухитриться сделать безобидно выглядящую ошибку

да ещё связанную со всеми тремя пунктами — сложно.

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

GnuPG финансируется немецкими властями, Tor (и значительная часть исследований в области Crypto) — американскими.

3.3. Securing the hypervisor

Formal security proofs?

It would be nice if it was possible to formally prove correctness of the hypervisor code. Unfortunately this doesnt seem to be feasible for software that interacts with commodity PC hardware (x86 architecture). Particularly in order to prove correctness of the hypervisor, it seems like one would first need to have complete models of all the hardware that the hypervisor can interact with, including e.g. the CPU and the chipset (MCH), which seems highly nontrivial to create.

For instance, the recently published paper on formally proving the correctness of well known seL4 microkernel,⁷ explicitly states that only the ARM port (and only for non-SMP systems) has been proven, while the x86 port is still left to be formally verified in the future. More over, the paper states that e.g. the memory management has been pushed of out of the microkernel to the usermode process, and that this process has not be contained within the proof. They admit, however, that this process is part of the TCB, and so eventually would have to also be proved. One can easily imagine that in case of a general purpose OS, based on such a microkernel, there would be more usermode processes that would also be part of the TCB and hence would have to be formally proved, e.g. the filesystem server.

In case of the x86 hardware, one would also assure that the drivers cannot program devices to issue malicious DMA transactions that could potentially compromise the microkernel or other parts of the system. This would require the microkernel to support programming of the IOMMU/VT-d, as otherwise one would need to prove correctness of every single driver, which is unfeasible in reality. However, addition of IOMMU/VT-d support to the seL4 microkernel might likely result in rendering the formal proving much more difficult.

Additionally certain peculiarities of the x86 platform, like the SMM mode, might also be difficult to account for⁸.

Thus, we dont expect any bare-metal hypervisor or microkernel for commodity x86 PC hardware to be formally proved secure anytime in the near future. Consequently other, more pragmatic, approaches are needed in order to secure the hypervisor. The best approach we can think of is the manual audit of the hypervisor code and to keep the hypervisor as small and simple as possible. Additionally one might apply some anti-exploitation mechanisms, like e.g. non-executable memory.

In the future, when formally proved hypervisors become a reality, there is no reason why Qubes should not switch to such a hypervisor. Particularly, the rest of the architecture proposed in this document (secure GU, secure storage domain, etc) would still be required even if the system used formally verified hypervisor.

В меру своих познаний в этом вопросе тоже пытался его провентилировать. Узнал только то, что инженер по имени 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:
Понятно, что злонамеренность АНБ может помножить всё на бесконечность, но хотелось бы технические соображения по этому поводу.

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

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

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

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

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

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

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

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

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

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

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

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

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

Негласное правило обычно таково — лучше не очень хороший, но стабильный код от проверенного и известного человека или организации, чем очень хороший, но неизвестно от кого. При любом раскладе анонимам дают только второстепенную роль, а ведут проект люди с именем и репутацией.

I am so glad I resisted pressure from Intel engineers to let /dev/random rely only on the RDRAND instruction... Relying solely on the hardware random number generator which is using an implementation sealed inside a chip which is impossible to audit is a BAD idea.

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

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

фейспалм

Linus:
У меня был компилятор и интерпретатор языка Форт, с которыми я и возился. Форт — это очень странный язык; сейчас им уже никто не пользуется. Эта игрушка, рассчитанная на определенную рыночную нишу, в 80-е годы довольно широко использовалась для разных целей, но по-настоящему популярной так и не стала, потому что оказалась слишком сложной для непрофессионалов.

Папа, давай остановимся и купим шоколадное мороженое! Хочу мороженое!
Нет, дочка. Придется подождать. Вот остановимся пописать — тогда купим мороженое.
Попробую объяснить на примерах. Самый очевидный пример — секс.

Просто у меня большие передние зубы — посмотришь на мои детские фотографии, и на ум невольно приходят бобры.

финские мужчины самые плодовитые в Европе.

Жулики — первые, кто легко меняет вывеску.

Самые критичные уязвимости выглядят случайными ошибками. Чем больше разработчик делает, тем больше у него шансов фатально накосячить при прочих равных. Получится, что изгонять надо всех.

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

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

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

*У Кэти Топурии есть замечательная пестня, там такие строки: красота — среди бегущих первых нет и отстающих, бег на месте общепримеряющий!

*У Кэти Топурии

Адриан Аникушин | 2013-08-05 в 20:16:46
SELinux – Долой SELinux! Это дыра для контроля моих данных якобы позволяющая гибкое обращение к файловой системе программ.. Происки Микрософт и ЦРУ! Долой SELinux! Нет империализации моего оборудования!Вы что не видите!!!! Гавно!

Вот, сегодня опят наткнулся на очередной возглас недовольного параноика

https://www.pgpru.com/comment38599

Для безопасности API в ядре был выбран SELinux, другие альтернативы рассматривались (в том числе AppArmor):
http://lwn.net/Articles/181508/

Вот подробное описание неполноценности ограничивающих моделей ACL по путям (AppArmor, etc).

Работа, которую привели выше интересна тем, что на практике показывает, что реально используемые правила AppArmor немного безопаснее SELinux, но там рассматривается доступ, который злоумышленник может получить к дополнительным утилитам только определённым способом и не рассматриваются другие возможные способы.

Увидел мнение в сети:

The only thing SELinux has over apparmor is greater flexibility (for example
policies involving restricting pipes and IPC signals). When it comes to simple
filesystem-based permission or denial, apparmor and selinux are the same. And
actually apparmor may be slightly more secure due to it being simpler and not
having so many features. So when the intention is to just prevent tor browser
from accessing files it does not need (like /sys) then apparmor is totally
sufficient.

With the apparmor enabled they cannot read your dmesg (/var/log access is
blocked of course). And so is /dev/log. Even if tor browser did have a vuln, and
a root exploit was discovered, then apparmor would STILL prevent dmesg access.
And they cannot see the pci devices either. Those are present in /sys which is
heavily restricted by apparmor.

Это правда? Tails полагается на apparmor^[link78]