|
|
@@ -0,0 +1,163 @@
|
|
|
+# Права доступа к файлам Linux
|
|
|
+Под именем Linux сегодня люди понимают одну из двух вещей:
|
|
|
+Операционные Системы на базе GNU/Linux, или, как их по-другому называют, дистрибутивы. Наиболее популярные RedHat/CentOS, Debian, Ubuntu и другие.А так же ядро Linux и, опционально, набор программ GNU coreutils.
|
|
|
+
|
|
|
+# Наследие MULTICS
|
|
|
+Система прав доступа в Linux уходит корнями в 1960-е годы, в проект MULTICS (Multiplexed Information and Computing Service). Этот революционный проект, в котором участвовали MIT, General Electric и Bell Labs, впервые представил концепцию многоуровневой безопасности для многопользовательских систем.
|
|
|
+Кен Томпсон и Деннис Ритчи, работавшие над MULTICS, позже создали UNIX, взяв лучшие идеи, но упростив реализацию. Именно в UNIX оформилась та система прав, которую мы знаем сегодня.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+# Фундаментальные принципы файловой системы Linux
|
|
|
+Иерархия каталогов: Наследие FHS
|
|
|
+Filesystem Hierarchy Standard (FHS) определяет структуру, которую наследует Linux от UNIX:
|
|
|
+/
|
|
|
+├── bin/ # Базовые исполняемые файлы
|
|
|
+├── etc/ # Конфигурационные файлы
|
|
|
+├── home/ # Домашние каталоги пользователей
|
|
|
+├── tmp/ # Временные файлы (sticky bit)
|
|
|
+├── usr/ # Пользовательские программы
|
|
|
+├── var/ # Изменяемые данные
|
|
|
+└── root/ # Домашний каталог root
|
|
|
+
|
|
|
+# Inode: Сердце файловой системы
|
|
|
+Каждый файл в Linux представлен inode (index node), который содержит:
|
|
|
+- Метаданные файла
|
|
|
+- Права доступа
|
|
|
+- Владельца и группу
|
|
|
+- Временные метки
|
|
|
+- Указатели на данные
|
|
|
+
|
|
|
+# Эволюция интерпретации прав
|
|
|
+1970-е: В ранних версиях UNIX право выполнения (x) для каталогов не имело сегодняшнего смысла. Изначально система была ориентирована на исполняемые файлы.
|
|
|
+1980-е: С ростом популярности UNIX в академической среде появилась необходимость в более тонком контроле доступа к общим ресурсам.
|
|
|
+
|
|
|
+# Владелец (User - u)
|
|
|
+История: В ранних UNIX системах UID 0 (root) имел особый статус
|
|
|
+Современность: Каждый пользователь имеет уникальный UID
|
|
|
+--------------------------------------------------------------------------
|
|
|
+$ id username
|
|
|
+uid=1000(username) gid=1000(username) groups=1000(username),...
|
|
|
+--------------------------------------------------------------------------
|
|
|
+
|
|
|
+# Группа (Group - g)
|
|
|
+Эволюция: Изначально пользователь мог быть только в одной группе
|
|
|
+1980-е: Добавлена поддержка множественных групп
|
|
|
+--------------------------------------------------------------------------
|
|
|
+$ groups username
|
|
|
+username : username wheel developers
|
|
|
+--------------------------------------------------------------------------
|
|
|
+
|
|
|
+# Расширенные атрибуты доступа
|
|
|
+
|
|
|
+SGID (Set Group ID): Решение для коллективной работы
|
|
|
+Проблема: В научных и академических средах 1980-х годов требовался эффективный обмен данными между исследователями.
|
|
|
+--------------------------------------------------------------------------
|
|
|
+Создание общего рабочего пространства
|
|
|
+$ mkdir /research/project_alpha
|
|
|
+$ chgrp researchers /research/project_alpha
|
|
|
+$ chmod g+s /research/project_alpha
|
|
|
+
|
|
|
+Все новые файлы наследуют группу каталога
|
|
|
+$ touch /research/project_alpha/data.txt
|
|
|
+$ ls -l /research/project_alpha/data.txt
|
|
|
+-rw-r--r-- 1 alice researchers 0 May 10 10:00 data.txt
|
|
|
+--------------------------------------------------------------------------
|
|
|
+# Sticky Bit: От оптимизации к безопасности
|
|
|
+Историческое применение: Изначально sticky bit заставлял систему сохранять образ программы в swap-памяти после завершения для ускорения последующего запуска.
|
|
|
+
|
|
|
+Современное использование:
|
|
|
+#Классический пример - /tmp каталог
|
|
|
+$ ls -ld /tmp
|
|
|
+drwxrwxrwt 15 root root 4096 May 10 10:00 /tmp
|
|
|
+
|
|
|
+Эволюция:
|
|
|
+1970-е: Оптимизация производительности
|
|
|
+1980-е: Обнаружение security-применения
|
|
|
+1990-е: Стандарт для общих каталогов
|
|
|
+
|
|
|
+ # Утилита chmod: Два лица одной команды
|
|
|
+# Символьный формат: Человеко-читаемый
|
|
|
+
|
|
|
+
|
|
|
+ Исторические примеры из руководств 1980-х годов
|
|
|
+chmod u+x script.sh # Добавить выполнение владельцу
|
|
|
+chmod go-w confidential.txt # Забрать запись у группы и остальных
|
|
|
+chmod a=rx public_dir # Установить чтение и выполнение для всех
|
|
|
+
|
|
|
+Специальные флаги (добавлены в 1970-е)
|
|
|
+chmod u+s /usr/bin/su # SUID - исторически для системных утилит
|
|
|
+chmod g+s /shared/research # SGID - для академических проектов
|
|
|
+chmod +t /public/upload # Sticky bit - для общих каталогов
|
|
|
+
|
|
|
+Цифровой формат: Наследие восьмеричной системы
|
|
|
+Философия: Восьмеричная система была естественна для программистов ранней эпохи, работавших с машинными кодами.
|
|
|
+
|
|
|
+#Базовые права (классическая схема)
|
|
|
+chmod 755 script.sh # rwxr-xr-x - стандарт для исполняемых файлов
|
|
|
+chmod 644 config.conf # rw-r--r-- - стандарт для конфигураций
|
|
|
+chmod 600 secret.txt # rw------- - максимальная приватность
|
|
|
+
|
|
|
+#Специальные флаги (четвертая цифра)
|
|
|
+chmod 4755 /usr/bin/sudo # SUID установлен
|
|
|
+chmod 2750 /shared/project # SGID для групповой работы
|
|
|
+chmod 1777 /tmp # Sticky bit для временных файлов
|
|
|
+
|
|
|
+# Современные тенденции в управлении доступом Linux
|
|
|
+# Контейнеризация: Изоляция прав на уровне контейнеров
|
|
|
+Современная контейнеризация представляет собой фундаментальный сдвиг в парадигме управления правами доступа. В отличие от традиционного подхода, где права управляются на уровне физического сервера, контейнеризация внедряет концепцию изоляции безопасности на уровне отдельных контейнеров.
|
|
|
+
|
|
|
+Ключевым механизмом обеспечения безопасности в контейнерах являются пространства имен (namespaces), которые создают виртуализированные представления системных ресурсов. Пространство имен пользователей (user namespace) позволяет отображать идентификаторы пользователей и групп внутри контейнера в различные идентификаторы на хост-системе, обеспечивая тем самым, что привилегированный пользователь root внутри контейнера не обладает соответствующими привилегиями на основной системе.
|
|
|
+
|
|
|
+Пространство имен монтирования (mount namespace) изолирует файловые системы контейнера, ограничивая доступ к точкам монтирования хост-системы. Дополнительный уровень безопасности обеспечивается механизмами seccomp, которые фильтруют системные вызовы, и профилями безопасности, ограничивающими возможности (capabilities) контейнеров.
|
|
|
+
|
|
|
+Эта многоуровневая система изоляции создает среду, где нарушения прав доступа внутри одного контейнера не оказывают влияния на другие контейнеры или хост-систему, что особенно критично в многопользовательских и облачных средах.
|
|
|
+
|
|
|
+# SELinux/AppArmor: Мандатный контроль доступа
|
|
|
+Эволюция систем контроля доступа привела к переходу от дискреционной модели к мандатному контролю. В то время как традиционная модель Linux основана на дискреционном контроле доступа, где владелец ресурса самостоятельно определяет политику доступа, мандатная модель предполагает централизованное управление политиками безопасности на уровне системы.
|
|
|
+
|
|
|
+SELinux (Security-Enhanced Linux) реализует модель принудительного контроля доступа на основе мандатных политик. Его архитектура основана на концепции контекстов безопасности, где каждому процессу и системному объекту присваиваются метки безопасности. Эти метки содержат информацию о пользователе, роли, типе и уровне безопасности, формируя сложную матрицу доступа.
|
|
|
+
|
|
|
+Политика SELinux определяет правила взаимодействия между различными типами процессов и объектов, обеспечивая минимальные привилегии даже для процессов, выполняющихся от имени root. Система использует расширенные атрибуты файловой системы для хранения меток безопасности и обеспечивает принудительное применение политики на уровне ядра.
|
|
|
+
|
|
|
+AppArmor предлагает альтернативный подход к мандатному контролю, основанный на профилях путей. В отличие от SELinux, который использует сложную систему меток, AppArmor определяет политики безопасности через пути файловой системы и разрешенные операции. Профили AppArmor описывают, к каким файлам, сокетам и возможностям может обращаться приложение.
|
|
|
+
|
|
|
+Обе системы обеспечивают защиту от эскалации привилегий, ограничивают уязвимости нулевого дня и предоставляют механизмы аудита безопасности. Их внедрение особенно важно в средах с высокими требованиями к безопасности, где традиционной модели прав доступа недостаточно для противодействия современным угрозам.
|
|
|
+
|
|
|
+# Filesystem Capabilities: Гранулярные привилегии
|
|
|
+Традиционная модель привилегий в Linux, основанная на бинарном разделении между обычными пользователями и суперпользователем root, демонстрирует свою ограниченность в современных сложных системах. Для решения этой проблемы были разработаны возможности файловой системы (capabilities) — механизм гранулярного распределения привилегий.
|
|
|
+
|
|
|
+Возможности файловой системы разбивают монолитные привилегии root на отдельные, независимые права, которые могут быть назначены исполняемым файлам и процессам. Это позволяет предоставить приложению только те специфические привилегии, которые необходимы для его функционирования, следуя принципу минимальных привилегий.
|
|
|
+
|
|
|
+Система включает десятки различных возможностей, каждая из которых представляет собой конкретную привилегию, ранее доступную только суперпользователю. Например, отдельные возможности управляют правами на изменение системного времени, работу с сетевыми интерфейсами, выполнение системных административных задач и другие критически важные операции.
|
|
|
+
|
|
|
+Возможности могут быть назначены исполняемым файлам на постоянной основе через расширенные атрибуты файловой системы, что позволяет программам получать необходимые привилегии без необходимости установки битов SUID или выполнения от имени root. Также возможности могут динамически назначаться процессам во время выполнения, обеспечивая гибкое управление привилегиями.
|
|
|
+
|
|
|
+Наследуемые и эффективные наборы возможностей обеспечивают контроль над распространением привилегий между родительскими и дочерними процессами. Механизмы ограничивающих возможностей предоставляют дополнительный уровень безопасности, устанавливая верхнюю границу привилегий, которые процесс может получить.
|
|
|
+
|
|
|
+Этот гранулярный подход значительно повышает безопасность системы, уменьшая поверхность атаки и ограничивая потенциальный ущерб от скомпрометированных приложений, одновременно обеспечивая необходимую функциональность для легитимных процессов.
|
|
|
+
|
|
|
+# Заключение: Философия прав доступа как отражение эволюции вычислительных систем
|
|
|
+Система прав доступа Linux представляет собой не просто набор технических механизмов контроля, а живое воплощение пятидесятилетней эволюции компьютерных систем. Её развитие — это история поиска баланса между простотой и мощностью, между доступностью и безопасностью, между индивидуальным контролем и системным управлением.
|
|
|
+
|
|
|
+От своих истоков в проекте MULTICS, где впервые были заложены принципы многопользовательской безопасности, через элегантное упрощение в UNIX, где сложные механизмы уступили место понятной и эффективной модели, к современным облачным и контейнерным средам — система прав доступа демонстрирует удивительную адаптивность. Эта эволюция не была простым линейным прогрессом; она отражала меняющиеся парадигмы в понимании того, что значит быть "безопасной системой" в разных исторических контекстах.
|
|
|
+
|
|
|
+Фундаментальная философия UNIX — "делай одну вещь и делай её хорошо" — нашла своё совершенное выражение в модели "пользователь-группа-остальные". Эта триада, при всей своей кажущейся простоте, оказалась на удивление мощным и гибким инструментом. Её гениальность заключается в том, что она одновременно интуитивно понятна для новичков и предоставляет достаточно выразительности для опытных системных администраторов. Как отмечали многие компьютерные философы, настоящая элегантность заключается не в добавлении возможностей, а в нахождении минимального набора примитивов, достаточного для решения всех возникающих задач.
|
|
|
+
|
|
|
+Исторический контекст развития системы прав — это зеркало эволюции самих вычислений. В 1970-е годы, когда компьютеры были дорогими ресурсами, разделяемыми между многими пользователями, система прав решала задачу изоляции и защиты. В 1980-е, с распространением UNIX в академической среде, появилась потребность в механизмах collaboration, что привело к развитию групповых политик. 1990-е, с ростом интернета и увеличением кибератак, сместили акцент на безопасность и минимизацию привилегий. Наконец, современная эпоха облачных вычислений и контейнеризации потребовала новых уровней абстракции и изоляции.
|
|
|
+
|
|
|
+Но что действительно поражает в этой системе — её способность сохранять обратную совместимость, продолжая при этом развиваться. Современные расширения, такие как POSIX ACL, возможности файловой системы (capabilities), мандатный контроль доступа через SELinux и AppArmor — все они не заменяют классическую модель, а расширяют её, предоставляя дополнительные инструменты для решения специфических задач.
|
|
|
+
|
|
|
+Освоение системы прав доступа Linux — это не просто изучение синтаксиса chmod или запоминание восьмеричных кодов. Это погружение в культуру UNIX, понимание того, как проектировались системы, предназначенные для длительной эксплуатации и эволюции. Это изучение того, как простые идеи, правильно реализованные, могут выдержать испытание временем и оставаться актуальными спустя десятилетия.
|
|
|
+
|
|
|
+Каждый аспект системы прав несёт в себе уроки проектирования: от важности принципа минимальных привилегий до ценности прозрачности и предсказуемости. Эти принципы выходят далеко за рамки управления файлами и каталогами — они формируют основу для понимания того, как строить надёжные, безопасные и масштабируемые системы.
|
|
|
+
|
|
|
+В эпоху, когда вычисления становятся всё более распределёнными и сложными, понимание фундаментальных основ, таких как система прав доступа Linux, становится не менее важным, чем знание современных фреймворков и платформ. Это знание соединяет нас с богатой историей вычислительной техники и даёт прочный фундамент для решения будущих challenges.
|
|
|
+
|
|
|
+Как говорил Деннис Ритчи, один из создателей UNIX: "UNIX очень прост, но нужен гений, чтобы понять его простоту". Система прав доступа — прекрасная иллюстрация этой глубокой истины. Её изучение — это не только техническое образование, но и приобщение к традициям, которые сформировали современный ландшафт информационных технологий и продолжают влиять на его развитие.
|
|
|
+
|
|
|
+# Источники
|
|
|
+https://habr.com/ru/articles/469667/
|
|
|
+https://securitymedia.org/
|
|
|
+
|
|
|
+--------------------------------------------------------------------------------
|
ypv
