Доступен выпуск Linux-дистрибутива Bottlerocket 1.1.0, развиваемого при участии компании Amazon для эффективного и безопасного запуска изолированных контейнеров. Инструментарий и управляющие компоненты дистрибутива написаны на языке Rust и распространяются под лицензиями MIT и Apache 2.0. Поддерживается запуск Bottlerocket в кластерах Amazon ECS и AWS EKS Kubernetes, а также создание произвольных сборок и редакций, допускающих применение различных инструментов оркестровки и runtime для контейнеров...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55109
О-о-ох.
Ехал контейнер в контейнере через атомарный образ
Видит контейнер в контейнере контейнер
Сунул контейнер запрос в контейнер
Контейнер контейнер контейнер контейнер
Когда компьютеры в Россию только начали завозить, примерно такие же частушки про них складывали.
Все будет через "компутэры", ха-ха-ха.
Ты сильный "программист"? - Да! - Иди грузи ящики! (Смех в зале)... примерно из той же "оперы" анекдоды про "новых русских" (если кто помнит еще).
... покупать жидкое мыло, полезное для кожи, за 300р., когда можно купить кусок за 20р. Ха-ха-ха - зачем нужна шелковистая кожа, когда з/п месяцами задерживают!
... и вообще, репертуар поздних Петросяна и Задорного.Т.е. понятно что это будет примерно так. Только кому-то это кажется смешным.
Всё понятно, только причём тут "новые русские"? Если память не подводит, они были поводом для насмешек из-за своей быдловатости, тупости, и безвкусицы; персонажи, которые всякими, зачастую - нелегальными и нечестными способами разбогатели?
> Всё понятно, только причём тут "новые русские"?Типичное "все понятно, только...", только отсутствие абстрактного мышления чуть менее, чем полностью.
> Если память не подводит, они были поводом для насмешек из-за своей быдловатости, тупости, и безвкусицы; персонажи, которые всякими, зачастую - нелегальными и нечестными способами разбогатели?
Память подводит, поскольку стыдно помнить, что под эту гребенку равняли всех, кто чем-то отличался, и у кого было больше денег (часто как раз таки благодаря их талантам и способностям, что и вызывало усиленную зависть).
Также здесь многих память упорно подводит, что "быдловато", "тупо" и "безвкусно" неординарные личности обычно ведут себя не потому что они такие, а лишь индивидуально с теми, кто этого "заслуживает",
лишь "зеркаля" последних, дабы "не метать бисер перед...".Это, представляете, сколько талантливых, культурных и способных людей все это время вели себя с вами "быдловато", "тупо" и "безвкусно",
а вы все это время так и не догадались, что без вас все происходит совсем иначе.
Ставить диагноз по комментарию, это тоже как бы наводит на мысльВы слышали о таком понятии как "нувориш"? Вы приравнили "новых русских" к теми, кто умел зарабатывать деньги, углубитесь в тему-то хоть. У меня один дядька в 90ых неплохо крутился, развозил продукты по региону, деньги зарабатывал коробками, но "новым русским" он не был
Ник-то какой! "Dzen Python"!
Да он же Дзен врурил! Он же реально в теме!
Он же хеллоуворлд на Питоне смог!... очень приятно, Царь! (С)
Забудте про производительность.
Почему? Там же нет никакой виртуализации, только namespaces и cgroups.
Тормозит примерно как chroot или jail (то есть, никак).
с каких пор изоляция на уровне cgroups стала бесплатной?
Естественно что она меньше потребляет ресурсов чем kvm/xen/Hyper-v но она не бесплатна.
Что там с изоляцией сетевой подсистемы?
С каких пор механизм ограничения потребления ресурсов стал механизмом изоляции?А так да, если для контейнера проц, память и blkio через cgroups ограничить, то для контейнера они будут ограничены, вот так неожиданность!
> С каких пор механизм ограничения потребления ресурсов стал механизмом изоляции?То виндовое (или таки бсдшное? или оба?!) ламо не в курсе и потому путает.
А что до изоляции namespaces, то оверхед от нее наверное в теории есть, но на практике он маргинальный и к тому же половину этого ядро и раньше умело по другим поводам, с этим своим clone() и проч.
>> С каких пор механизм ограничения потребления ресурсов стал механизмом изоляции?
> То виндовое (или таки бсдшное? или оба?!) ламо не в курсе и потому путает.А точно ламо он, а не надувающие щечки пингвинятки и прочие 294-е?
https://www.kernel.org/doc/Documentation/cgroup-v1/devices.txt
---
> An entry is added using devices.allow, and removed using
> devices.deny. For instance
>
> echo 'c 1:3 mr' > /sys/fs/cgroup/1/devices.allow
> allows cgroup 1 to read and mknod the device usually known as /dev/null.
вброс наугад, не в теме даже, авось кого зацепит
Не про опроизводительность, а про оперативу. Ну вот пусть Амазон сам свою жрущую поделку юзает и клиентам втюхивает.
"Мелко и пошло" (c)
надо что-то вроде (Function aaS):
std::atomic++ в одном контейнере
std::atomic-- в другом контейнере
Уже придумали. Называется "микросервисная архитектура". Именно так - каждое приложение выполняет только одну функцию и имеет стандартный API.Но это для хипстоты, конечно. Трушные программисты создают мегакомбайны все-в-одном и живут припеваючи.
>Уже придумали. Называется "микросервисная архитектура"Коллега говорил про функции на уровне ЯП => больше простора для сольдирования(монетизации)
Реализовать функцию для связи с другим контейнером... и поместить ее в другой контейнер? А это идея, надо предложить в C++22
> Реализовать функцию для связи с другим контейнером... и поместить ее в другой
> контейнер? А это идея, надо предложить в C++22Вы изобрели IPC в 2021 году? Все круто, но немного опоздали :)
Для банковских серверов подойдёт. Анониму такая оркестровка микросервисов будет оверхедом.
Угу.
> в случае выявления попытки модификации данных на уровне блочного устройства система перезагружаетсяСамое то для ответственного продакшона. Клиенты, чьи деньги с одного счёта ушли, а на другой не пришли, будут безумно счастливы те несколько дней, пока отдел автоматизации банка будет разбираться и разглядывать под лупой каждую оборванную транзакцию (вместе с тётенькой из финансовых), прежде чем её вручную откатить.
Как показывает пример одного желтого банка - stateless микросервисы с масштабированием на лету вполне пригодны для банковских задач, если у программистов руки не из ягодиц, конечно.
> Анониму такая оркестровка микросервисов будет оверхедом.Если анониму нужно в киберпанк поиграть - да.
А если хочется запилить стартап по продаже булочек с минимальным гемором - почему нет? AWS+кубик - quick, easy, fun! Дороговато, правда, но это уже проблема инвесторов.
В банковской сфере скорее "зайдет" шкаф с кондовой до усрчки IBM i (впрочем, AIX тоже сойдет), чем кубер-кластер, размазанный в чужом облаке. Не говоря уже об ответственности облакодержателя за доступность ресурсов и сохранность данных.К счастью, в [со]ответственных госрегуляторах процент сыроедов/смузихлебов небольшой, и за слишком фривольную работу процессинга, можно лишиться лицензии.
Как же вы ошибаетесь.
Микросервисов у нас уже очень много. У коллег из тоже госбанков - также.Везде молодые энергичные новые пытаются на микросервисных палках и говне БДхи размазывать.
Руководство просто не понимает, в чем оверхед собсна, поэтому выкидываем кучу бабла на железо.
Как правило, ребята от бизнеса уже наелись чудесными мастерами, которые всю бизнес-логику делают на хранимках в оракле, а потом все это при росте нагрузки смасштабировать нельзя, и все жизненно важные банковские сервисы говорят "кря".
что такое "рост нагрузки"? Много данных стало и запросы исполняются медленно? Или много запросов идет от микросервисов? Во-втором случае хранимки ни при чем. В первом - лечится тоже очевидно не "машстабированием" на уровне микросервисов
> Много данных стало и запросы исполняются медленно?
> В первом - лечится тоже очевидно не "машстабированием" на уровне микросервисовОчевидно, вы никогда не занимались ярусным шардированием-агрегированием данных в РСУБД.
Очень сильно развивает условный рефлекс "адепты хранимок разносят заразу, такого увидишь - прибей его сразу".> Или много запросов идет от микросервисов? Во-втором случае хранимки ни при чем.
Ну да, вы же не в курсе, что в микросервисной архитектуре у большинства сервисов есть свои БД, причем не обязательно реляционные. Или просто не понимаете, какая связь между разделением данных по разным БД и снижением числа запросов к отдельно взятой БД.
речь шла про банк вроде? Какая там такая нагрузка, что надо снижать количество запросов? Мы писали данные с нескольких тысяч датчиков в базу и не надо было снижать. А у вас в банке - надо лол.При чем тут шардинг и хранимки? Хранимки - это просто логика. Представь себе их можно вызывать даже для другого инстанса базы, на другом IP. Вопрос - нафига бизнес-логику тащить с клиента, если только ты не имеешь в PL/SQL конечно.
Что касается микросервисной архитектуры и отдельных БД - эту глупость даже комментировать тяжело, микросерфисы - это не Коран, а всего лишь инструмент и архитектур микросервисных - множество. Одна база - целостность данных. Много баз - ни о какой целостности говорить не приходится, все делается на убогих клиентах, написанных убогими программистами
Бизнес есть бизнес, тащить на себе кондовые трехтонные шкафы гораздо дороже, чем кубик.
Конечно же, не у дяди в облаке, а на своих серваках.
systemd, SELinux (не говоря уже про монолитное ядро)- спасибо, нет.
Воу, полегче. На что пересесть предлагаете, так чтобы без MAC и монолитного ядра?
Я не то чтобы предлагаю, сам ищу варианты. Пока гипервизор Xen(микроядро) с виртуалками Parrot Home (дебиановский AppArmor), колхоз на тему Qubes OS. Есть свои минусы, а в свете скурвливания Debian - хочется чегой-то посекьюрнее, без такого прокладывания под RedHat с завязкой на systemd. Вот думу думаю и Bottlerocket как-то не привлекает.
А я из KVM сделал, просто виртуалки с дебианами, без всякой хайпоты. Так оно тяжелее конечно, зато и изоляция крепче (и кто сказал что контейнеров внутрях нет).Что до дебиана - вариантов лучше как-то особо и не заметно вроде. Эти достаточно стабильные, предсказуемые и не слишком интрузивные. Хотя для совсем олдскульщиков какая-нибудь слака наверное, но в олдскуле так то и виртуализация не полагается, там вообще первый же рутовый эксплойт по канону имеет вас от и до :P
KVM/QEMU тоже рассматривал (Аллах с потерей % произв-ти), но, поскольку я тот ещё параноик - меня смутило то, что к KVM плотно приложились RedHat, опять же SELinux и, главное - KVM же кусок ядра Linux. А Xen- с отдельным микроядрышком и разрабатывается Linux Foundation всё-таки, что изрядно успокоило мою паранойю.
Xen не является полноценным ядром, и практически все основные функции делегирует ядру dom0. Именно поэтому для его поддержки пришлось запихнуть в Linux кучу ксеновского кода.> меня смутило то, что к KVM плотно приложились RedHat
А то, что к Xen приложился Citrix, вас не смущает?
Citrix давно сказали, что Xen не есть их приоритет и делать деньги на этом не планируют, даже проприетарный bare metal XenServer открыли и дали забесплатно. Понятно, что есть подвох - пилится Xen очень постепенно. А вот KVM стал фактически стандартом и развивается бешеными темпами. Так что может и придётся на него перелезать, ибо два остальных главных стандарта HyperV и ESXi те ещё проприетарные blackbox.
А что, редхат на KVM или SELinux деньги делает?> Так что может и придётся на него перелезать, ибо два остальных главных стандарта HyperV и ESXi те ещё проприетарные blackbox.
Учитывая ваше недоверие к редхату, и учитывая, что на Linux он деньги как раз делает, возможно, приприетарные решения будут не худшим вариантом.
> KVM/QEMU тоже рассматривал (Аллах с потерей % произв-ти),По производительности CPU/ram почти как baremetal, io особо не тормозит, qxl или virtio gpu 1080p ютуб кажут. Что мне еще надо? Разве что RAM тратится, отдельная ОС же. Но я умею в минимализм, виртуалки 128-256 оперативы для сервисов. К тому же на qemu/kvm действует ksm, он частично дедуплицирует RAM похожих VM.
> но, поскольку я тот ещё параноик - меня смутило то, что к KVM плотно приложились RedHat,
К всем живым виртуализаторам корпы прикладываются, и к кернелу. На этом их бизнес держится. Это же вызывает сомнения что они нагадят себе в прод, вредно для бизнеса. А что ревью кода в Xen лучше чем в Linux Kernel - имхо не факт.
> опять же SELinux и,
Я им не пользуюсь, пусть NSA с регламентами упирается. А с моей точки зрения это много канители, а вырубается каждым уважающим себя эксплойтом, такое соотношение мне не нравится.
> главное - KVM же кусок ядра Linux.
В ядре Linux делом доказали, как КХ против миннесоты недавно, что не лыком шиты.
> А Xen- с отдельным микроядрышком
1. Бесполезным без Linux в dom0. При том посокольку там device drivers, его поимение не так уж лучше поимения кернела с kvm вроде?
2. Не факт что с более качественным кодом.
3. Разрабатывается хрен знает кем. Ядерщиков я знаю, и что они могут видел. Про xen я это сказать не могу.> и разрабатывается Linux Foundation всё-таки,
Я доверяю шайке торвальдса с их устоявшимися практиками в плане ревью кода больше чем тому фаундейшну с майкрософт корп и руководилой юзающим мак. Никогда не видел по части Xen ничего сравнимого с KH vs minnesota.
> что изрядно успокоило мою паранойю.
А предпосылками что? Linux foundation в целом так себе шарага, с майкрософтами и проч.
p.s. анонимус, а ты забавный. Как тебе https://www.opennet.ru/tips/3166_bitmessage_imap_smtp_docker... (доскер можно и не юзать) - если пронравится, пиши BM-87b9JSFbo88N7BVrWJ426Y1MKJbu9CGb3UC - вроде прикольнее для анонимусов получается :)
Боишься что RedHat украдут твои данные? Ты в ФСБ что ли работаешь? Что-то логику не могу уловить. Тебе б на Эльбрус перебраться - Intel к CPU "руку приложили"
>А я из KVM сделал, просто виртуалки с дебианамиУсловно говоря, "облако" где-то так и работает - клиент получает запрошенное количество виртуалок нужной кофигурации с развернутой ОСЬю. Уже внутри этой ОСи запускаются контейнеры со stateless-софтом.
Идея этой БутылкоРакеты - уменьшить толщину ОСи в виртуалках, сведя функционал к запуску контейнеров и взаимодействию с оркестратором. Разумеется, вместе с водой выплеснули и ребенка...
В смысле - выплеснули? Решение вполне рабочее, но уж очень нишевое - за пределами амазона этот дистр бесполезен.
> Условно говоря, "облако" где-то так и работает - клиент получает запрошенное количество
> виртуалок нужной кофигурации с развернутой ОСЬю.Спасибо Кэп. Как ты понимаешь, идея была частично сперта у энетрерпайзников, частично у руткитской.
> Уже внутри этой ОСи запускаются контейнеры со stateless-софтом.
В моем случае может быть stateless, может не быть. Может быть снапшот, допустим, но откат на него только в энных случаях.
> Идея этой БутылкоРакеты - уменьшить толщину ОСи в виртуалках, сведя функционал к
> запуску контейнеров и взаимодействию с оркестратором. Разумеется, вместе с водой выплеснули
> и ребенка...Учитявая их список баззвордов, я как-нибудь пешком постою без всей этой хайпоты. Проверять отгрузят ли этим растишкам из репы хруста не снабженной подписями какую-нибудь гадость - это как-нибудь на фрактале каком, чтоли. И "облака" мне не особо упали для вон тех целей. Видите ли тут я в qemu и гипервизор и дебагсервер, one level above. А в этом вашем облаке все это тоже можно, только - не мне, вот ведь какой нюанс... так что чужое облако следует рассматривать как потенциально ненадежную штуку. В конечном итоге гипервизор всегда может "отменеджить" гуеста по самые небалуйся, какие бы там козьи морды не делали владельцы облаков.
https://projectacrn.org - легковесный реалтаймовый гипервизор от интел.
Есть ещё какой-то гипервизор от сименса, но там вм гвоздями прибивается к ядру процессора, соотв. число вм ограничено числом ядер физического процессора.
> ACRN is an open source reference hypervisor, built to meets the unique needs of embedded IoT development. Today’s connected devices are increasingly expected to support a range of hardware resources, operating systems, software tools, and applications. Virtualization is vital to meet these broad needs, however, existing VM solutions don’t offer the right size and flexibility for IoT.
> Datacenter hypervisor code is too big, and its boot time is too slow. It doesn’t offer safety-critical workload capabilities and requires too much overhead for embedded development. Proprietary solutions are expensive and make it difficult to deliver long-term product support. There’s a pressing need for a reference hypervisor that meets the specialized needs of embedded IoT product development. Project ACRN™ provides the answer.Ох, они хотят чтобы даже на холодильнике была запущена пачка виртуальных машин.
> https://projectacrn.org - легковесный реалтаймовый гипервизор от интел.А management engine они туда встроили? Какой же интел без management engine? :)
Это не годится - Intel руку приложило". И Сименс не годится - "Сименс руку приложили". Анону надо чего-нибудь православненького, судя по всему лол - к Линуксу США "руку приложили" опять же...
Не надо вот тут. К Linux руку швед руку приложил. Финский швед. :)
ну это совсем плохо, учитывая какие там гей-парады ходють
> Не надо вот тут. К Linux руку швед руку приложил. Финский швед. :)...получивший американское гражданство, а потому заодно еще и американец :)
> в свете скурвливания Debian - хочется чегой-то посекьюрнее, без такого прокладывания под RedHat с завязкой на systemdТогда варианта всего два - Hyper-V и BHyVe.
HyperV проприетарный и на нём Lunux виртуалки, отличные от дефолтных, бывает, выкидывают сюрпризы, в BSD лезть неохота, надо всё таки работу работать, а не покорять новые, ненужные горизонты. Интел и сименс - новые (привет, баги) специализированные решения, как-то я пока их не вижу на Homelab workstation или server.
> HyperV проприетарный и на нём Lunux виртуалки, отличные от дефолтных, бывает, выкидывают сюрпризы, в BSD лезть неохота, надо всё таки работу работать, а не покорять новые, ненужные горизонты.Люди, которые всерьез воюют со "злобным редхатом" и "его продуктами", типа Linux kernel и systemd (в обоих проектах, на самом деле, вклад отдельно взятого редхата существенен, но не 100%), обычно все-таки работают работу на чем-то другом, нежели нехороший линукс с нехорошим системды.
А есть люди, которые ни с кем не воюют, но по работе надо сделать secure. А ещё есть люди, которые имели в виду ковыряться в SELinux.
Таких людей в этом обсуждении не наблюдаю. Потому что они строят комплекс защитных мер на основе модели угроз с оценками рисков, а не рассуждают в стиле "мне вот это чисто интуитивно нравится, а вон тот какой-то не такой, даже сам не знаю почему".
Не подходит, тут же вот какое дело:Hyper-V -> Microsoft -> USA -> NATO -> ... -> собака -> c**ка
Не годится
Тотемное животное США - не собака, а скунс. Так что норм.
А они верят что орлан. Хотя, возможно, что ошибаются
Очень многие вещи внутри США и за пределами страны называются по-разному.Например, то, что в других странах клеймится термином corruption, применительно к самим США неоофенсивно и инклюзивно именуется business.
> Hyper-V -> Microsoft -> USAВ США так то ~90% софта планеты пишется. Так что если ты надеялся импортозаместить, носить тебе непереносить...
Они там походу вообще все хайпожорские баззворды в этой штуке собрали.
Без этого инвесторы денех не дадут.
Веселят коментарии староверов "ненужны нам ваши контейнеры, нам и на виртуализации хорошо". Да вот только прогресс не остановить и остается либо принять тренды либо скатится на обочину.
Есть гвоздь, есть молоток, а есть отвертка.Можно забить - можно завентить. Держать будет одинаково.
Если люди намастрячились крутить гвозди и они не выскакивают - пусть так, при условии что времени и $$ стоит столько же сколько завинтить.
ничего тупей этой "аналогии" придумать невозможно. впрочем для икспертов опеннет - это норма
Хозяйке на заметку: саморез забитый молотком держит лучше, чем гвоздь, закрученный отверткой (с)
Это регрес, а не прогресс.
Расскажи это программистам на коболе и фортране, ага. А заодно поспрашивай старших о том, сколько новомодной хрени, на которую молились малолетние энтузиасты, оказалось на той самой обочине.
> Расскажи это программистам на коболе и фортране, ага.Боюсь, ваша просьба не является достаточным основанием потратить день на поездку в дом престарелых.
> Веселят коментарии староверов "ненужны нам ваши контейнеры, нам и на виртуализации хорошо". Да вот только прогресс не остановить и остается либо принять тренды либо скатится на обочину.Поинтересуйтесь на досуге, на каких машинах крутятся ваши прогрессивные контейнеры.
Hint: в 99.999% случаем это не bare metal.
На третий день Зоркий Глаз заметил что его отменеджил гипервизор...
это так. Но докер не для виртуализации, а для доставки апплекух, относительно независимым от среды образом. Чтоб программеры не говорили: странно, а у меня работает, а у Васи - нет, хотя Джава та же. Что-то типа толстого RPM-а
Естественно. Просто тут некоторые комментаторы не видят разницы между контейнерами докера (более обобщенно я бы назвал их CRI-подобными), LXC и OpenVZ. А про последние два смутно помнят, что противопоставляют виртуализации (опять-таки, от большого ума). Это делает меня печальной пандой.
Какой в этом смысл если это всё обходится через уязвимости в процессорах.
Как конкретно происходит утечка в qubes например? (которая имеет по хen окружению на dom0, сетевые sys-net и sys-firewall и собственно domU с данными)
Абсолютно так же, как и между процессами на обычной ОС. Виртуализация (если она реализована в процессоре) - это прежде всего про разделение доступа к периферии.
> Как конкретно происходит утечка в qubes например?Да процу то какая разница где оно там. Если через кэш и сайдэффекты тайминги текут то уж текут. Сам по себе виртуализатор от этого не особо спасет, разве что немного размоет картину в лучшем случае. И если в случае линуха кернел немного заморочился подкостыливанием этого и даже довольно оперативно вертится на это, то как это с Xen взаимодействует и подкостылили ли и там - а кто б его там знает.
> Контейнеры создаются при помощи штатных механизмов ядра Linux - cgroups, пространств имён и seccomp.Где о таком подробнее почитать можно?
В документации на ядро.
Не издеваюсь - но больше мест где это было бы как-то подробно расписано, я не знаю.https://www.kernel.org/doc/html/latest/userspace-api/seccomp...
https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1...
https://www.kernel.org/doc/html/v4.14/admin-guide/LSM/Yama.html
https://www.kernel.org/doc/html/latest/admin-guide/device-ma...SELinux это конечно хорошо, но я для таких вещей когда-то RSBAC-ом пользовался.
SELinux пока отконфигурируешь - кучу времени убьёшь.
> SELinux пока отконфигурируешь - кучу времени убьёшь.В принципе, про seccomp и firewall можно то же самое сказать.
SELinux требует понимания, к каким файлам и каталогам обращается программа.
Seccomp требует понимания, какие сисколлы нужны для работы программы.
Firewall требует понимания, на какие хосты и порты может обращаться программа.Нанести, смыть, повторить для всех программ в системе.
Не всё так плохо. Есть вот такое вот:https://github.com/QuarkSecurity/SPAN
SELinux Policy Analysis NotebookСделано для RH-based и уже 2 года не развивается.
Но я пользовался несколько раз - помогает.
То есть допиливать политику приходится не с нуля.
На рабочей системе, которая постоянно изменяется - очень муторно, никто не спорит.
А вот для контейнера, который настраивается только один раз - овчинка выделки может и стоить.
И всё-таки RSBAC гораздо понятнее и проще в настройке.
> SELinux пока отконфигурируешь - кучу времени убьёшь.А хакеру его потом эксплойт совершенно стандартно вырубит. Оно надо с таким соотношением?
Ну, если у хакера есть стандартный эксплойт с одной кнопкой "взломать что угодно", тогда да, любые меры защиты бесполезны.
> Ну, если у хакера есть стандартный эксплойт с одной кнопкой "взломать что
> угодно", тогда да, любые меры защиты бесполезны.Ну, блин, в всех более-менее серьезно настроеных эксплойтах на ядро SELinux вырубается первым делом. Так что соотношение получается очень так себе. ИМХО технологии должны создавать минимум сложностей для легитимного юзера и максимум для левого атакующего. Это точно не про SELinux, там скорее все наоборот. Хакер вырубит одной левой, а долботни с настройкой эвон сколько.