Система защиты от несанкционированного доступа

Общие принципы аутентификации в Windows. Локальная и доменная регистрация. Аутентификация в Linux. Права доступа к файлам и реестру. Транзакции, примитивы, цепочки и политики. Основные компоненты дескриптора защиты. Хранение и шифрование паролей.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 13.06.2013
Размер файла 62,6 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Федеральное агентство по образованию Российской Федерации

Государственное образовательное учреждение высшего профессионального образования

Волгоградский Государственный Технический Университет

(ВолгГТУ)

Кафедра «Программное Обеспечение Автоматизированных Систем»

Семестровое задание по курсу «Операционные системы»

Система защиты от несанкционированного доступа

Научный руководитель

асс. каф. ПОАС

Иванов. И.И.

Исполнитель

студент гр. АУЗ-461

Петров П.П.

Волгоград 2010г.

Аутентификация в Windows

Аутентификация -- это незаменимая процедура для каждого пользователя, компьютера и служебной учетной записи Windows. Каждый знает, что для регистрации в компьютере необходимо указать верный пароль, но многим ли известно, что происходит потом? Аутентификация Windows и связанные с ней протоколы активизируются каждый раз, когда пользователь, компьютер или служба регистрируются локально или на контроллере домена (DC).

Общие принципы

Аутентификация представляет собой один из компонентов любой компьютерной системы управления доступом. Как показано на схеме, системы управления доступом обеспечивают идентификацию, аутентификацию, авторизацию и отчетность.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Идентификация. В процессе идентификации используется набор данных, который уникально идентифицирует объект безопасности (например, пользователя, группу, компьютер, учетную запись службы) в общей службе каталогов. Служба каталогов, такая как Active Directory (AD), позволяет уникально идентифицировать объекты, подобно тому как DNS удостоверяет, что два человека не могут иметь одинаковые адреса электронной почты. Во внутренних механизмах Windows используются SID, глобально уникальные идентификаторы (globally unique identifier, GUID) и другие уникальные тэги. В большинстве случаев для идентификации достаточно ввести уникальное имя учетной записи, такое как Rgrimes. В большом лесу AD приходится применять полные имена пользователей (user principal name, UPN), например rgrimes@banneretcs.com. При использовании смарт-карт субъект безопасности может представить свой цифровой сертификат или ключ.

Аутентификация или проверка подлинности. После того как субъект безопасности вводит с клавиатуры или иным способом предоставляет необходимую для идентификации информацию (например, имя пользователя, маркер безопасности), он должен ввести с клавиатуры или представить частную информацию для аутентификации (например, пароль или PIN-код). В Windows субъект безопасности вводит эту информацию на экране регистрации с помощью программ Microsoft Graphical Identification and Authentication DLL (msgina.dll) и Winlogon.exe. Протокол аутентификации и механизм системы кодируют представленную информацию на настольном компьютере и передают запрос аутентификации. Служба аутентификации Windows может быть базой данных SAM или AD. База данных SAM обслуживает локальные процедуры регистрации и регистрацию на контроллерах домена Windows NT 4.0. AD аутентифицирует запросы в Windows 2000 или доменах более поздних версий этой операционной системы. Протокол аутентификации (например, LAN Manager, NT LAN Manager, NTLM, NTLMv2, Kerberos) используется для транспортировки запросов аутентификации и последующих транзакций между экраном регистрации и службой аутентификации.

Авторизация. Если служба аутентификации удостоверяет комбинацию идентификатора и «секретных» данных аутентификации, то подлинность субъекта безопасности считается успешно подтвержденной. Затем система собирает информацию о членстве субъекта безопасности (т. е. пользователя) в группах. Нередко пользователь принадлежит к нескольким точно определенным группам -- локальным (local), доменным (domain local), глобальным (global) и универсальным (universal) -- в результате обычных процедур назначения членства. Система сверяет локальные группы с локальной базой данных SAM и проверяет локальные и глобальные группы на контроллерах DC в домашнем домене пользователя, а также универсальные группы на DC, который содержит глобальный каталог Global Catalog. Прямо или косвенно система собирает все сведения о членстве в группах, чтобы получить информацию о разрешениях безопасности.

Сразу после аутентификации система собирает идентификаторы SID учетной записи и сведения о членстве в группах в объекте, называемом маркером доступа (access token). Возможно, пользователю придется выйти и вновь зарегистрироваться в системе, чтобы новые разрешения безопасности вступили в силу. Если пользователю нужно получить доступ к объекту (например, файлу, папке, принтеру, разделу реестра), защищенному разрешениями NTFS, то процесс (например, Windows Explorer), выступающий от имени пользователя, предоставляет свой маркер доступа. Каждый объект NTFS располагает списком элементов управления доступом (access control entry, ACE), которые, в сущности, представляют собой знакомые разрешения NTFS (например, Allow Read, Allow Write). Набор элементов ACE, назначенных пользователям и группам, составляет список управления доступом (ACL) данного объекта..

Маркер доступа, содержащий учетную запись и группы, с которыми связан пользователь, определяет эффективные разрешения пользователя. Процесс авторизации заключается в разрешении или отказе в доступе к определенному объекту на основе сравнения маркера доступа с ACL объекта. Авторизацию обеспечивает Security Reference Monitor системы Windows.

Отчетность. Если в Windows активизирован режим аудита, то система сохраняет событие аутентификации в журнале Security, и это последний компонент системы управления доступом -- отчетность. Большинство сложных событий начальной регистрации и последующей авторизации происходят за несколько секунд и скрыты от пользователя. Все сложные операции возлагаются на протокол аутентификации, в задачи которого входит безопасная передача транзакции от запросчика в базу данных аутентификации и на любой другой компьютер, на котором размещен соответствующий ресурс. И безопасное и надежное хранение пароля или маркера.

Протокол аутентификации должен защитить введенную пользователем информацию при пересылке в базу данных аутентификации (т. е. SAM или AD). Для этого протокол подписывает, скрывает или шифрует транзакцию. Кроме того, ей присваивается временная метка.

В течение более чем десяти лет протоколы аутентификации в основном обеспечивали защиту путем сохранения паролей в скрытой форме (обычно хешированной) в базе данных аутентификации и полного запрета на передачу паролей между запросчиком и базой данных аутентификации простым текстом (даже в скрытой форме). Процесс запрос--ответ выглядит следующим образом:

1. Компьютер получает данные для идентификации и аутентификации от пользователя и запрашивает аутентификацию на соответствующем сервере.

2. Сервер аутентификации генерирует случайное произвольное значение (называемое запросом - challenge) и посылает его запросчику.

3. Запросчик получает запрос и производит над ним и скрытой формой пароля математические операции, а затем передает результат (называемый ответом - response) серверу аутентификации.

4. Сервер аутентификации также выполняет математические манипуляции с запросом методом, идентичным используемому на рабочей станции, и сравнивает результат с полученным ответом. Если результаты совпадают, то запросчик считается успешно аутентифицированным.

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

Локальная и доменная регистрация

При регистрации пользователя одна из первых задач Windows -- определить, относится ли процедура только к локальной машине или к учетной записи домена. Пользователи, регистрирующиеся от имени локальной учетной записи, имеют доступ только к ресурсам своего компьютера и только если информация об учетной записи пользователя содержится в локальной базе данных SAM. Если пользователям нужно обратиться к ресурсам на удаленном компьютере без аутентификации в домене, то их учетные записи должны быть продублированы в локальной базе данных SAM каждого доступного компьютера. Учетные записи в каждом компьютере-участнике должны быть синхронизированы (одинаковые имена регистрации, пароли и сроки действия учетных данных на всех машинах). В противном случае положение значительно усложняется. Трудно обслуживать одноранговые (P2P) сети средних размеров, в которых применяются только локальные процедуры регистрации.

На DC не распространяется требование синхронизации нескольких учетных записей пользователей на разных компьютерах. При доменной аутентификации компьютеры, зарегистрированные в домене, отыскивают контроллеры DC, чтобы предъявить учетные данные доменной учетной записи пользователя при запросах аутентификации. Таким образом, если удаленный пользователь пытается получить доступ к локальному ресурсу какой-нибудь машины, то этот компьютер просит DC проверить идентичность запрашивающего пользователя. Учетные записи пользователя домена располагаются только на DC и создаются лишь один раз. Любой компьютер-участник, которому нужно удостоверить учетную запись в домене, может обратиться к контроллерам DC в любое время. Проблемы синхронизации имен регистрации, паролей и сроков их действия не возникает, так как учетные данные и управление учетной записью осуществляются только в одном месте -- на DC. Независимо от типа регистрации (локальной или доменной), Windows должна аутентифицировать запрос пользователя.

Ниже представлен процесс защищенной NT challenge/response (NTLM) аутентификацию, при этом процедура входа в сеть (если сетью управляет сервер) следующая:

1. Компьютер передает серверу запрос об аутентификации пользователя.

2. Сервер генерирует случайную 8-байтовую последовательность данных (так называемый "Challenge") и передает его компьютеру.

3. Компьютер, получив Challenge, на основе его и пароля, который ввел пользователь с помощью функций хэширования генерирует LanMan Hash (а при отключении формирования LanMan Hash генерируется NT Hash). В этом случае длина хэша составляет уже 24 байта.

4. Компьютер передает полученный хэш серверу.

5. Сервер, в свою очередь, также генерирует хэш, используя те же входные данные (пароль, хранящийся на сервере и Challenge, который в пределах одной сессии одинаковый для сервера и для компьютера-клиента).

6. Затем сервер сверяет оба полученных хэша и возвращает результат аутенфикации.

Аутентификация в Linux

В UNIX-подобных системах осуществляется посредством Подключаемых Модулей Аутентификации.

Библиотека Pluggable Authentication Modules (PAM) является обобщённым API для служб, связанных с аутентификацией, которые позволяют системному администратору добавлять новые методы аутентификации простой установкой новых модулей PAM, и изменять политику аутентификации посредством редактирования конфигурационных файлов.

Терминология, используемая в PAM, достаточно запутана. Первой попыткой создать недвусмысленную и согласованную терминологию была работа, которую написал Andrew G. Morgan (автор Linux-PAM) в 1999 году. Выбор терминологии, которую сделал Морган, был гигантским скачком вперед.

Термин

Значение

account

Учётная запись. Набор полномочий, которые аппликант запрашивает от арбитратора.

applicant

Аппликант. Пользователь или объект, запрашивающие аутентификацию.

arbitrator

Арбитратор. Пользователь или объект, имеющий привилегии, достаточные для проверки полномочий аппликанта и права подтвердить или отклонить запрос.

chain

Цепочка. Последовательность модулей, которые будут вызваны в ответ на запрос PAM. В цепочку включена информация о последовательности вызовов модулей, аргументах, которые нужно им передать, и о том, как интерпретировать результаты.

client

Клиент. Приложение, отвечающее за инициирование запроса на аутентификацию от имени аппликанта и получающее от него необходимую для аутентификации информацию.

facility

Подсистема. Одна из четырех основных групп функциональности, которые дает PAM: аутентификация, управление учетными записями, управление сеансом и обновление ключом аутентификации.

module

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

policy

Политика. Полный набор конфигурационных деклараций, описывающих, как обрабатывать запросы PAM к определенной услуге. Политика обычно состоит из четырех цепочек, по одной для каждой подсистемы, хотя некоторые службы используют не все четыре подсистемы.

server

Сервер. Приложение, выступающее от имени арбитратора для общения с клиентом, запрашивания аутентификационной информации, проверки полномочий аппликанта и подтверждающее или отклоняющее запрос.

service

Сервис. Класс серверов, предоставляющих похожую или связанную функциональность, и требующую подобную аутентификацию. Политики PAM задаются на основе сервисов, так что ко всем серверам, объявляющим одно и тоже имя сервиса, будет применяться одна и та же политика.

session

Сеанс. Контекст, в котором сервис оказывается аппликанту сервером. Одна из четырех подсистем PAM, управление сеансом, касается исключительно настройке и очистке этого контекста.

token

Ключ. Блок информации, связанный с учётной записью, например, пароль или ключевая фраза, которую аппликант должен предоставить для своей идентификации.

transaction

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

Подсистемы и примитивы

API для PAM предоставляет шесть различных примитивов для аутентификации, сгруппированных в четыре подсистемы, каждая из которых описывается ниже.

auth

Аутентификация. Эта подсистема, собственно говоря, реализует аутентификацию аппликанта и выяснение полномочий учётной записи. Она предоставляет два примитива:

Функция pam_authenticate аутентифицирует аппликанта, обычно запрашивая аутентификационный ключ и сравнивая его со значением, хранящимся в базе данных или получаемым от сервера аутентификации.

Функция pam_setcred устанавливает полномочия учётной записи, такие, как идентификатор пользователя, членство в группах и ограничения на использование ресурсов.

account

Управление учётной записью. Эта подсистема обрабатывает вопросы доступности учетной записи, не связанные с аутентификацией, такие, как ограничения в доступе на основе времени суток или загрузки сервера. Он предоставляет единственный примитив:

Функция pam_acct_mgmt проверяет, доступна ли запрашиваемая учётная запись.

session

Управление сеансом. Эта подсистема отрабатывает задачи, связанные с установлением и закрытием сеанса, такие, как учет входов пользователей. Она предоставляет два примитива:

Функция pam_open_session выполняет действия, связанные с установлением сеанса: добавление записей в базы данных utmp и wtmp, запуск агента SSH и так далее.

Функция pam_close_session выполняет действия, связанные с закрытием сеанса: добавление записей в базы данных utmp и wtmp, завершение работы агента SSH и так далее.

password

Управление паролем. Эта подсистема используется для изменения ключа аутентификации, связанного с учетной записью, по причине истечения его срока действия или желания пользователя изменить его. Она предоставляет единственный примитив:

Функция pam_chauthtok изменяет ключ аутентификации, опционально проверяя, что он труден для подбора, не использовался ранее и так далее.

Цепочки и политики

Когда сервер инициирует PAM-транзакцию, библиотека PAM пытается загрузить политику для службы, указанной при вызове функции pam_start. Политика определяет, как должны обрабатываться запросы на аутентификацию, и задаётся в конфигурационном файле. Это составляет другую основополагающую концепцию PAM: возможность администратору настраивать политику безопасности системы (в самом широком её понимании) простым редактированием текстового файла.

Политика состоит из четырёх цепочек, по одной на каждый из методов PAM. Каждое звено представляет собой последовательность конфигурационных утверждений, задающих вызываемый модуль, некоторые (необязательные) параметры для передачи в модуль, и управляющий флаг, описывающий, как интерпретировать возвращаемый из модуля код.

Понимание смысла управляющего флага необходимо для понимания конфигурационных файлов PAM. Существуют четыре различных управляющих флага:

binding

Если модуль отработал успешно, и ни один из предыдущих модулей в цепочке не сработал отрицательно, то цепочка прерывается, а запрос подтверждается. Если же модуль отработает неудачно, то выполняется оставшаяся часть цепочки, однако запрос отвергается.

required

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

requisite

Если модуль возвращает положительный ответ, выполняется оставшаяся часть цепочки, запрос удовлетворяется, если никакой другой модуль не отработает отрицательно. Если же модуль отрабатывает отрицательно, то отработка цепочки немедленно прекращается, а запрос отвергается.

sufficient

Если модуль возвратит положительный ответ, и ни один из предыдущих модулей в цепочке на отработал отрицательно, то отработка цепочки немедленно прекращается, а запрос удовлетворяется. Если модуль отработал отрицательно, то результат игнорируется и цепочка отрабатывается дальше.

optional

Модуль отрабатывается, но результат выполнения игнорируется. Если все модули в цепочке помечены как optional, то удовлетворяться будут все запросы.

Когда сервер вызывает один из шести PAM-примитивов, PAM запрашивает цепочку подсистемы, к которой принадлежит примитив, и запускает каждый модуль, перечисленный в цепочке в порядке их перечисления, пока список не будет исчерпан либо не будет определено, что дальнейшей обработки не нужно (по причине достижение модуля, вернувшего положительный ответ при условии binding или sufficient, либо отрицательный с условием requisite). Запрос подтверждается, если только был вызван по крайней мере один модуль, и все неопциональные модули вернули положительный ответ.

Модуль, просматривающий имена и пароли пользователя в сервере каталога может быть вызван несколько раз с различными параметрами, задающими различные серверы каталогов для связи. PAM считает различные появления одного модуля в той же самой цепочке разными и не связанными модулями.

Транзакции

Типичноя PAM-транзакция:

1. Сервер вызывает функцию pam_start для инициализации библиотеки PAM и задания имени сервиса и целевой учётной записи, а также регистрации подходящего способа общения.

2. Сервер получает различную информацию, относящуюся к транзакции (такую, как имя пользователя аппликанта и имя хоста, на котором запущен клиент), и отправляет её в PAM при помощи функции pam_set_item.

3. Сервер вызывает функцию pam_authenticate для аутентификации аппликанта.

4. Сервер вызывает функцию pam_acct_mgmt для проверки того, что запрошенная учётная запись доступна и корректна. Если пароль верен, но его срок истёк, pam_acct_mgmt возвратит результат PAM_NEW_AUTHTOK_REQD, а не PAM_SUCCESS.

5. Если на предыдущем шаге был получен результат PAM_NEW_AUTHTOK_REQD, то сервер вызывает функцию pam_chauthtok для того, чтобы вынудить клиента изменить ключ аутентификации для запрошенной учётной записи.

6. Теперь, когда аппликант полностью аутентифицирован, сервер вызывает функцию pam_setcred для получения полномочий запрошенной учётной записи. Сделать это возможно, потому что он работает как арбитратор, и оставляет за собой полномочия арбитратора.

7. После получения необходимых полномочий, сервер вызывает функцию pam_open_session для установления сеанса.

8. Теперь сервер выполняет тот сервис, который затребовал клиент--например, предоставляет аппликанту оболочку.

9. После того, как сервер закончил обслуживание клиента, он вызывает функцию pam_close_session для закрытия сеанса.

10. Наконец, сервер вызывает функцию pam_end для оповещения библиотеки PAM о том, что работа с ней завершена и какие-либо выделенные в течение сеанса ресурсы можно освободить.

Хранение и шифрование паролей

Реализация в Windows:

Информация об учетных записях пользователей хранится в ветке HKEY_LOCAL_MACHINE\SAM (SAM - Security Account Manager) реестра. А так как в Windows все ветки реестра физически расположены на диске в каталоге %SystemRoot%\System32\Config в нескольких файлах, то и эта ветка - не исключение. Она располагается в файле SAM. Этот файл по умолчанию недоступен для чтения никому, даже Администратору. К файлу SAM (а также к остальным файлам без расширений в этой директории - system, software и др.) нет доступа по той причине, что Windows используют реестр "на лету" - т.е. при внесении в реестр изменений они становятся доступны сразу же и перезагрузка компьютера не требуется, но для этого системе нужно иметь монопольный доступ к файлам реестра. Это отличает современные версии Windows от предыдущих (семейства 9x), где реестр хранится в файлах system.dat и user.dat, которые загружаются однократно при загрузке системы и при изменениях в реестре требуется перезагрузка компьютера для того, чтобы эти изменения вступили в силу.

Windows хранит пароли пользователей не в явном виде, а в виде хэшей (hash), т.е. фактически в виде контрольных сумм паролей.

Среди сложной структуры SAM-файла интересна структура, называемая V-блок. Она имеет размер 32 байта и содержит в себе хэш пароля для локального входа - NT Hash длиной 16 байт, а также хэш, используемый при аутентификации доступа к общим ресурсам других компьютеров - LanMan Hash или просто LM Hash, длиной также 16 байт. Алгоритмы формирования этих хэшей следующие:

Формирование NT Hash:

1. Пароль пользователя преобразуется в Unicode-строку.

2. Генерируется хэш на основе данной строки с использованием алгоритма MD4.

3. Полученный хэш шифруется алгоритмом DES, причем в качестве ключа используется RID (т.е. идентификатор пользователя).

Это необходимо для того, чтобы два пользователя с одинаковыми паролями имели разные хэши.

Напомним, что все пользователи имеют разные RID-ы (RID встроенной учетной записи Администратора равен 500, встроенной учетной записи Гостя равен 501, а все остальные пользователи последовательно получают RID-ы, равные 1000, 1001, 1002 и т.д.).

Формирование LM Hash:

1. Пароль пользователя преобразуется в верхний регистр и дополняется нулями до длины 14 байт.

2. Полученная строка делится на две половинки по 7 байт и каждая из них по отдельности шифруется алгоритмом DES, на выходе которого получаем 8-байтный хэш - в сумме же имеем один хэш длиной 16 байт.

3. Далее LM Hash дополнительно шифруется так же, как и в шаге 3 формирования NT Hash.

Для повышения безопасности хранения паролей, начиная с 3-го Service Pack'a в Windows NT (и во всех последующих NT-системах), полученные хэши дополнительно шифруются еще одним алгоритмом с помощью утилиты syskey.

Т.е. к вышеописанным алгоритмам добавляется еще 4-й шаг - получение с помощью syskey нового хэша от хэша, полученного на шаге 3.

Алгоритмы MD4 и DES (применяемые для формирования LM Hash и NT Hash) считаются необратимыми, точнее сказать - их обратимость математически еще не доказана. Поэтому получение паролей из хэшей прямыми математическими методами невозможно. Для злоумышленника остается только одно - перебирать пароли, формировать хэши на основе этих паролей и сравнивать хэши с теми, которые получены из SAM-файла. Если хэши совпадают, то и пароль, который сформировал такой же хэш - верный. Таким образом, для получения пароля Администратора, нужно получить доступ к SAM-файлу, а затем, например, с помощью программы-переборщика паролей, попытаться восстановить нужный пароль.

Сравнение LM и NT Hash'ей

Как было указано, LM Hash формируется на основе "половинок" по 7 символов исходного пароля и имеет максимальную длину исходного пароля в 14 символов. Поэтому для восстановления 14-символьного пароля с алфавитом в N символов нужно перебрать не N14 вариантов, а 2N7 вариантов, что несоизмеримо меньше.

Поэтому "сложный" 14-символьный пароль по LM Hash восстанавливается как два "простых" пароля по 7 символов. Более того - при формировании LM Hash пароль переводится в верхний регистр, поэтому хэши от паролей "ADMIN", "Admin" и "admin" будут одинаковыми!

В этом плане надежность NT Hash намного выше. Здесь пароль не "разбивается" на части и максимальная длина пароля составляет 128 символов. Также учитывается регистр букв пароля. Поэтому вышеприведенные пароли дадут разные хэши.

Соответственно, для восстановления пароля из латинских букв нужно использовать в качестве алфавита уже 52 символа (26 заглавных латинских символов и 26 строчных), а не только 26 заглавных, как при восстановлении пароля по LM Hash.

Также, если пароль пользователя больше 14 символов, то Windows автоматически отключают формирование LM Hash, оставляя только NT Hash. Отключить формирование LM Hash также можно через реестр. В Windows XP, к примеру, для этого нужно в ветви HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa создать параметр "NoLMHash" типа DWORD со значением 1.

Реализация в Linux

Ранее хранение информации о пользователях и паролях хранились в файлах /etc/passwd и /etc/group. На сегодняшний день хранение паролей в файлах passwd и group считается ненадежным. В новых версиях Linux применяются так называемые теневые файлы паролей - shadow и gshаdow. Права на них назначены таким образом, что даже чтение этих фалов без прав суперпользователя невозможно. Нужно учесть, что нормальное функционирование системы при использовании теневых файлов подразумевает одновременно и наличие файлов passwd и group.

Файл shadow хранит защищенную информацию о пользователях, а также обеспечивает механизмы устаревания паролей и учетных записей. Вот структура файла shadow:

username:$1$oAJZcVg0$EGORy8Mh3swT1RfJeX.UR0:13770:10:99999:7:30:99999: (элементы разделены знаком «двоеточие»)

1. имя пользователя

2. шифрованный пароль - применяются алгоритмы хеширования, как правило MD5

3. число дней последнего изменения пароля, начиная с 1 января 1970 года, последнего изменения пароля

4. число дней, перед тем как пароль может быть изменён

5. число дней, после которых пароль должен быть изменён

6. число дней, за сколько пользователя начнут предупреждать, что пароль устаревает

7. число дней, после устаревания пароля для блокировки учётной записи

8. дней, отсчитывая с 1 января 1970 года, когда учётная запись будет заблокирована.

Файл gshadow так же накладывает дополнительную функциональность, вкупе с защищенным хранением паролей групп. Он имеет следующую структуру:

root:$1$QydTRu2w$Cm5gk.6w6nmNdUjerh5pu:root:cisco,oem (элементы разделены знаком «двоеточие»)

1. Имя группы - имя, используемое для удобства использования таких программ, как newgrp.

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

3. Администратор группы - пользователь, имеющий право изменять пароль с помощью gpasswd.

4. Список пользователей - В этом поле через запятую отображаются те пользователи, у которых по умолчанию (в файле /etc/passwd) назначена другая группа.

Права доступа

Реализация в Windows:

В Windows NT администратор может управлять доступом пользователей к каталогам и файлам только в разделах диска, в которых установлена файловая система NTFS. Разделы FAT не поддерживаются средствами защиты Windows NT, так как в FAT у файлов и каталогов отсутствуют атрибуты для хранения списков управления доступом. Доступ к каталогам и файлам контролируется за счет установки соответствующих разрешений. Разрешения в Windows NT бывают индивидуальные и стандартные. Индивидуальные разрешения относятся к элементарным операциям над каталогами и файлами, а стандартные разрешения являются объединением нескольких индивидуальных разрешений.

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

Разрешение

Для каталога

Для файла

Read (R)

Чтение имен файлов и каталогов, входящих в данный каталог, а также атрибутов и владельца каталога

Чтение данных, атрибутов, имени владельца и разрешений файла

Write (W)

Добавление файлов и каталогов, изменение атрибутов каталога, чтение владельца и разрешений каталога

Чтение владельца и разрешений файла, изменение атрибутов файла, изменение и добавление данных файла

Execute (X)

Чтение атрибутов каталога, выполнение изменений в каталогах, входящих в данный каталог, чтение имени владельца и разрешений каталога

Чтение атрибутов файла, имени владельца и разрешений. Выполнение файла, если он хранит код программы

Delete (D)

Удаление каталога

Удаление файла

Change Permission (P)

Изменение разрешений каталога

Изменение разрешений файла

Take Ownership (O)

Стать владельцем каталога

Стать владельцем файла

Для файлов в Windows NT определено четыре стандартных разрешения: No Access, Read, Change и Full Control, которые объединяют индивидуальные разрешения, перечисленные в следующей таблице.

Стандартное разрешение

Индивидуальные разрешения

No Access

Ни одного

Read

RX

Change

RWXD

Full Control

Все

Разрешение Full Control отличается от Change тем, что дает право на изменение разрешений (Change Permission) и вступление во владение файлом (Take Ownership). Для каталогов в Windows NT определено семь стандартных разрешений: No Access, List, Read, Add, Add&Read, Change и Full Control.

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

Стандартные рарешения

Индивидуальные разрешения для каталого

Индивидуальные разрешения для файлов каталого при наследовании

No Access

Ни одного

Ни одного

List

RX

Не определены

Read

RX

RX

Add

WX

Не определены

Add & Read

RWX

RX

Change

RWXD

RWDX

Full Control

Все

Все

При создании файла он наследует разрешения от каталога указанным способом только в том случае, если у каталога установлен признак наследования его разрешений. Стандартная оболочка Windows NT -- Windows Explorer -- не позволяет установить такой признак для каждого разрешения отдельно (то есть задать маску наследования), управляя наследованием по принципу «все или ничего».

Существует ряд правил, которые определяют действие разрешений.

? Пользователи не могут работать с каталогом или файлом, если они не имеют явного разрешения на это или же они не относятся к группе, которая имеет соответствующее разрешение.

? Разрешения имеют накопительный эффект, за исключением разрешения No Access, которое отменяет все остальные имеющиеся разрешения. Например, если группа Engineering имеет разрешение Change для какого-то файла, а группа Finance имеет для этого файла только разрешение Read и Петров является членом обеих групп, то у Петрова будет разрешение Change. Однако если разрешение для группы Finance изменится на No Access, то Петров не сможет использовать этот файл, несмотря на то что он член группы, которая имеет доступ к файлу.

По умолчанию в окнах Windows Explorer находят свое отражение стандартные права, а переход к отражению индивидуальных прав происходит только при выполнении некоторых действий. Это стимулирует администратора и пользователей к использованию тех наборов прав, которые разработчики ОС посчитали наиболее удобными.

транзакция аутентификация доменный пароль

Реализация в Linux

Права доступа определяются по отношению к трём типам действий: чтение, запись и исполнение. Эти права доступа могут быть предоставлены трём классам пользователей: владельцу файла (пользователю), группе, которой принадлежит файл, а также всем остальным пользователям, не входящим в эту группу. Право на чтение даёт пользователю возможность читать содержимое файла или, если такой доступ разрешён к каталогам, просматривать содержимое каталога (используя команду ls). Право на запись даёт пользователю возможность записывать или изменять файл, а право на запись для каталога -- возможность создавать новые файлы или удалять файлы из этого каталога. Наконец, право на исполнение позволяет пользователю запускать файл как программу или сценарий командной оболочки (разумеется, это действие имеет смысл лишь в том случае, если файл является программой или сценарием). Владение правами на исполнение для каталога позволяет перейти (командой cd) в этот каталог.

Чтобы получить информацию о правах доступа, используйте команду ls с ключом -l. При этом будет выведена подробная информация о файлах и каталогах, в которой будут, среди прочего, отражены права доступа.

Пример:

/home/ivanov/docs# ls -l report1303

-rwxr--r-- 1 user1 users 505 Mar 13 19:05 report1303

Первое поле в этой строке (-rw-r--r--) отражает права доступа к файлу. Третье поле указывает на владельца файла (user1), четвёртое поле указывает на группу, которая владеет этим файлом (users). Последнее поле -- это имя файла (report1303). Другие поля описаны в документации к команде ls.

Данный файл является собственностью пользователя user1 и группы users. Последовательность -rwxr--r-- показывает права доступа для пользователя -- владельца файла, пользователей -- членов группы-владельца, а также для всех остальных пользователей.

Первый символ из этого ряда (в данном случае «-» ) обозначает тип файла.

Символ

Тип

-

Обычный файл

d

Каталог

b

Файл блочного устройства

c

Файл символьного устройства

s

Доменное гнездо (socket)

p

Именованный канал (pipe)

l

Символическая ссылка (link)

Далее следуют три группы по три символа, которые и определяют права доступа к файлу соответственно для владельца файла, для группы пользователей, которая сопоставлена данному файлу, и для всех остальных пользователей системы. В нашем примере права доступа для владельца определены как rwx, что означает, что владелец (user1) имеет право читать файл (r), производить запись в этот файл (w), и запускать файл на выполнение (x). Замена любого из этих символов прочерком будет означать, что пользователь лишается соответствующего права. В том же примере мы видим, что все остальные пользователи (включая и тех, которые вошли в группу users) лишены права записи в этот файл, т. е. не могут файл редактировать и вообще как-то изменять.

Вообще говоря, права доступа и информация о типе файла в UNIX-системах хранятся в индексных дескрипторах в отдельной структуре, состоящей из двух байтов, т. е. из 16 бит. Четыре бита из этих 16-ти отведены для кодированной записи о типе файла. Следующие три бита задают особые свойства исполняемых файлов, о которых мы скажем чуть позже. И, наконец, оставшиеся 9 бит определяют права доступа к файлу. Эти 9 бит разделяются на 3 группы по три бита. Первые три бита задают права пользователя, следующие три бита -- права группы, последние 3 бита определяют права всех остальных пользователей (т. е. всех пользователей, за исключением владельца файла и группы файла).

При этом, если соответствующий бит имеет значение 1, то право предоставляется, а если он равен 0, то право не предоставляется. В символьной форме записи прав единица заменяется соответствующим символом (r, w или x), а 0 представляется прочерком.

Право на чтение (r) файла означает, что пользователь может просматривать содержимое файла с помощью различных команд просмотра, например, командой more или с помощью любого текстового редактора. Но, подредактировав содержимое файла в текстовом редакторе, вы не сможете сохранить изменения в файле на диске, если не имеете права на запись (w) в этот файл. Право на выполнение (x) означает, что вы можете загрузить файл в память и попытаться запустить его на выполнение как исполняемую программу. Конечно, если в действительности файл не является программой (или скриптом shell), то запустить этот файл на выполнение не удастся, но, с другой стороны, даже если файл действительно является программой, но право на выполнение для него не установлено, то он тоже не запустится.

Некоторые примеры:

Значение

Описание

- r w x r - x - - x

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

- r w - - - - - - -

Только владелец файла может читать и изменять его.

- r w x r w x r w x

Все пользователи могут читать файл, изменять его и запускать на выполнение.

- - - - - - - - - -

Никто, включая самого владельца файла, не имеет прав на его чтение, запись или выполнение. Хотя такая ситуация вряд ли имеет практический смысл, с точки зрения системы она является вполне корректной. Разумеется, владелец файла может в любой момент изменить права доступа к нему.

Возможность доступа к файлу зависит также от прав доступа к каталогу, в котором находится файл. Например, даже если права доступа к файлу установлены как -rwxrwxrwx, другие пользователи не могут получить доступ к файлу, пока они не имеют прав на исполнение для каталога, в котором находится файл. Другими словами, чтобы воспользоваться имеющимися правами доступа к файлу, пользователь должен иметь право на исполнение для всех каталогов вдоль пути к файлу.

Основные команды управления правами доступа к файлам и каталогам:

Команда

Значение

chmod

Изменение прав доступа к файлу или каталогу.

chown

Изменение владельца файла.

chgroup

Изменение группы, которой принадлежит файл.

umask

Определение прав доступа по умолчанию для файлов, создаваемых пользователем.

Списки контроля доступа

Любая серьезная многопользовательская ОС предусматривает разграничение доступа к объектам для пользователей и их группам. Объектом может выступать файл, именованный канал, синхронизирующая структура ядра ОС, процесс, поток, служба и т.д. Для Windows NT все разделяемые, защищаемые и именованные структуры являются истинными объектами, т.е. содержат, кроме самих данных, и код по их обработке -- методы, чем достигается независимость внутренней реализации объекта от внешнего интерфейса. Это позволяет также легко вести учет ссылок на конкретный экземпляр объекта.

К примеру, есть разнообразные объекты, а также пользователи, которые должны в зависимости от своих прав получить или не получить доступ к конкретному объекту. В общих чертах данный процесс выглядит так:

1. Пользователь при входе в систему вводит свое имя и пароль, тем самым производя аутентификацию.

2. Проверяющая подсистема ОС сверяет полученные данные с имеющимися в ее базе. Если они одинаковы, открывает доступ к объекту. Если процесс аутентификации прошел успешно, запускается первый процесс (программа) сессии данного пользователя, создающий рабочую среду. Этот процесс получает контекст защиты (маркер доступа), который идентифицирует пользователя, его группы и привилегии процесса. Все созданные пользователем процессы запускаются либо от имени этого процесса, либо его дочерних, что не важно, так как любой процесс получает маркер доступа своего родителя. В итоге ОС может теперь понять, какая программа кем запущена и какие у нее права.

Однако остается еще одна проблема: при обращении программы (процесса) к объекту, ОС должна с чем-то сравнить ее маркер доступа для решения вопроса о разрешении/запрещении доступа (это действие называется авторизацией). В разных системах такая структура данных для различных объектов реализована по-разному (в NT она называется дескриптором защиты). Например, в большинстве файловых систем для UNIX каталоги и файлы имеют структуры защиты, состоящие из имени владельца, его группы и группы "остальные", которым соответствует числовое значение, определяющее права доступа. Такая система довольно проста, но не отличается гибкостью, поэтому ведутся разработки для переноса на некоторые ФС технологии списков контроля доступа. В то же время, в других ОС (NT в том числе) все объекты имеют одинаковую структуру, отвечающую за их защиту.

Информация о том, что субъекту (пользователю, процессу и так далее) позволено делать с объектом или ресурсом, указана в структуре данных, известной как список контроля доступа (ACL). В списках ACL перечислено, кто (какие участники) имеет доступ к какого рода к конкретным объектам. Список контроля доступа на уровне пользователей (discretionary ACL - DACL) - это тип списка ACL, где владельцам объектов позволено их изменять. При доступе к объекту его дескриптор безопасности сравнивается с полномочиями участника, чтобы убедиться в дозволенности запрашиваемого доступа.

Достоинство списков контроля доступа в их гибкости, т.е. можно очень точно разграничить права, а также в единообразности и универсальности.

Windows также поддерживает системные списки ACL (system ACL - SACL) для объектов, и во многих выпусках этой ОС параметры списка SACL использованы для установки того, какие события записываются в журнал аудита. С появлением Windows Server 2008 и Windows Vista список SACL расширен для переноса информации уровня целостности.

Эта метка целостности используется для установки метки «низко», помечающей процесс Internet Explorer, использованный в LowRights Internet Explorer. Метки «система» и «высоко» используются для защиты ключевых ресурсов системы. Сбор сообщений Windows отфильтровывает сообщения, основываясь на уровне их целостности. Например, процессы среднего уровня не получают сообщений, посланных низкоуровневыми процессами, а высокоуровневые процессы не получают сообщений от процессов низкого или среднего уровня.

DACL и SACL это разновидности ACL. Первый служит для указания прав доступа к объекту для конкретных пользователей и групп (в том числе и встроенных). Второй ответственен за ведение аудита в журнале безопасности соответствующих действий над объектом для указанных пользователей/групп (используется только для файловой системы и реестра). Любой ACL состоит, кроме заголовка, из вхождений (элементов) контроля доступа (Access Control Entries, ACE).

ACE для DACL состоит из SID пользователя/группы и маски доступа, разной для разных типов объектов, а также флагов, отвечающих за наследование. Объекты могут быть контейнерами либо списками. Контейнеры могут содержать другие контейнеры и/или списки.

SACL состоит из ACE двух типов: системного аудита (System Audit ACE) и объекта системного аудита (System Audit Object ACE). Они обеспечивают аудит указанных действий для выбранных пользователей, причем может записываться как "успех", так и "отказ". В плане наследования SACL аналогичен DACL. Если SACL не существует, аудит не ведется.

Как и все современные ОС, Windows полагается на списки DACL для принятия общих решений контроля доступа. Чтобы система могла определить, разрешено ли участнику выполнять операцию над объектом, проверяются несколько вещей: полномочия участника, маркер участника и дескриптор безопасности объекта. Двоичный дескриптор безопасности на объекте передается процедуре AccessCheck вместе с маркером участника. Подготавливается запрошенный вектор битов маски доступа; он представляет полномочия доступа, которые должны быть предоставлены, чтобы их проверка завершилась успехом. Он передается процедуре AccessCheck вместе с дескриптором безопасности участника, а та изучает маркер безопасности пользователя и учитывает полномочия участника безопасности (обычно основанные на ролях или членстве, скажем на роли администратора) в сочетании с требуемым доступом и списком DACL на объекте.

Если полномочия участника соответствуют требуемому уровню доступа, то доступ предоставляется. В противном случае по порядку изучаются записи контроля доступа (ACE) списка DACL. Как только система безопасности может показать, что допустимы все требуемые компоненты доступа или что любой из них запрещен, она возвращает успех во первом случае и неудачу во втором.

Таким образом, список записей ACE в списке DACL должен быть упорядочен должным образом. Стандартный (канонический) порядок - сперва однозначные запреты, затем однозначные допуски, общие (групповые) запреты и групповые допуски. Если канонический порядок не используется, могут произойти непредвиденные запреты или допуски.

Основные компоненты дескриптора защиты

* Номер версии защиты.

* Флаги (необязательно).

* SID владельца.

* SID группы.

* Список управления избирательным доступом (Discretionary Access Control List, DACL).

* Системный список управления доступом (System Access Control List, SACL).

SID владельца - идентификатор защиты (Security Identifier, SID). Именно по нему ОС идентифицирует объект, что позволяет избежать проблем при повторении имен. Сам идентификатор представляет собой числовое значение переменной длины. В итоге в дескрипторе защиты объекта уже содержится имя его владельца (точнее, его SID). Анологично с SID группы -- это идентификатор основной группы владельца (используется только подсистемой POSIX).

Размещено на Allbest.ru


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.