id: Гость   вход   регистрация
текущее время 14:09 29/03/2024
Автор темы: unknown, тема открыта 11/04/2010 21:58 Печать
https://www.pgpru.com/Форум/UnixLike/SELinuxAppArmorИДрСистемыБезопасности
создать
просмотр
ссылки

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


Цитата с другой ветки, обсуждение перенесено сюда в отдельно созданную тему.

> Но безопасность в контексте браузера это фантастика, на сегодняшний день.
SELinux по идее должен защищать пользовательское пространство от уязвимостей в приложениях. Правда я пока не освоил эту технику. Может кто из знающих людей покажет пример? Предположим, нужно изолировать браузер Firefox

Вот пример создания политики для гуглохрома:


http://danwalsh.livejournal.com/32759.html


Или пример использования киоск-режима:


http://danwalsh.livejournal.com/11913.html


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


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


По SELinux практически нет ни манов ни доков, только книжки, разрозненные описания в расчёте на опору поддержки дистростроителями готовых политик (что хорошо делается только в Федоре).


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 След.
Комментарии
— Гость (21/08/2013 13:34)   <#>
Если учитывать менталитет спецслужб, доверять их программным продуктам категорически нельзя. Их сознание отформатировано так, чтобы использовать абсолютно любую лазейку для сбора информации и вторжения в частную жизнь. Это для нас подобные действия преступны, а для них это – спецоперация, которая рассматривается как ступень в карьерной лестнице. Скорее всего сделаны оценки – сложность кода такова, что ни у кого без таких ресурсов как у АНБ не будет возможности в нём до конца разобраться. Экплойты можно замаскировать в виде багов, и случае их маловероятного обнаружения репутация selinuxa не пострадает. Все риски и возможные издержки подсчитаны, нужные люди находятся под влиянием. Возможно что selinux в редакции gnu (не для внутреннего использования АНБ) – это проект для компрометации свободного ПО, внедрение глобального трояна в неподконтрольные средства коммуникации. Лучше отдать предпочтение другим продуктам типа grsecurity, которые к тому же проще в настройке.
— unknown (21/08/2013 15:24, исправлен 21/08/2013 15:26)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


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

— тестерТьюринга (21/08/2013 20:04)   профиль/связь   <#>
комментариев: 301   документов: 8   редакций: 4
Red Hat – крупная корпорация. Кстати(не кстати), тоже подрядчик АНБ, получается. Fedora давно использует SElinux по умолчанию. Когда долгое время вкладываешься в изучение и применение дистра, то перейти на другой продукт не легкая психологическая задача. Даже если на том же дистре с другой системой безопасности. Весь дистрибутив скомпрометирован.
— Гость (22/08/2013 02:06)   <#>

тестерТьюринга, ставь ФСБ BSD.
— unknown (22/08/2013 09:56, исправлен 22/08/2013 09:58)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


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

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


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

— тестерТьюринга (22/08/2013 09:58, исправлен 22/08/2013 10:04)   профиль/связь   <#>
комментариев: 301   документов: 8   редакций: 4
… 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.

— тестерТьюринга (22/08/2013 10:12)   профиль/связь   <#>
комментариев: 301   документов: 8   редакций: 4
ухитриться сделать безобидно выглядящую ошибку

Конкурс http://underhanded.xcott.com/
да ещё связанную со всеми тремя пунктами — сложно.

Да :)
— Гость (22/08/2013 22:57)   <#>
ухитриться сделать безобидно выглядящую ошибку для него, да ещё связанную со всеми тремя пунктами — сложно.

Вполне вероятно, что для решения таких задач создана научная база. А сложно или нет – понятие относительное, зависит от возможностей.

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

Размеры этих проектов несопоставимы с selinux, а разработчики не связаны обязательствами неразглашения. Т.е. код намного проще для проверки, а риск утечки компрометирующей информации значительно выше. Да и понятие "власть" в данном случае расплывчато, какой-нибудь фонд раздающий гранты из бюджета – это тоже власть что ли?
— Гость (23/08/2013 00:40)   <#>

Стр. 13 зде упомянутой pdf'ки:

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,7 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 for8.

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.
— unknown (23/08/2013 09:45)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
АНБ формально почти устранилось от разработки SELinux, передав его разным компаниям. Рассылки и исходники больше не хостятся у него на серверах, а лежат у Трезиса. На странице агентства только историческая справка о начале разработки и нет никаких актуальных материалов.

Это, разумеется, никак не успокаивает паранойю, т.к. несколько официальных разработчиков от АНБ остались в проекте, да и формальная смена вывески ничего не значит в плане возможного контроля. Другой вопрос, что альтернативные "независимые" проекты также могут разрабатываться подконтрольными компаниями.
— тестерТьюринга (23/08/2013 10:12)   профиль/связь   <#>
комментариев: 301   документов: 8   редакций: 4
Microsoft в своих подпроектах Singularity внедряет формальную систему для доказательства корректности программ на уровне языка.
http://research.microsoft.com/apps/pubs/?id=122884

Это устраняет широкий круг уязвимостей, но, понятно, что проблема не перестает быть сложной.
— Гость (23/08/2013 12:10)   <#>

Вспоминается странная история становления Microsoft, которую на начальных этапах IBM почему-то поддерживала в ущерб себе. Есть мнение, что об этом её очень попросили...
— тестерТьюринга (23/08/2013 13:07)   профиль/связь   <#>
комментариев: 301   документов: 8   редакций: 4
Да, ксати о M$: http://www.heise.de/tp/artikel/5/5263/1.html
Wine – самая надежная Винда? :D
— Гость (25/08/2013 21:48)   <#>

Описание в английской статье какое-то сумбурное. Непонятно, о чем конкретно идёт речь. IMHO, это обычные спекуляции, "жареные новости".

NSA backdoor в криптографии если и был, то ровно один раз — в стандарте DUAL_EC_DBRG, который впервые применен в Windows 7. Это стандарт на ГПСЧ, принятый NIST. Там случайные числа генерируются хитрой эллиптикой, и доказано, что теоретически может существовать секретная эллиптическая кривая, позволяющая полностью скомпрометировать этот генератор (есть ли такая кривая в их константах — вопрос, но опасения имеются). Стандарт пропихнули с подачи NSA без обсуждения, в win7 он есть в числе прочих стандартных алгоритмов. Вероятность, что всё случайно так вышло, и никакой секретной кривой у них в загашниках нет, стремится к нулю не велика. IMHO, сама идея генерировать случайные числа, используя ассиммитричное крипто, порочна на корню и должна вызывать подозрение.
— unknown (25/08/2013 23:15)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Да ну? BBS вполне себе классичен.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3