Он же тролль, а ты ведешься.

Если ты уж занялся LSM-реализациями, то не мог бы ты посмотреть, не может ли:

SELinux работать вместе с grsecurity (включая MAC).

На гентушной вики о hardened написано, что может.

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

Но зачем? Virtualbox/VMware + Unity (проброс окон гостя в хост).

Позвольте, но вы так же неаргументированно выдвигаете свои тезисы о святости скайпа.

Ты сам то hardened пробовал? Для SELinux нет ни одной вменяемой политики. Refpolicy - 3.14здец и наркомания. Ну и именно что MAC (a не MC в общем и целом) кажется вообще нигде нормально не работает из коробки.

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

Для SELinux нет ни одной вменяемой политики

А те, что в дереве?

Это все рефполиси. Её патчат под дистры, а потом вливают в апстрим, разумеется

Только на сервере. А что тебе не нравится? У SELinux'а есть обучалка, можешь всё поставить, отключить энфорсинг-режим, выгрузить всё ПО (которое можно), перейти в режим логирования, запустить ПО, поработать, audit2allow, применяем политики, включаем энфорсинг. Реф политики конечно хуже, чем в федоре, но для конкретного приложения тебе никто не мешает из федоры выдрать, только может понадобиться пути изменить.

Очень хочется на десктоп, но не хочется трахаться. :(

audit2allow

Это безумие. Лучше его сразу выключить, что-бы не питать ложных иллюзий, в таком случае

На гентушной вики о hardened написано, что может.

Но зачем? Virtualbox/VMware + Unity (проброс окон гостя в хост).

SPIE куда лучше. Только для защиты каждого приложения придется иметь отдельную виртуалку - это уже накладко, также они до сих пор не могут seamless-интеграгию (как unity, seamless-rdp или X11), производительность там тоже так себе. Тем более, что (на hardened gentoo, если не использовать скайп и прочую бинарщину) взлом системы и так маловероятен. Что касается скайпа - я его держу в отдельной виртуалке (на другой машине, правда) и через ssh-X11 запускаю, звуковое устройство он получает подключением удаленного pulse. Я не вижу смысла трахаться и извращаться с MAC только ради одного него, это несет тонны костылей, не даёт возможность при включенном скайпе отключить защиту, мало того, никто не гарантирует, что твои политики полностью верно записаны и блокируется всё, что действительно надо.

Ну ты же будешь просматривать генерируемые им политики, верно? :)
Не вижу в нём ничего плохого, если ты понимаешь, что ты делаешь, и что он делает.

Не вижу в нём ничего плохого, если ты понимаешь, что ты делаешь, и что он делает.

Ну. Я то как раз понимаю что он делает. И чего он не делает. 95% ошибок в политике - отсутствие переходов и доменов. Разумеется audit2allow не экстрасенс, и их не выводит. Получается пипец.

Ну ты же будешь просматривать генерируемые им политики

Генерируемые им костыли просто бесполезны

SPIE

wtf SPIE? spice может быть?

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

SPICE, а не SPIE, действительно. Прошу прощения на точность, сам никогда не юзал, поэтому исказил название.

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

Вы абсолютно не правы.
1. LSM нужна для ограничения userspace-кусков Xen/KVM в случае взлома.
2. LSM нужна для разграничения доступа сервисов в самой системе. Как бы Вы не старались, Вы не не сможете вынести в контейнер всё ПО (потому что есть не только прикладное, но и системное ПО, включая ssh). Его тоже нужно ограничивать, особенно, если оно имеет доступ к сети.
3. В случае десктопа держать кучу chroot'ов (паравиртуализация (не Xen pv), это же по-сути расширенная технология chroot'а) с единым home - это весьма странное занятие. Особенно, учитывая необходимость единого dbus, проброса X11, pulse. В случае с Xen pv нужна будет ещё и NFS.
4. На серверах общего пользования куда выгоднее иметь SELinux, чем контейнеры.
5. Придумайте сами.

Ну и плюс накладные расходы.

1. LSM нужна для ограничения userspace-кусков Xen/KVM в случае взлома.

Этот тезис мне не понятен

2. LSM нужна для разграничения доступа сервисов в самой системе. Как бы Вы не старались, Вы не не сможете вынести в контейнер всё ПО (потому что есть не только прикладное, но и системное ПО, включая ssh). Его тоже нужно ограничивать, особенно, если оно имеет доступ к сети.
4. На серверах общего пользования куда выгоднее иметь SELinux, чем контейнеры.

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

Следующий поинт. В рамках домена информация циркулирует относительно свободно. Следовательно компрометация участка домена обычно приводит к компрометации циркулирующей информации. Что это значит по факту. Если у вас будет скомпрометирован ssh, SELinux возможно спасет вас от персистентного бекдора, но не от утечки. В подавляющем большинстве случаев цель атаки - именно компрометация чего-нибудь. Плюс, в век web безумия SELinux вообще теряет всякую актуальность - управление доступом выносится в юзерспейс в логику ПО.

3. В случае десктопа держать кучу chroot'ов (паравиртуализация (не Xen pv), это же по-сути расширенная технология chroot'а) с единым home - это весьма странное занятие. Особенно, учитывая необходимость единого dbus, проброса X11, pulse. В случае с Xen pv нужна будет ещё и NFS.

В случае десктопа для LSM нужно нормальное решение и нормальный аудит/исследования - слишком много векторов атаки. Возможно решение для обычного DAC — запуск приложений под разными пользователями, и ACL на файлы в хомяке — будет практически достаточным. Не представляю, как избыточно централизованной политикой описать динамически изменяющуюся среду

1. Прочитайте уже про KVM sVirt и Xen XSM.
2,4. Вопрос очевидный в случае предоставления нормальных референсных политик из коробки.
В случае генты это не совсем так, но у всех потомков RHEL - так. Не вижу проблем в системе безопасности, которая не особо трахает мозг админу или юзеру, но даёт увеличенную безопасность.
В случае взлома ssh (эксплойт переполнения памяти или иной магии с памятью hardened gentoo не сработает, вопрос только в ключах получается) будут получены весьма большие права даже в случае SELinux'а (если мне не изменяет память, то он может напрямую форкануть даже процесс с uid 0, если это не запрещено политикой, обычных юзеров уж точно.). Но это не является эксплойтом, поскольку утечка была ключей или паролей (как я сказал выше, эксплойты с памятью в HG не катят). Это уже вопрос разграничения прав клиентов и политик ИБ систем клиентов.
Если у Вас куча всякого анонимного сброда имеет ssh-доступ к машине, то я не буду спорить что (пара)виртуализация лучше.
В век веб-безумия проблемы аудита систем и их безопасности ещё как важны. Особенно это касается хостеров, которые, внезапно, не запускается по openvz-виртуалки на каждого своего нищеклиента. Но там более важны такие инструменты, как greensql, mod_secure и их аналоги из-за особенности безопасности интерпретируемого кода.
3. Вы не правы. Кроме доступа к файлам другого юзера у есть ещё куча других векторов атак, особенно, это касается параноидальной конфиденциальности и локальных эксплойтов (кстати, под HG большая часть тоже не заработает).

1. Почитаю, спасибо

Я согласен с тем, что больше безопасности лучше чем меньше, особенно если это бесплатно — с этим вообще глупо не соглашаться. Просто попробуйте нарисовать модель угроз для веб сервисов/десктопа, и в соответствии с ней настроить SELinux для этих кейсов

Virtualization does not increase security (despite marketing) [1] © PaX Team

[1] PaXTeam-SSTIC12-keynote-20-years-of-PaX.pdf

В случае отсутствия PaX, PIE, SSP (насколько я помню, большинство приложений в RHEL, CentOS, Fedora скомпилины только с NX, лишь некоторые с PIE и SSP) практические все приложения, которые либо работают с Интернетом, либо с внешними (полученными за пределами системы) файлами могут быть подвержены взлому (через любимые хакерами уязвимости стеков, буферов, и прочих ошибок при работе с памятью). Далее очевидные из этого кейсы:
1. Взлом IM. Хотя злоумышленник получит доступ к логам, логинам и паролям пользователя, мы не должны дать ему вырваться дальше. Следовательно, кроме папки с настройками и логами IM доступ с иные папки юзера (и в часть папок системы) должен быть запрещен.
2. Взлом браузера. Аналогично IM, но нужно дать возможность доступа к downloads, а также к папке files-to-upload в ro-режиме.
3. Взлом просмоторщика pdf/текстового редактора и т.д. Тут сложнее, т.к. распихивать по отдельным папкам каждые документы не очень удобно. Но можно разрешить доступ к файлам поддерживаемых форматов в downloads и documents в папке юзера. Единственное, я не знаю, насколько SELinux поддерживает маски файлов.
И т.д.
В случае hardened gentoo на десктопе взлом может произойти только со стороны интерпретируемого кода, причём только в случае, если проблема не будет связана с магией в памяти, а сам интерпретатор будет кривым. В итоге, даже в HG имеет те же кейсы, что и без неё, но только для программ, где внешние данные проходят через интерпретатор (точно браузер, возможно почтовик и IM (если от mozilla).

В случае сервера с веб-сервисами тоже простой кейс:
У нас веб-хостинг с apache+fgci-php, mysql, memcached, nginx. Достаточно стандартное решение. Мы хостим кучу клиентов, не хотим потерять лицо. Далее проблема ухудшается тем, что мы для поддержки SFTP предоставляем юзерам урезанный SSH (причём тот же, что мы сами используем, а не отдельный головной процесс на отдельном порте), FTP, а многие юзеры держат несколько проектов.
В результате получается проблема в случае использования DAC. Юзеры могут (и будут) выставлять 777 на файлы, терять пароли, пароли будут красть и юзать всякие хакеры, т.к. наши юзеры сидят под сраными виндами и юзают крякнутые дримвиверы с троянцами.
А ещё, периодически, т.к. мы юзаем энтерпрайзовый дистрибутив, а не поделку каких-то ничего не смыслящих в безопасности тупых красноглазиков, у нас будут взломы из-за плановых уязвимостей касающихся памяти всего вышеперечисленного софта. Поэтому мы должны динамически запускать процессы на юзера с нужными политиками, давать юзеру со стороны ssh доступ сразу ко всем его проектам, хотя для апача и php они разделены, nginx и memcached ссаными тряпками гнать от юзерских файлов и т.д. Ну и плюс всякие прелести, типа запрета исходящих соединений, биндинга к ненужным портам, аудит (Вы без MAC'а всё-равно не сможете нормальный аудит-лог вести, т.к. всё-равно нужно будет включать MAC, только в режиме логирования, а в режиме защиты). И ещё у нас будут (даже на HG) проблемы с php и mysql, т.к., как мы помним, HG спасёт нас только от уязвимостей связанных с памятью, но не с интерпретаторами. Про greensql proxy, mod_secure и подобные решения мы ничего не слышали, поэтому нам придётся спасаться ещё и от наплыва хакеров, которые через юзерские дырки могут начать влиять не только на их говнождумлу и решето-вордпресс, но и на нашу няшненьку систему, либо на файлы юзеров, не понимающих сути 777 и 755 (для того, что пароли увести и прочую инфу).


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

Я не совсем понимаю, почему Вы насколько противитесь мысли о том, что вокруг нас (и особенно публичных серверов) есть реальные проблемы безопасности. Или Вы считаете, что раз Ваши данные стоят меньше, чем железо, а простой вообще ничего не стоит, которое их обрабатывает и хранит, то и у других такие же расценки? Или Вы считаете, что «вероятность мала»? Смею Вас огорчить: сейчас это - форма заработка. И меня и моих знакомых линуксоидов часто сканируют откуда-то из сети, хотя никаких ресурсов публичных на нас не крутится, причём даже на ssh подбирают пароли. Про документики для MS Office, которые эксплуатируют дырки - я вообще молчу. А эксплойты для флеша и браузера расходятся у хакеров для их ресурсов или говнорекламы как горячие пирожки, т.к. они принесут им в разы больше денег.

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

Вставлю пять копеек - как-то писал многопоточную чекалку проксей just4fun, и удивился, насколько легко за вменяемые сроки просканировать весь Интернет IPv4 по определённому простому сценарию (в данном случае - обнаружение открытых проксей и их анализ на анонимность) даже с помощью одного компа. Но это всё было давно, и не правда, и вообще плод больного воображения.

А если сюда добавить десятки и сотни тысяч ботов по всему миру?

А если сюда добавить десятки и сотни тысяч ботов по всему миру?

после такого сканирования-если тебя не забанит провейдер,забанит магистральный провайдер.(в 99% случаев выдается бан от провайдера в считанные минуты,ты еще даже не начнешь).Как бан выглядит-там простой сценарий,первые раз 10 просто разрыв соединения и слип xx минут/секунд,дальше выдача ИП с блокированными портами,далее фильтр трафика,если это не помогает-тут уже на пару дней инет будут рубать,или вообще отключат.

Поэтому логичнее разбить интернет на зоны которые разделить по компам из ботнета.Т.е. когда ты с одного ИП конектишся к половине ИП мира-бан 100%,а когда с одного ИП к паре десятков ИП-это нормально.

И да-иметь ботнет сегодня-дело пяти минут,фактически ботнет можно сделать за 1 день,не имея ни веб сайта,вообще ничего не оплачивая и не покупая.Порядка 100 машин за день любой дурак может подключить.

Ах да-особенно весело с ботнетами на андроидах и айфонах.

Welcome to alpine linux.

Я не совсем понимаю, почему Вы насколько противитесь мысли о том, что вокруг нас (и особенно публичных серверов) есть реальные проблемы безопасности

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

Welcome to Hardened Gentoo.

Не нужно.

Если это (ИБ) - Ваша работа (важная её часть), тогда Вы точно понимаете, почему на Ваших серверах крутится HG, а не что-то иное :) А хождение вокруг до около виртуализации - это позерство, а не ИБ.

Можете пересесть на уютненькую восьмерочку, если Вам ИБ «не нужно».

man EMET
man SRP
man AppLocker

но есть вещи, аналоги которых есть только в.

TL;DR: Intel implements UDEREF equivalent 6 years after PaX, PaX will make use of it on amd64 for improved performance. [1]

[1] http://forums.grsecurity.net/viewtopic.php?f=7&t=3046

Забабахал отдельный раздел на Скайповой страничке в арчевики. Пользуйтесь.

профиль apparmor для skype выглядит поломанным.

Пофиксь, если можешь. Я AppArmor'ом не занимался и на арчевики его не описывал.

Won't Fix

As for 'mmap', the way skype is compiled means it requires an executable stack (see 'execstack /usr/bin/skype'), which is far from ideal. When a binary has an executable stack, it gets READ_IMPLIES_EXEC, which is why mmap is showing up. While the best solution would be to recompile skype to not require an executable stack, unfortunately this cannot be done since this is proprietary code.

http://paste.ubuntu.com/1385471/

И что мне с этим делать :)?

поправить профиль в wiki?

p.s. as you can see, I use microsoft ® windows ® 8 ™

поправить профиль в wiki?

А сам не? Я не могу его опробовать, поэтому лучше ты.

p.s. as you can see, I use microsoft ® windows ® 8 ™

Не вижу.