Поскольку Linux – система многопользовательская, вопрос об организации разграничения доступа к файлам и каталогам является одним из существенных вопросов, которые должна решать ОС. Механизмы разграничения доступа, разработанные для системы UNIX в 70-х годах, очень просты, но они оказались настолько эффективными, что просуществовали уже более 40 лет и по сей день успешно выполняют стоящие перед ними задачи.
В основе механизмов разграничения доступа лежат имена пользователей и имена групп пользователей. В Linux каждый пользователь имеет уникальное имя, под которым он входит в систему. Кроме того, в системе создается некоторое число
групп пользователей, причем каждый пользователь может быть включен в одну или несколько групп. Создает и удаляет группы суперпользователь (Root), он же может изменять состав участников той или иной группы. Члены разных групп могут иметь разные права по доступу к файлам, например, группа администраторов может иметь больше прав, чем группа программистов.
групп пользователей, причем каждый пользователь может быть включен в одну или несколько групп. Создает и удаляет группы суперпользователь (*Root*), он же может изменять состав участников той или иной группы. Члены разных групп могут иметь разные права по доступу к файлам, например, группа администраторов может иметь больше прав, чем группа программистов.
В индексном дескрипторе каждого файла записаны имя так называемого владельца файла и группы, которая имеет права на этот файл. Первоначально, при создании файла его владельцем объявляется тот пользователь, который этот файл создал. Точнее – тот пользователь, от чьего имени запущен процесс, создающий файл. Группа тоже назначается при создании файла – по идентификатору группы процесса, создающего файл. Владельца и группу файла можно поменять в ходе дальнейшей работы с помощью команд chown и chgrp. Изменить владельца и группу может только суперпользователь (root).
В индексном дескрипторе каждого файла записаны имя так называемого владельца файла и группы, которая имеет права на этот файл. Первоначально, при создании файла его владельцем объявляется тот пользователь, который этот файл создал. Точнее – тот пользователь, от чьего имени запущен процесс, создающий файл. Группа тоже назначается при создании файла – по идентификатору группы процесса, создающего файл. Владельца и группу файла можно поменять в ходе дальнейшей работы с помощью команд *chown* и *chgrp*. Изменить владельца и группу может только суперпользователь (root).
Выполнение команд в Linux происходит через терминал, также можно написать файл с расширением «sh», который будет содержать команды для терминала. Чтобы получить информацию о конкретном файле в linux, в терминале можно использовать команду ls –l (рисунок 1). Первое поле в этой строке отражает права доступа к файлу. Третье поле указывает на владельца файла (user). Четвёртое поле указывает на группу, которая владеет этим файлом (users). Последнее поле указывает имя файла. Для вызова справки команда «ls --help».
Выполнение команд в Linux происходит через терминал, также можно написать файл с расширением *.sh*, который будет содержать команды для терминала. Чтобы получить информацию о конкретном файле в linux, в терминале можно использовать команду `ls –l` (рисунок 1). Первое поле в этой строке отражает права доступа к файлу. Третье поле указывает на владельца файла (user). Четвёртое поле указывает на группу, которая владеет этим файлом (users). Последнее поле указывает имя файла. Для вызова справки команда `ls --help`.
<imagesrc="assets/L1P1_1.jpg">
@ -195,11 +195,11 @@
*Рисунок 2 – Форма вывода прав доступа*
Права доступа и информация о типе файла в UNIX-системах хранятся в индексных дескрипторах в отдельной структуре, состоящей из двух байтов, т. е. из 16 бит. Четыре бита из этих 16-ти отведены для кодированной записи о типе файла. Следующие три бита задают особые свойства исполняемых файлов, о которых мы скажем чуть позже. И, наконец, оставшиеся 9 бит определяют права доступа к файлу. Эти 9 бит разделяются на 3 группы по три бита. Первые три бита задают права пользователя, следующие три бита – права группы, последние 3 бита определяют права всех остальных пользователей (т. е. всех пользователей, за исключением владельца файла и группы файла). Если соответствующий бит имеет значение 1, то право предоставляется, а если он равен 0, то право не предоставляется. В символьной форме записи прав единица заменяется соответствующим символом (r, w или x), а 0 представляется прочерком.
Права доступа и информация о типе файла в UNIX-системах хранятся в индексных дескрипторах в отдельной структуре, состоящей из двух байтов, т. е. из 16 бит. Четыре бита из этих 16-ти отведены для кодированной записи о типе файла. Следующие три бита задают особые свойства исполняемых файлов, о которых мы скажем чуть позже. И, наконец, оставшиеся 9 бит определяют права доступа к файлу. Эти 9 бит разделяются на 3 группы по три бита. Первые три бита задают права пользователя, следующие три бита – права группы, последние 3 бита определяют права всех остальных пользователей (т. е. всех пользователей, за исключением владельца файла и группы файла). Если соответствующий бит имеет значение 1, то право предоставляется, а если он равен 0, то право не предоставляется. В символьной форме записи прав единица заменяется соответствующим символом (*r*, *w* или *x*), а 0 представляется прочерком.
Право на чтение (r) файла означает, что пользователь может просматривать содержимое файла с помощью различных команд просмотра, например, командой more или с помощью любого текстового редактора. Но сохранить изменения в файле на диске возможно, только если есть права на запись (w) в этот файл. Право на выполнение (x) означает, что вы можете загрузить файл в память и попытаться запустить его на выполнение как исполняемую программу. Конечно, если в действительности файл не является программой (или скриптом shell), то запустить этот файл на выполнение не удастся, но, с другой стороны, даже если файл действительно является программой, но право на выполнение для него не установлено, то он тоже не запустится.
Право на чтение (*r*) файла означает, что пользователь может просматривать содержимое файла с помощью различных команд просмотра, например, командой more или с помощью любого текстового редактора. Но сохранить изменения в файле на диске возможно, только если есть права на запись (*w*) в этот файл. Право на выполнение (*x*) означает, что вы можете загрузить файл в память и попытаться запустить его на выполнение как исполняемую программу. Конечно, если в действительности файл не является программой (или скриптом *shell*), то запустить этот файл на выполнение не удастся, но, с другой стороны, даже если файл действительно является программой, но право на выполнение для него не установлено, то он тоже не запустится.
В Linux каталоги – те же файла, поэтому если выполнить команду ls –l для каталога, то, также как для файла, получим список прав доступа, причем они задаются теми же самыми символами rwx. Естественно, что по отношению к каталогам трактовка понятий "право на чтение", "право на запись" и "право на выполнение" несколько изменяется. Право на чтение по отношению к каталогам легко понять, если вспомнить, что каталог – это просто файл, содержащий список файлов в данном каталоге. Следовательно, если вы имеете право на чтение каталога, то вы можете просматривать его содержимое (этот самый список файлов в каталоге). Право на запись тоже понятно – имея такое право, вы сможете создавать и удалять файлы в этом каталоге, т. е. просто добавлять в каталог или удалять из него запись, содержащую имя какого-то файла и соответствующие ссылки. Право на выполнение интуитивно менее понятно. Оно в данном случае означает право переходить в этот каталог. Если вы, как владелец, хотите дать доступ другим пользователям на просмотр какого-то файла в своем каталоге, вы должны дать им право доступа в каталог, т. е. дать им "право на выполнение каталога". Более того, надо дать пользователю право на выполнение для всех каталогов, стоящих в дереве выше данного каталога. Поэтому в принципе для всех каталогов по умолчанию устанавливается право на выполнение как для владельца и группы, так и для всех остальных пользователей. И, уж если вы хотите закрыть доступ в каталог, то лишите всех пользователей (включая группу) права входить в этот каталог. Разница прав на чтение и выполнения есть. Если задать только право на выполнение, вы сможете войти в каталог, но не увидите там ни одного файла.
В Linux каталоги – те же файла, поэтому если выполнить команду `ls –l` для каталога, то, также как для файла, получим список прав доступа, причем они задаются теми же самыми символами rwx. Естественно, что по отношению к каталогам трактовка понятий "право на чтение", "право на запись" и "право на выполнение" несколько изменяется. Право на чтение по отношению к каталогам легко понять, если вспомнить, что каталог – это просто файл, содержащий список файлов в данном каталоге. Следовательно, если вы имеете право на чтение каталога, то вы можете просматривать его содержимое (этот самый список файлов в каталоге). Право на запись тоже понятно – имея такое право, вы сможете создавать и удалять файлы в этом каталоге, т. е. просто добавлять в каталог или удалять из него запись, содержащую имя какого-то файла и соответствующие ссылки. Право на выполнение интуитивно менее понятно. Оно в данном случае означает право переходить в этот каталог. Если вы, как владелец, хотите дать доступ другим пользователям на просмотр какого-то файла в своем каталоге, вы должны дать им право доступа в каталог, т. е. дать им "право на выполнение каталога". Более того, надо дать пользователю право на выполнение для всех каталогов, стоящих в дереве выше данного каталога. Поэтому в принципе для всех каталогов по умолчанию устанавливается право на выполнение как для владельца и группы, так и для всех остальных пользователей. И, уж если вы хотите закрыть доступ в каталог, то лишите всех пользователей (включая группу) права входить в этот каталог. Разница прав на чтение и выполнения есть. Если задать только право на выполнение, вы сможете войти в каталог, но не увидите там ни одного файла.
Алгоритм проверки прав пользователя при обращении к файлу можно описать следующим образом. Система вначале проверяет, совпадает ли имя пользователя с именем владельца файла. Если эти имена совпадают (т. е. владелец обращается к своему файлу), то проверяется, имеет ли владелец соответствующее право доступа: на чтение, на запись или на выполнение (не удивляйтесь, суперпользователь может лишить некоторых прав и владельца файла). Если право такое есть, то соответствующая операция разрешается. Если же нужного права владелец не имеет, то проверка прав, предоставляемых через группу или через группу атрибутов доступа для остальных пользователей, уже даже не проверяются, а пользователю выдается сообщение о невозможности выполнения затребованного действия.
@ -269,7 +269,7 @@
[user]$ chmod +x file_name
```
Второй вариант задания команды chmod (он используется чаще) основан на цифровом представлении прав. Для этого мы кодируем символ r цифрой 4, символ w – цифрой 2, а символ x – цифрой 1. Чтобы предоставить пользователям какой-то набор прав, надо сложить соответствующие цифры. Получив, таким образом, нужные цифровые значения для владельца файла, для группы файла и для всех остальных пользователей, задаем эти три цифры в качестве аргумента команды chmod (ставим эти цифры после имени команды перед вторым аргументом, который задает имя файла). Например, если надо дать все права владельцу (4+2+1=7), право на чтение и запись – группе (4+2=6), и не давать никаких прав остальным, то следует дать такую команду:
Второй вариант задания команды *chmod* (он используется чаще) основан на цифровом представлении прав. Для этого мы кодируем символ **r** цифрой 4, символ **w** – цифрой 2, а символ **x** – цифрой 1. Чтобы предоставить пользователям какой-то набор прав, надо сложить соответствующие цифры. Получив, таким образом, нужные цифровые значения для владельца файла, для группы файла и для всех остальных пользователей, задаем эти три цифры в качестве аргумента команды *chmod* (ставим эти цифры после имени команды перед вторым аргументом, который задает имя файла). Например, если надо дать все права владельцу (4+2+1=7), право на чтение и запись – группе (4+2=6), и не давать никаких прав остальным, то следует дать такую команду:
```ssh
[user]$ chmod 760 file_name
@ -291,7 +291,7 @@ rwx --- --- = 700
Первый из этих атрибутов – так называемый "бит смены идентификатора пользователя". Смысл этого бита состоит в следующем.
Ообычно, когда пользователь запускает некоторую программу на выполнение, эта программа получает те же права доступа к файлам и каталогам, которые имеет пользователь, запустивший программу. Если же установлен "бит смены идентификатора пользователя", то программа получит права доступа к файлам и каталогам, которые имеет владелец файла программы (таким образом, рассматриваемый атрибут лучше называть "битом смены идентификатора владельца"). Это позволяет решать некоторые задачи, которые иначе было бы трудно выполнить. Самый характерный пример – команда смены пароля passwd. Все пароли пользователей хранятся в файле /etc/passwd, владельцем которого является суперпользователь root. Поэтому программы, запущенные обычными пользователями, в том числе команда passwd, не могут производить запись в этот файл. А, значит, пользователь как бы не может менять свой собственный пароль. Но для файла /usr/bin/passwd установлен "бит смены идентификатора владельца", каковым является пользователь root. Следовательно, программа смены пароля passwd запускается с правами root и получает право записи в файл /etc/passwd (уже средствами самой программы обеспечивается то, что пользователь может изменить только одну строку в этом файле).
Ообычно, когда пользователь запускает некоторую программу на выполнение, эта программа получает те же права доступа к файлам и каталогам, которые имеет пользователь, запустивший программу. Если же установлен "бит смены идентификатора пользователя", то программа получит права доступа к файлам и каталогам, которые имеет владелец файла программы (таким образом, рассматриваемый атрибут лучше называть "битом смены идентификатора владельца"). Это позволяет решать некоторые задачи, которые иначе было бы трудно выполнить. Самый характерный пример – команда смены пароля *passwd*. Все пароли пользователей хранятся в файле `/etc/passwd`, владельцем которого является суперпользователь *root*. Поэтому программы, запущенные обычными пользователями, в том числе команда *passwd*, не могут производить запись в этот файл. А, значит, пользователь как бы не может менять свой собственный пароль. Но для файла `/usr/bin/passwd` установлен "бит смены идентификатора владельца", каковым является пользователь root. Следовательно, программа смены пароля passwd запускается с правами root и получает право записи в файл `/etc/passwd` (уже средствами самой программы обеспечивается то, что пользователь может изменить только одну строку в этом файле).
Установить "бит смены идентификатора владельца" может суперпользователь с помощью команды
@ -303,7 +303,7 @@ rwx --- --- = 700
Еще один возможный атрибут исполняемого файла – это "бит сохранения задачи" или "sticky bit" (дословно – "бит прилипчивости"). Этот бит указывает системе, что после завершения программы надо сохранить ее в оперативной памяти. Удобно включить этот бит для задач, которые часто вызываются на выполнение, так как в этом случае экономится время на загрузку программы при каждом новом запуске. Этот атрибут был необходим на старых моделях компьютеров. На современных быстродействующих системах он используется редко.
Если используется цифровой вариант задания атрибутов в команде chmod, то цифровое значение этих атрибутов должно предшествовать цифрам, задающим права пользователя:
Если используется цифровой вариант задания атрибутов в команде `chmod`, то цифровое значение этих атрибутов должно предшествовать цифрам, задающим права пользователя:
```ssh
[root]# chmod 4775 file_name
@ -360,8 +360,10 @@ echo “данные_для_ввода_в_ковычках_пишем” > на
- для файла 1.txt установить запрет доступа всем, полные права root и право запуска для группы root: «setfacl -m "u::-,o::-,g::-,u:root:rwx,g:root:x" 1.txt)».
- для файла *1.txt* установить запрет доступа всем, полные права *root* и право запуска для группы *root*:
Популярные значения прав доступа (2-4 символ в цифровой маске доступа):
@ -464,23 +466,23 @@ find ~ -ls
### 1. Теоретическая часть
SSH или Secure Shell — это зашифрованный протокол, который часто используется для взаимодействия и удаленного управления серверами. Если вы захотите что-либо сделать на удаленном сервере, скорее всего, вам придется воспользоваться SSH и работать через терминал.
**SSH** или **Secure Shell** — это зашифрованный протокол, который часто используется для взаимодействия и удаленного управления серверами. Если вы захотите что-либо сделать на удаленном сервере, скорее всего, вам придется воспользоваться SSH и работать через терминал.
В SSH существует несколько способов авторизации:
- по IP-адресу клиента
- по публичному ключу
- стандартный парольный метод
Вы можете каждый раз вводить пароль пользователя или использовать более безопасный и надежный способ — ключи SSH. Как работает ssh версии 2:
Вы можете каждый раз вводить пароль пользователя или использовать более безопасный и надежный способ — ключи SSH. Как работает SSH версии 2:
При запросе клиента сервер сообщает ему, какие методы аутентификации он поддерживает (это определяется в опции PreferredAuthentications sshd.conf) и клиент по очереди пытается проверить их. По умолчанию клиент вначале пытается аутентифицироваться своим адресом, затем публичным ключом и, если ничего не сработало, передаёт пароль, введённый с клавиатуры (при этом пароль шифруется асимметрическим шифрованием). После прохождения аутентификации одним из методов из имеющихся у клиента и сервера пар ключей генерируется ключ симметрического шифрования, который, генерируется на основании своего секретного и удалённого публичного ключей. После чего все последующие данные, передаваемые через ssh, шифруются данным ключом (обычно используется алгоритм AES с длиной ключа 128 бит). Протокол ssh версии 1 имел некоторые баги в шифровании передаваемого трафика и являлся по сути методом безопасной аутентификации, поэтому по современным меркам данный протокол считается небезопасным. Протокол версии 2 поддерживает более современные методы шифрования трафика, также вместе с данными посылаются контрольные суммы формата SHA, что исключает подмену или иную модификацию передаваемого трафика(чего не было у SSH версии 1).
При запросе клиента сервер сообщает ему, какие методы аутентификации он поддерживает (это определяется в опции *PreferredAuthentications sshd.conf*) и клиент по очереди пытается проверить их. По умолчанию клиент вначале пытается аутентифицироваться своим адресом, затем публичным ключом и, если ничего не сработало, передаёт пароль, введённый с клавиатуры (при этом пароль шифруется асимметрическим шифрованием). После прохождения аутентификации одним из методов из имеющихся у клиента и сервера пар ключей генерируется ключ симметрического шифрования, который, генерируется на основании своего секретного и удалённого публичного ключей. После чего все последующие данные, передаваемые через SSH, шифруются данным ключом (обычно используется алгоритм AES с длиной ключа 128 бит). Протокол SSH версии 1 имел некоторые баги в шифровании передаваемого трафика и являлся по сути методом безопасной аутентификации, поэтому по современным меркам данный протокол считается небезопасным. Протокол версии 2 поддерживает более современные методы шифрования трафика, также вместе с данными посылаются контрольные суммы формата SHA, что исключает подмену или иную модификацию передаваемого трафика(чего не было у SSH версии 1).
### 1.1. Идентификация по адресу клиента
При данном способе аутентификации происходит следующее:
каждый клиент и сервер имеют свои пары ключей RSA, которые называются ключи хоста. При этом существует несколько методов проверки адреса клиента.
Сервер смотрит файлы `$HOME/.rhosts`, `$HOME/.shosts`, `/etc/hosts.equiv` или `/etc/ssh/shosts.equiv`, если же сервер настроен на проверку ключей клиентов(а это нужно в соображениях безопасности, т.к. иначе злоумышленник может подменить IP клиента на свой), то он дополнительно проверяет `/etc/ssh/ssh_known_hosts` и `$HOME/.ssh/known_hosts`. Естественно, что файлы, расположенные в домашних каталогах сервера, действуют на пользователя, в чьём каталоге они размещены, а файлы, расположенные в /etc имеют глобальный эффект. Синтаксис вышеперечисленных файлов:
Сервер смотрит файлы `~/.rhosts`, `~/.shosts`, `/etc/hosts.equiv` или `/etc/ssh/shosts.equiv`, если же сервер настроен на проверку ключей клиентов(а это нужно в соображениях безопасности, т.к. иначе злоумышленник может подменить IP клиента на свой), то он дополнительно проверяет `/etc/ssh/ssh_known_hosts` и `~/.ssh/known_hosts`. Естественно, что файлы, расположенные в домашних каталогах сервера, действуют на пользователя, в чьём каталоге они размещены, а файлы, расположенные в `/etc` имеют глобальный эффект. Синтаксис вышеперечисленных файлов:
- **.rhosts** - определяет адрес машины и имя пользователя, с которой данному пользователю открыт доступ (файл расположен в домашнем каталоге пользователя )
@ -503,7 +505,7 @@ null.test.ru user1
Знак **+** означает разрешение пользователю работать с сервером с данного адреса, знак **-** запрещает подобное действие.
/etc/ssh/ssh_known_hosts и $HOME/.ssh/known_hosts - данные файлы содержат список адресов и соответствующих им публичных ключей. При запросе клиента сервер генерирует рандомную строку и шифрует её публичным ключом удалённого хоста. Клиент, получив данную строку, расшифровывает её своим секретным ключом (который имеется только у него) и зашифровывает полученную строку ключом сервера. Сервер получает зашифрованное сообщение, расшифровывает своим секретным ключом и сравнивает с исходной. Если строки совпали, то клиент имеет валидный секретный ключ, что даёт ему право захода на данный сервер. Но для начала клиент должен иметь правильный адрес, которому соответствует публичный ключ на сервере в файле ssh_known_hosts. Файл состоит из 3-х полей: адрес(или адреса, разделённые запятой), публичный ключ для него одной(!) строкой и дополнительное поле комментариев(необязательно). Пример файла known_hosts:
`/etc/ssh/ssh_known_hosts` и `~/.ssh/known_hosts` - данные файлы содержат список адресов и соответствующих им публичных ключей. При запросе клиента сервер генерирует рандомную строку и шифрует её публичным ключом удалённого хоста. Клиент, получив данную строку, расшифровывает её своим секретным ключом (который имеется только у него) и зашифровывает полученную строку ключом сервера. Сервер получает зашифрованное сообщение, расшифровывает своим секретным ключом и сравнивает с исходной. Если строки совпали, то клиент имеет валидный секретный ключ, что даёт ему право захода на данный сервер. Но для начала клиент должен иметь правильный адрес, которому соответствует публичный ключ на сервере в файле *ssh_known_hosts*. Файл состоит из 3-х полей: адрес(или адреса, разделённые запятой), публичный ключ для него одной(!) строкой и дополнительное поле комментариев(необязательно). Пример файла known_hosts:
Адрес клиента должен быть в полном формате(name.domain), иначе могут быть проблемы. Кроме этого, в адресе можно использовать шаблоны * и ?. Публичные ключи вставляются в данный файл самим администратором из генерированных клиентом ssh(identity.pub) публичных ключей. Вообще создание ssh_known_hosts - это прерогатива администратора(root).
При аутентификации по хосту лучше использовать ssh_known_hosts, т.к. этот метод достаточно безопасен, если публичные ключи клиентов были получены из доверенного источника. Другие методы аутентификации не исключают подмену адреса, и потому считаются небезопасными.
При аутентификации по хосту лучше использовать *ssh_known_hosts*, т.к. этот метод достаточно безопасен, если публичные ключи клиентов были получены из доверенного источника. Другие методы аутентификации не исключают подмену адреса, и потому считаются небезопасными.
### 1.2. Аутентификация пользователя по его публичному ключу
Каждая пара ключей состоит из открытого и закрытого ключа. Секретный ключ сохраняется на стороне клиента и не должен быть доступен кому-либо еще. Утечка ключа позволит злоумышленнику войти на сервер, если не была настроена дополнительная аутентификация по паролю.
Открытый ключ используется для шифрования сообщений, которые можно расшифровать только закрытым ключом. Это свойство и используется для аутентификации с помощью пары ключей. Открытый ключ загружается на удаленный сервер, к которому необходимо получить доступ. Его нужно добавить в специальный файл ~/.ssh/authorized_keys или в директорию ~/.ssh/<имя_ключа>
Открытый ключ используется для шифрования сообщений, которые можно расшифровать только закрытым ключом. Это свойство и используется для аутентификации с помощью пары ключей. Открытый ключ загружается на удаленный сервер, к которому необходимо получить доступ. Его нужно добавить в специальный файл `~/.ssh/authorized_keys` или в директорию `~/.ssh/<имя_ключа>`
Когда клиент попытается выполнить проверку подлинности через этот ключ, сервер отправит сообщение, зашифрованное с помощью открытого ключа, если клиент сможет его расшифровать и вернуть правильный ответ — аутентификация пройдена.
