Comments 18
Лет 20-25 назад Ваша статья была бы актуальна как никогда (когда деревья были большие). Сейчас новички получат тот же пакет знаний, используя пресловутый FuckAI, но не задумываясь, как это всё "под капотом" сложено.
Да, понимаю это. Но все равно есть те кто не ограничивается поверхностным ответом нейронок и отдает предпочтение литературе, статьям и документации.
А еще, нейронки лениво дозируют информацию из своих весов, и что бы получить подробные ответы, нужно знать что спрашивать, без каркаса фундаментальных знаний — спрашивать-то нечего.
А неплохо получилось.
Только аналогии по selinux больше запутают, чем помогут новичку, выглядит не очень корректно.
Возможно стоит добавить про само управление метками selinux, атрибуты (тот же immutable).
На самом деле примерно половина того, что хотелось рассказать, а уже вышло прилично текста. Думаю в отдельную статью вынести некоторые темы, например POSIX ACL, еще думаю стоит схематично описать как устроены процессы linux и как они наследуют права/владельца/группу и прочее, еще туда же umask. Да и про модель Белла-Лападулы хотя бы уровня главного принципа No Read Up, No Write Down хотелось бы рассказать. Короче тема объменая, побоялся увязнуть еще на несколько дней написания и решил без фанатизма обпуликовать текущую версию, хотя бы узнать на сколько зайдет.
Отличный tutorial
Все супер. Нужно продолжение, хорошо получается.
По вопросам штатных дискреционных UNIX-прав, отчасти по SELinux и обзору дистрибутивов Linux написано хорошо. По более сложным вопросам, где машинное обучение (ИИ) еще не научилось выдавать правильные ответы, гораздо хуже. Например (далеко не полный перечень ошибочных суждений):
наличие владельца у объекта доступа не является обязательным для дискреционного управления доступом;
к атрибутивному управлению доступом (ABAC), строго говоря, сводится любой другой вид управления доступом, поэтому не верно говорить, что ABAC - «современная модель» (к слову, единой формальной модели ABAC не существует);
«модели управления доступом» (например, Take-Grant, Белла-ЛаПадулы, Биба, МРОСЛ ДП-модель) и «политики (принципы, методы) управления доступом» (политики дискреционного, мандатного, ролевого управления доступом или мандатного контроля целостности) не одно тоже;
AppArmor реализует не мандатное, а дискреционное управление доступом (MAC и мандатное управление доступом разные вещи);
в ОС Astra Linux основной реализованной PARSEC политикой управления доступом является мандатный контроль целостности (МКЦ), который в статье не упомянут вообще. При это, не понятно, что автором понимается под «Parsec Roles».
Поэтому, кому по профессиональным вопросам информационной безопасности важна достоверная информация (а не плод генерации ИИ), снова рекомендую пользоваться соответствующими источниками, например:
Большое спасибо за развернутую обратную связь, но совсем не понимаю к чему обвинение в ИИ.
Единственная часть где ИИ было задействовано — сравнительная таблица дистрибутивов, но я в тексте отметил что там помогала мне нейронка.
В остальном, почти везде оставлены ссылки на разные источники, рускоязычные и англоязычные в том числе, по которым я проверял информацию которую пишу что бы не ввести никого в заблуждение.
Я бы закрепил даже ваш комментарий, если бы не эта неприятная, токсичная часть с ИИ…
Тимофей, Вы много выучили про систему прав Linux и поделились с другими. Почему же Вы никак не выучите как писать “что бы” и “чтобы”? Кровь течёт из глаз прямо на сердце при виде таких текстов. Мой Вам совет: если не хотите запоминать в каких случаях как правильно, пишите слитно всегда. Так Вы чаще попадёте в правило.
....передайте кто-нибудь разработчикам, что для chmod и chown надо добавить директиву d. А-то задалбывает огородить при переносе из винды.
А ещё есть интересные файловые атрибуты, которые можно установить через chattr.
Да, есть ещё люди, скучающие по глубоким и подробным системным описаниям, типа меня. В CW российском когда-то были такие статьи с ликбеза и в каждом почти номере. Спасибо!
Только в разделе про mandatory (MAC) спецслужбы лишние и только запутывают все дело. Плохой пример. Лучше исправить на такой: есть, мол, в организации документы разного уровня секретности: приглашение на собрание, инструкция по пользованию кофеваркой, журнал резервного копирования, финансовые отчёты, планы развития компании и пр. и, в зависимости от уровня посвящённости пользователя в дела организации или государственные, пользователь имеет право какие-то документы править и удалять, какие-то только читать, к каким-то не имеет доступа.
P. S.: К сожалению не могу уже неск. дней плюсовать и вести диалог чаще раза в сутки, благодаря местной системе, которой пользуются злонамеренные залётные учётные записи из незалежной. Недавно одна такая залетела, раздала два десятка комментариев, типа "лапти", "ватники", "недолюди"... (самые добрые выбираю), понизило мне счёт, нахватало неск. десятков минусов и побежало регистрировать новую учётку для своих черных пропагандистских дел.
Если кто-то может поправить мое положение — заранее спасибо! ;-)
Статья честно предупреждает, что для начинающих. Именно поэтому в ней нет самого важного: что делать, когда "Permission denied" при правах 777. Это первая загадка после чтения любой шпаргалки по chmod – оказывается, SELinux об этом не знал.
Права в Linux: chown/chmod, SELinux context, символьная/восьмеричная нотация, DAC/MAC/RBAC/ABAC