6. Средства безопасности операционных систем
Современные операционные системы обладают мощными встроенными средствами обеспечения безопасности, осуществляющими аутентификацию, авторизацию, аудит действий пользователей в системе, защиту от сбоев, криптографическую защиту объектов операционной системы, предотвращение сетевых атак. Рассмотрим подробнее встроенные средства безопасности самых популярных операционных систем.
6.1. ОС семейства Windows
Разговор о подсистемах безопасности ОС семейства Windows имеет смысл вести начиная с версий NT/2000/XP, поскольку именно это поколение ОС фирмы Microsoft включает в себя надежную подсистему безопасности как одну из концептуальных основ системы. Более ранние версии (Windows 95,98) были ориентированы на домашние компьютеры и не реализовывали большинства функций безопасности платформы Win32.
ОС платформы Win32 для обеспечения безопасности позволяют: идентифицировать пользователей сети и управлять их доступом к ресурсам, кодировать информацию с использованием встроенных средств шифрования CryptoAPI, поддерживать безопасную связь по общедоступным сетям с использованием протоколов IPSec, аутентифицировать пользователей по протоколу аутентификации Kerberos версии 5 и посредством смарт-карт, разграничивать доступ к файлам и каталогам с помощью файловых систем NTFS и EFS.
Система безопасности платформы Win32 основана на модели безопасности для каждого пользователя или группы пользователей. Каждый пользователь, зарегистрированный в системе, имеет собственную учетную запись, которая содержит персональную информацию о пользователе. Эти данные система использует для проверки подлинности пользователя и для авторизации его при доступе к ресурсам домена. После прохождения процедуры аутентификации пользователю присваивается маркер доступа, идентифицирующий пользователя, его группу, а также определяющий доступные пользователю привилегии в системе для доступа к ресурсам. При этом каждому объекту системы, включая файлы, принтеры, сетевые службы, контейнеры Active Directory и другие, присваивается дескриптор безопасности. Дескриптор безопасности объекта определяет права доступа к объекту и содержит список контроля доступа (ACL – Access Control List), в котором явно определяется, каким пользователям разрешено выполнять те или иные действия с этим объектом. Дескриптор безопасности объекта также определяет, для каких событий должен вестись аудит. Авторизация Win32 основана на сопоставлении маркера доступа субъекта с дескриптором безопасности объекта. Управляя свойствами объекта, администраторы могут устанавливать разрешения, назначать право владения и отслеживать доступ пользователей. Каждый дескриптор безопасности может содержать списки двух типов. Системный список управления доступом (SACL – System Access Control List) позволяет отслеживать права и ограничения, установленные для объекта на системном уровне. В этот список могут вносить изменения только те пользователи, которые обладают правами доступа на уровне системы.
Пользовательский список управления доступом (DACL – Discretionary Access Control List) позволяет отслеживать права и ограничения, установленные владельцем данного объекта. DACL может быть изменен пользователем, который указан как текущий владелец объекта.
Оба списка имеют одинаковую структуру. Они могут не содержать ни одной записи либо содержать одну или несколько записей. Каждая запись (ACE – Access Control Entry) состоит из трех частей: в первой указываются пользователи или группы, к которым относится данная запись, во второй – права доступа, а третья информирует о том, предоставляются эти права или отбираются.
Дескрипторы безопасности могут быть представлены либо в абсолютном, либо в относительном формате. Абсолютный формат предусматривает запись дескриптора безопасности в память в виде структуры указателей и, поэтому, он более удобен для обновления содержимого дескриптора.
С другой стороны, поскольку указатели содержат ссылки на области памяти, доступ к которым обычно обеспечивается только компьютером-владельцем, абсолютный формат не слишком хорош для передачи дескрипторов по сети (или записи на диск), так как при этом записываются не сами структуры, а только набор указателей. Поэтому существует второй формат дескрипторов безопасности, в соответствии с которым структура с текущим содержимым всех полей записывается в едином непрерывном блоке памяти. Такой формат более удобен для передачи дескриптора. Он называется относительным форматом (см. рис. 6.1).
Задавать список прав доступа можно непосредственно в оконном диалоге Windows в окне свойств объекта (см. рис.6.2 с определением прав на доступ к файлу), а можно программно, используя специальные API-функции. В листинге 1 представлен фрагмент программы, позволяющей программно изменить права доступа к файлу для некоторого пользователя.
Рис.6.2. Определения прав доступа к файлу в Windows
Листинг 1. Программа управления правами доступа к объектам в Windows
SID_NAME_USE SIDType;
PSECURITY_DESCRIPTOR pNewFileSD;
PACL pNewFileDACL;
char *filename = “c:\\testfle.dat”; //имя файла
char *username =”guest” ; //имя пользователя
char szDomainName[250]=”VPI”; //название домена
char UserSID[2048]; //идентификатор безопасности пользователя
DWORD dwSIDLength = sizeof( UserSID );
DWORD dwDomainLength = sizeof( szDomainName );
DWORD dwNewACLSize;
// получить SID (идентификатор безопасности) пользователя (группы)
LookupAccountName((LPSTR) NULL, username, UserSID, &dwSIDLength, szDomainName, &dwDomainLength, &SIDType );
// Инициализировать новый SD (дескриптор безопасности)
InitializeSecurityDescriptor( pNewFileSD, SECURITY_DESCRIPTOR_REVISION );
//получить размер ACL
dwNewACLSize = sizeof(ACL) + sizeof(ACCESS_ALLOWED_ACE) + GetLengthSid(UserSID) - sizeof(DWORD) ;
//создать и проинициализировать новый ACL
InitializeAcl( pNewFileDACL, dwNewACLSize, ACL_REVISION2 );
//поместить новый ACE с разрешением на чтение файла для пользователя в конец DACL
AddAccessAllowedAce( pNewFileDACL, ACL_REVISION2, GENERIC_READ, &UserSID );
// записать DACL в новый SD файла
SetSecurityDescriptorDacl( pNewFileSD, TRUE, pNewFileDACL, FALSE );
// установить новый SD для файла с именем в filename
SetFileSecurity( filename, DACL_SECURITY_INFORMATION, pNewFileSD );
Разграничение прав доступа пользователей к файлам и папкам в Win32 возможно только при использовании файловой системы NTFS. Эта файловая система обеспечивает поддержку дескрипторов безопасности для элементов файловой системы и позволяет определять следующие права на доступ: чтение, запись, выполнение, удаление, изменение прав доступа, получение права владельца, запись/чтение атрибутов (см. рис. 6.2). Необходимо, однако, отметить, что файловая система NTFS не выполняет шифрования информации на носителях, в связи с чем существует возможность получить доступ к информации на физическом уровне, например, загрузившись с другой операционной системы, получить доступ к информации в файлах. Такую возможность предоставляет утилита ntfsdos.exe, которую можно запустить, предварительно загрузив на компьютер операционную систему MS DOS c гибкого диска. Для того чтобы предотвратить доступ к логическим NTFS – дискам необходимо запретить загрузку компьютера с гибкого диска, запретить подключение других носителей к компьютеру и отключение носителя от компьютера. Альтернативой этому комплексу мер может стать использование файловой системы EFS (Encrypting File System). Шифрующая файловая система EFS - это тесно интегрированная с NTFS служба, располагающаяся в ядре Windows. Ее назначение: защита данных, хранящихся на диске, от несанкционированного доступа путем их шифрования. EFS использует архитектуру Windows CryptoAPI. В ее основе лежит технология шифрования с открытым ключом. Для шифрования каждого файла случайным образом генерируется ключ шифрования файла. В текущей реализации EFS использует алгоритм - DESX, являющийся специальной модификацией стандарта DES.
Локальные учетные записи пользователей в Win32 хранятся в базе данных SAM (Security Account Manager). Она располагается в каталоге \%Systemroot%\System32\ConfIg в отдельном файле, который называется SAM. В учетных записях базы данных SAM находится информация о пользовательских именах и паролях, которая необходима для идентификации и аутентификации пользователей при их интерактивном входе в систему. Учетные записи создаются с использованием инструмента Local Users and Groups (Локальные пользователи и группы) из программы Computer Management (Управление компьютером). Информация в SAM хранится в зашифрованном виде. Пароль пользователя сначала хэшируется алгоритмом MD4, затем результат хэширования кодируется алгоритмом DES, причем в качестве ключа шифрования используется так называемый относительный идентификатор пользователя (Relative Identifier, RID), который представляет собой автоматически увеличивающийся порядковый номер учетной записи данного пользователя в базе данных SAM. При входе пользователя в систему его пароль подвергается аналогичным преобразованиям, и если их результат совпадет с содержимым SAM, пользователь проходит аутентификацию. Для предотвращения доступа злоумышленника к базе данных SAM доступ к ней заблокирован для всех без исключения ее пользователей. Однако, существует возможность сохранить копию этого файла с помощью утилиты резервного копирования NTBACKUP. Доступ возможен также при загрузке альтернативной ОС (уже упоминавшаяся утилита ntfsdos.exe из под MS DOS может предоставить доступ к SAM). Необходимо также защищать от несанкционированного доступа автоматически создаваемую сжатую архивную копию SAM (файл SAM) в каталоге \%Systemroot%\Repair.
При наличии файла SAM злоумышленник может получить доступ к хранящимся в нем учетным записям, используя такие программы, как LOphtCrack или Advanced NT Security Explorer. В связи с этим необходимо защищать SAM от несанкционированного доступа, запретив загрузку альтернативных ОС с других дисков в BIOS, установив соответствующие права доступа к файлам SAM в системе или используя специальную утилиту SYSKEY, дополнительно шифрующую содержимое файла SAM.
ОС платформы Win32 активно используют возможности защищенного режима процессора и позволяют эффективно защищать код и данные процессов от взаимного влияния друг на друга. Каждый процесс работает в собственном виртуальном адресном пространстве, доступ к которому других процессов запрещен, если только сам процесс-владелец не разрешит его.
Платформа Win32 предоставляет программный интерфейс CryptoAPI для кодирования информации по различным алгоритмам, как симметричным, так и асимметричным. CryptoAPI – это интерфейс прикладного программирования (API – Application Programming Interface) в операционной системе Windows, предоставляющий службы шифрования для операционной системы и приложений, работающих под ее управлением. Он содержит ряд функций, позволяющих приложениям шифровать данные и ставить цифровую подпись различными способами, обеспечивая защиту личных ключей. Однако, сами функции CryptoApi не выполняют никаких криптографических действий, а служат лишь посредниками между прикладной программой и CSP (Cryptographic Service Provider – поставщик службы шифрования). Программная часть криптопровайдера представляет собой dll-файл с функциями поддержки шифрования. Криптопровайдеры отличаются друг от друга составом функций, требованиями к оборудованию, алгоритмами, осуществляющими базовые действия (создание ключей, хеширование и пр.).
По составу функций и обеспечивающих их алгоритмов криптопровайдеры подразделяются на типы. Например, любой CSP типа PROV_RSA_FULL поддерживает как шифрование, так и цифровые подписи, использует для обмена ключами и создания подписей алгоритм RSA, для шифрования — алгоритмы RC2 и RC4, а для хеширования - MD5 и SHA.
В зависимости от версии операционной системы состав установленных криптопровайдеров может существенно изменяться. Однако на любом компьютере с Windows можно найти Microsoft Base Cryptographic Provider, относящийся к типу PROV_RSA_FULL. Именно с этим провайдером по умолчанию будут взаимодействовать все программы. Пользователь имеет возможность приобрести CSP другого производителя, тогда функции CryptoAPI будут работать с программами этого CSP. Пример использования функций CryptoAPI для кодирования файла симметричным алгоритмом RC4 приведен в листинге 2.
Листинг 2. Использование функций CryproAPI для кодирования файла
HCRYPTPROV hProv;
//Подключаемся к криптопровайдеру типа PROV_RSA_FULL
if(!CryptAcquireContext(&hProv,NULL,NULL,PROV_RSA_FULL,0))
{
puts("Ошибка инициализации CSP\n";
return;
}
//Открываем входной и выходной файл
HANDLE hInFile;
hInFile=CreateFile("d:\\NS.doc", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
HANDLE hOutFile;
hOutFile=CreateFile("d:\\crypt", GENERIC_WRITE, FILE_SHARE_READ, NULL,CREATE_ALWAYS, 0, NULL);
HCRYPTKEY hKey;
//генерируем сессионный ключ для RC4
if(!CryptGenKey(hProv,CALG_RC4,CRYPT_EXPORTABLE,&hKey))
{ puts("ошибка генерации ключа RC4\n");
return;
}
BYTE buf[BUFFER_SIZE];
DWORD dwSzLow,dwSzHigh;
dwSzLow=GetFileSize(hInFile,&dwSzHigh);// получить размер входного файла
unsigned __int64 fSize=(dwSzHigh<<32)+dwSzLow;
while(fSize)
{
if(!ReadFile(hInFile,buf,BUFFER_SIZE,&dwLen,NULL)) //читаем блок данных
puts("Ошибка чтения данных\n");
dwSzLow=dwLen;
if(!CryptEncrypt(hKey,0,fSize<=BUFFER_SIZE,0,buf,&dwSzLow,sizeof(buf)))
//шифруем блок данных
puts("Ошибка шифрования\n");
if(!WriteFile(hOutFile,buf,dwSzLow,&dwSzLow,NULL))
puts("Ошибка записи\n");
fSize-=dwLen;
}
CloseHandle(hOutFile);
CloseHandle(hInFile);
CryptReleaseContext(hProv,0);
Аудит - очень важный элемент системы безопасности, позволяющий регистрировать в специальных журналах события, связанные с действиями пользователей в системе. ОС платформы Win32 поддерживают систему аудита, позволяющую выбрать типы отслеживаемых событий и регистрировать их в системных журналах. Основной инструмент аудита в Windows – утилита Event Viewer (Просмотр событий). Запуск этой утилиты осуществляется из папки Administrative Tools (Администрирование).
Рис.6.3. Внешний вид утилиты Event Viewer (Просмотр событий) Windows
Windows записывает события в три журнала:
Системный журнал - (system log) содержит сообщения об ошибках, предупреждения и другую информацию, исходящую от операционной системы и компонентов сторонних производителей. Список событий, регистрируемых в этом журнале, предопределен операционной системой и компонентами сторонних производителей и не может быть изменен пользователем. Журнал находится в файле Sysevent.evt.
Журнал безопасности - (Security Log) содержит информацию об успешных и неудачных попытках выполнения действий, регистрируемых средствами аудита. События, регистрируемые в этом журнале, определяются заданной администратором стратегией аудита. Журнал находится в файле Secevent.evt.
Журнал приложений - (Application Log) содержит сообщения об ошибках, предупреждения и другую информацию, выдаваемую различными приложениями. Список событий, регистрируемых в этом журнале, определяется разработчиками приложений. Журнал находится в файле Appevent.evt.
Все журналы размещены в папке %Systemroot%\System32\Config.
П
ри
выборе событий для проведения аудита
следует учитывать возможность
переполнения журнала. Для настройки
каждого журнала можно использовать
диалоговое окно Event
Log Settings
(Свойства журнала, рис. 6.4)
. С помощью этого окна можно управлять:
размером архивируемых журналов (размер по умолчанию – 512 Кбайт, можно изменить размер от 64 до 4 194 240 Кбайт.);
методикой замещения устаревших записей журнала:
Затирать старые события по необходимости – в случае заполнения журнала при записи новых событий операционная система удаляет самые старые события;
Затирать события старее N дней– в случае заполнения журнала при записи новых событий удаляются самые события, но только если они старше N дней, иначе новые события будут проигнорированы;
Не затирать события – в случае заполнения журнала новые события не фиксируются. Очистка журнала производится вручную.
Каждая запись в журнале содержит сведения о выполненном действии, о пользователе, который его выполнил, а также о дате и времени события. Можно проводить аудит как успешных, так и неудачных попыток выполнения некоторых действий. В журнал заносятся записи 5 различных типов:
Ошибка |
Серьезные трудности, такие как потеря данных или функциональности. Например, если происходит сбой загрузки службы при запуске, в журнал заносится сообщение об ошибке. |
Предупреждение |
События, которые в момент записи в журнал не были существенными, но могут привести к сложностям в будущем. Например, если на диске осталось мало свободного места, в журнал заносится предупреждение. |
Сведения |
Событие, описывающее удачное завершение действия приложением, драйвером или службой. Например, после успешной загрузки драйвера в журнал заносится событие уведомления. |
Аудит успехов |
Событие, соответствующее успешно завершенному действию, связанному с поддержкой безопасности системы. Например, в случае успешного входа пользователя в систему в журнал заносится событие типа «Аудит успехов» |
Аудит отказов |
Событие, соответствующее неудачно завершенному действию, связанному с поддержкой безопасности системы. Например, в случае неудачной попытки доступа пользователя к сетевому диску в журнал заносится событие типа «Аудит отказов» |
Администратор имеет возможность определять набор подлежащих аудиту событий. В WindowsNT это осуществляется в диалоговом окне Audit Policy (Политика Аудита) утилиты User Manager for Domains (Менеджер пользователей)
Основные события, которые могут регистрироваться:
Logon and Logoff – регистрация пользователя в системе или выход из нее, а также установка и разрыв сетевого соединения;
File and Object Access – доступ к папкам, файлам и принтерам, подлежащим аудиту;
Use of User Rights – использование привилегий пользователей (кроме прав, связанных с входом и выходом из системы);
User and Group Management – создание, изменение и удаление учётных записей пользователей и групп, а также изменения в ограничениях учётной записи;
Security Policy Changes — изменения в привилегиях пользователей, стратегии аудита и политике доверительных отношений;
System Restart and Shutdown — перезапуск и завершение работы системы, возникновение ситуации, влияющей на безопасность системы;
Process Tracking — события, связанные с запуском и завершением пользовательских процессов, их доступом к объектам.
Настройка аудита доступа пользователей к тому или иному файлу или папке осуществляется в окне свойств этого объекта, закладка Безопасность-> Дополнительно-> Аудит. С помощью оконного интерфейса здесь можно определить события, связанные с файлом или папкой, возникновение которых должно отражаться в журнале системы. Список возможных событий отображен на рис. 6.5.
Рис.6.5. Определение
событий, связанных с файлом, подлежащих
аудиту
6.2. Средства безопасности ОС семейства Unix.
С самых первых версий операционная система Unix разрабатывалась как многопользовательская многозадачная операционная система. Она должна была обеспечивать одновременную работу нескольких пользователей, работающих с различными приложениями. Таким образом, необходимо было защитить пользователей друг от друга и предотвратить несанкционированный доступ, случайный или злонамеренный. Поэтому системе безопасности в ОС семейства Unix отводится очень большое внимание. В настоящий момент существует много различных версий операционных систем семейства Unix, однако все они поддерживают единую модель безопасности. Некоторые современные версии систем поддерживают различные расширения и улучшения системы безопасности, ознакомиться с которыми администратор может из справочного руководства к данным системам. В дальнейшем будем рассматривать традиционную модель безопасности операционных систем семейства Unix.
Основу безопасности ОС семейства Unix составляют пользователи системы. Пользователи обладают определенными правами, они владеют файлами, от их имени запускаются системные и прикладные процессы. Причем набор функций, системных вызовов и операций, которые может выполнять процесс зависит от прав пользователя, запустившего этот процесс. Все зарегистрированные в системе пользователи учитываются в файле /etc/passwd. Каждый пользователь системы имеет регистрационное имя (login name). Однако система различает пользователей не по именам, а по ассоциированным с ними уникальным идентификаторам пользователей или UID (User Identifier). Также каждый пользователь является членом одной или нескольких групп. Группы описываются в файле /etc/group. Каждая группа имеет уникальное имя и уникальный идентификатор группы GID (Group Identifier). В файле /etc/passwd указывается идентификатор первичной группы пользователя. Таким образом UID и GID определяют, какими правами обладает пользователь в системе. Среди всех пользователей особое положение занимает пользователь с UID=0, или так называемый суперпользователь. Данный пользователь обычно имеет регистрационное имя root, однако в системе может быть несколько пользователей с UID=0 и различными именами. Суперпользователь обладает неограниченными правами и может выполнять над файлами и процессами любую допустимую операцию. Кроме того, некоторые системные вызовы и операции может выполнять только суперпользователь. Например, следующие операции доступны лишь суперпользователю: создание файлов устройств, изменение системного времени, увеличение лимитов на использование ресурсов, увеличение приоритетов процессов, задание сетевого имени, конфигурирование сетевых интерфейсов, останов и перезагрузка системы. Администратору следует проявлять большую осторожность при работе под именем суперпользователя, поскольку неосторожные действия могут привести к необратимым последствиям. Также во многих системах существует специальная привилегированная группа с GID=0 и именем wheel. Некоторые операции, например выполнение команды su, доступны только пользователям, являющимся членами этой группы. Кроме имени пользователя и идентификаторов в файле /etc/passwd содержатся также: зашифрованный пароль пользователя, домашний каталог пользователя и интерпретатор команд. Алгоритм шифрования пароля зависит от конкретной версии системы и является однонаправленным алгоритмом шифрования. Например, в системе FreeBSD используется алгоритм MD5. Следует особо отметить, что в открытом виде пароль никогда и нигде не хранится. При входе пользователя в систему введенный им пароль шифруется и сравнивается два зашифрованных варианта. Даже суперпользователь не может узнать пароль какого-либо пользователя, однако он может сменить пароль любого пользователя с помощью утилиты passwd. Данная утилита также позволяет обычным пользователям менять их пароли. Если в файле паролей вместо зашифрованного пароля стоит символ ‘*’, то такой пользователь не сможет войти в систему. Если же поле пароля пустое, то пользователь сможет войти в систему, введя пустой пароль. Даже в зашифрованном виде файл паролей предоставляет некоторую угрозу безопасности, поскольку возможен подбор паролей, например, с использованием словаря. Поэтому во многих системах пароли были перенесены из файла /etc/passwd в другие файлы. Например, во FreeBSD пароли находятся в файле /etc/master.passwd, а в Solaris и Linux в /etc/shadow. Оба этих файла доступны только суперпользователю и недоступны другим пользователям системы даже для чтения. При входе пользователя в систему запускается указанный в файле /etc/passwd интерпретатор команд. Обычно это один из стандартных командных интерпретаторов /bin/sh (Bourne shell), /bin/csh (C shell), /bin/ksh (Коrn shell) или /bin/bash (Bourne shell again), позволяющих пользователю вводить команды и запускать задачи. Для пользователей, которым не нужен интерпретатор в этом поле можно указать, например, /sbin/nologin, /nonexistent (для псевдопользователей) или /bin/date (для удаленных пользователей). В общем случае в этом поле может быть указана любая программа, важно то, что, завершив выполнение этой задачи, пользователь автоматически выйдет из системы. В файле /etc/shells содержится список программ, которые могут быть использованы в качестве командного интерпретатора.
Как уже было отмечено, пользователи в ОС семейства Unix могут владеть файлами. Следует отметить, что в Unix файловая подсистема обеспечивает унифицированный интерфейс доступа к данным, расположенным на дисковых накопителях, и к периферийным устройствам. Т.е. доступ ко всем устройствам осуществляется через специальные файлы устройств. В ОС семейства Unix файлы имеют двух владельцев: владельца-пользователя и владельца-группу. Владельцем-пользователем вновь созданного файла является пользователь, создавший файл. Владелец-группа для вновь созданного файла определяется по-разному в различных версиях систем. В BSD-версиях UNIX владелец-группа определяется по группе, владеющей каталогом, в котором создается файл. В AT&T системах владельцем-группой становится первичная группа, которой принадлежит пользователь, создавший файл.
В Unix существуют три базовых класса доступа к файлу:
u – класс доступа для пользователя-владельца;
g – класс доступа для группы-владельца;
о – класс доступа для остальных пользователей.
Для каждого класса Unix поддерживает три типа прав доступа:
r – право на чтение;
w – право на запись;
x – право на исполнение.
Список прав доступа можно получить с помощью утилиты ls –l. Например:
- rwx rw- r- - 1 root wheel 1077 Jun 1 18:05 /usr/home/sergey/myinfo
Из приведенного примера видно, что для файла /usr/home/sergey/myinfo владельцем-пользователем является root, владельцем группой – wheel, права для владельца-пользователя rwx, владельца-группы rw, и для остальных пользователей r. Первый символ указывает тип файла: ‘d’ – каталог, ‘с’ – файл байт-ориентированного устройства, ‘b’ - файл блок-ориентированного устройства, ‘s’ – сокет, ‘p’- именованный канал, ‘l’ – символическая ссылка.
Права доступа могут быть изменены только владельцем файла или суперпользователем при помощи утилиты chmod. Изменить владельца-пользователя и владельца-группу может только суперпользователь при помощи утилит chown и chgrp.
Общий формат chmod следующий:
u
g + r
chmod o - w file1 file2 ….
a = x
В качестве аргументов указываются классы доступа (‘u’- владелец-пользователь, ‘g’ - владелец-группа, 'о' — остальные пользователи, 'а' — все классы пользователей), права доступа ('r' - чтение, ‘w’ - запись и 'х' - выполнение) и операция, которую необходимо произвести (‘+’ - добавить, ‘-‘ - удалить и ‘=’ - присвоить) для списка файлов file1, file2 и т. д. Например
chmod u+w,og+r-wx text1 text2
Также можно установить сразу все девять прав доступа, используя числовую форму команды. Число определяется следующим образом: нужно представить права доступа в двоичном виде (0 — отсутствие соответствующего права, 1 — его наличие) и каждую триаду, соответствующую классу доступа, в свою очередь преобразовать в десятичное число. Допустим chmod 754 * эквивалентно chmod u=rwx,g=rx,o=r * (rwx=111b=7; r-x=101b=5; r--=100b=4 )
Значение прав доступа различно для разных типов файлов. Для файлов операции, которые можно производить, следуют из самих названий прав доступа. Например, чтобы просмотреть содержимое файла командой cat, пользователь должен иметь право на чтение (r). Редактирование файла, т. е. его изменение, предусматривает наличие права на запись (w). Наконец, для того, чтобы запустить некоторую программу на выполнение, необходимо иметь право на исполнение (х). Исполняемый файл может быть как скомпилированной программой, так и скриптом командного интерпретатора shell. В последнем случае для выполнения необходимо иметь также право на чтение, поскольку при выполнении скрипта командный интерпретатор должен иметь возможность считывать команды из файла. Все сказанное, за исключением права на выполнение, справедливо и для других типов файлов: специальных файлов устройств, именованных каналов и сокетов. Для символических связей права доступа вообще не используются, поскольку контролируются целевым файлом (для символических связей права всегда равны lrwxrwxrwx).
Для каталогов система трактует права доступа несколько по-другому. Право чтения каталога позволяет получить имена файлов (точнее только имена и их индексные дескрипторы), находящихся в данном каталоге. Чтобы получить дополнительную информацию о файлах каталога (например, подробный листинг команды ls -l), необходимо иметь право на выполнение для каталога. Это право также необходимо, чтобы получить доступ к содержимому файла (например, прочитать его с помощью команды cat) и для того, чтобы перейти в каталог, т.е. сделать его текущим с помощью команды cd. Кроме того, для того чтобы сделать каталог текущим, право на выполнение необходимо иметь для всех каталогов на пути к указанному. Права r и x действуют независимо, право х для каталога не требует наличия права r, и наоборот. Комбинацией этих двух прав можно добиться интересных эффектов, например, создания «темных» каталогов, файлы которых доступны только в случае, если пользователь заранее знает их имена, поскольку получение списка файлов таких каталогов запрещено. Создание, удаление и переименование файлов требует наличия прав w и x на каталог. При этом при удалении файлов не учитываются права доступа для самого файла. Т.е. если пользователь имеет право w на каталог, то он может удалить в нем файл, на который не имеет никаких прав. Можно изменить подобное поведение операционной системы с помощью специальных дополнительных флагов, которые будут рассмотрены ниже.
Операционная система UNIX производит проверку прав доступа при создании, открытии (для чтения или записи), запуске на выполнение или удалении файла. При этом выполняются следующие проверки:
Если операция запрашивается суперпользователем (с UID=0), доступ разрешается. Никакие дополнительные проверки не производятся. Это позволяет администратору иметь неограниченный доступ ко всей файловой системе.
Если операция запрашивается владельцем файла, то доступ разрешается при условии, что требуемое право доступа определено для владельца-пользователя, в противном случае доступ запрещается.
Если операция запрашивается пользователем, являющимся членом группы, которая является владельцем файла, то доступ разрешается при условии, что требуемое право доступа определено для владельца-группы, в противном случае доступ запрещается.
Если требуемое право доступа для прочих пользователей (other) установлено, доступ разрешается, в противном случае доступ запрещается.
Система проводит проверки именно в указанной последовательности. Например, если пользователь не является владельцем файла, но является членом владельца-группы, то доступ определяется исключительно из прав владельца-группы, права, указанные для остальных пользователей, не проверяются. Например,
-rwx --- r-- 2 root guest 1056 Jun 1 19:13 special.info
Если пользователь gstuser является членом группы guest, то доступ к файлу special.info для него будет запрещен, хотя все остальные пользователи, не входящие в эту группу, имеют право чтения на этот файл. Эта возможность позволяет выделять группы пользователей, обладающих ограниченными правами.
Помимо рассмотренных основных прав доступа, имеются еще дополнительные права. Это биты SUID, SGID и Sticky-бит. Данные биты можно установить или убрать с помощью стандартной утилиты chmod. При использовании символьного режима данные биты указываются буквами s и t соответственно, а при использовании числового режима SUID соответствует 4000, SGID – 2000 и Sticky-бит – 1000. При просмотре прав доступа данные биты указываются вместо соответствующих битов x строчными буквами s и t. Следует отметить, что в большинстве случаев использование данных битов без установки соответствующих битов x лишено смысла (например установка SUID без установки бита x для владельца файла). Поэтому в этом случае при просмотре прав доступа биты будут указаны прописными буквами S и T, что указывает на некорректное их использование.
Рассмотрим область применения дополнительных битов. Биты SUID и SGID позволяют установить для файлов EUID и EGID процесса, равными UID или GID владельца-пользователя и владельца-группы файла. Sticky-бит для файлов считается устаревшим режимом и в современных системах практически не используется. Для каталогов бит SGID задает режим, при котором при создании файла владельцем-группой становится группа, владеющая каталогом. Это позволяет некоторым Unix системам имитировать поведение систем версии BSD, для которых такое правило наследования действует по умолчанию. Sticky-бит для каталогов устанавливает режим, при котором пользователь может удалять файлы из каталога, только если он имеет право w для этих файлов. Это перекрывает режим по умолчанию, при котором для удаления файлов достаточно только прав w и x на сам каталог. Примером использования данного режима может служить каталог /tmp, который является открытым на запись для всех пользователей, но в котором может оказаться нежелательной возможность удаления пользователем чужих временных файлов.
Кроме рассмотренных выше прав доступа, в некоторых системах используются дополнительные права доступа. Например, в BSD системах существует специальный флаг noschg, установка которого запрещает изменять и удалять файл. Кроме того, некоторые современные версии систем Unix поддерживают управление списками доступа ACL.
Как уже было отмечено, права процессов зависят от прав пользователя, запустившего процесс. В операционных системах семейства Unix процессы имеют четыре идентификатора, связанных с правами доступа. Это идентификаторы пользователя RUID, EUID (реальный и эффективный) и идентификаторы группы RGID, EGID. RUID и RGID всегда устанавливаются равными UID и GID пользователя, запустившего процесс. По умолчанию EUID и EGID также будут равны UID и GID пользователя, запустившего процесс. Однако, как было отмечено выше, если для файла установлены биты SUID или SGID, то EUID и EGID будут равны UID и GID владельца-пользователя и владельца-группы соответственно. В качестве примера можно привести утилиту passwd, владельцем которой является root, и у нее установлен бит SUID. Это дает право любому пользователю изменять свой пароль и сохранить изменения в файле паролей. Стоит также отметить, что в любом случае утилита passwd может по битам RUID и EUID определить, запустил ее суперпользователь, либо другой пользователь от имени суперпользователя. И соответственно для обычных пользователей она может предоставить лишь ограниченные права. Например, суперпользователь может изменять пароль любого пользователя, даже не зная его старого пароля. При запуске дочерних процессов они наследуют права доступа родительского процесса. Поэтому устанавливать биты SUID и SGID следует с большой осторожностью и только для программ, которые не имеют возможности запуска произвольных задач, поскольку, например, командный интерпретатор, запущенный от имени суперпользователя, предоставляет почти неограниченные возможности.
Как уже было отмечено, суперпользователь обладает неограниченными правами. Для работы в системе с правами суперпользователя можно просто войти в систему под именем root. Однако данный режим не рекомендуется использовать, поскольку, во-первых, при работе под именем root не ведется никаких записей о том, какие действия выполнял суперпользователь, во-вторых, сценарий регистрации суперпользователя не предполагает сбора никакой другой идентифицирующей информации (например, если под именем root могут входить несколько человек, невозможно определить, кто именно произвел вход в систему) и, в-третьих, любые неосторожные действия могут привести к необратимым последствиям. Поэтому для обеспечения большей безопасности регистрация под именем root запрещена на терминалах и по сети, т.е. везде кроме системной консоли.
Для того чтобы другой пользователь мог выполнять операции от имени root, существует 2 варианта: команда su и утилита sudo. Для использования команды su, пользователь должен войти в систему под любым произвольным именем и затем вызвать команду su без параметров. При этом будет запрошен пароль суперпользователя, и в случае указания правильного пароля, будет запущен командный интерпретатор с правами суперпользователя. Во многих системах пользователь должен также являться членом группы с GID=0. В общем случае команда su позволяет запускать командный интерпретатор от имени любого пользователя, указанного в качестве параметра. Команда su предназначена, в основном, для системных администраторов, а не для обычных пользователей. В некоторых случаях может возникнуть необходимость разрешить для некоторых пользователей выполнение некоторых команд от имени суперпользователя. Для этого можно использовать утилиту sudo. Программа sudo принимает в качестве параметра командную строку, которая подлежит выполнению с правами пользователя root. В файле /usr/local/etc/sudoers содержится список пользователей и перечень команд, которые они имеют право выполнять на указанных машинах. Если все разрешения совпадают, то перед выполнением указанной команды sudo запрашивает у пользователя его пароль и выполняет указанную команду от имени суперпользователя. Программа sudo ведет файл регистрации выполненных команд, а также вызвавших их пользователей и времени вызова. Редактировать файл sudoers может только суперпользователь с помощью специальной утилиты visudo. Он должен соблюдать большую аккуратность при установке разрешений в файле sudoers и должен предоставить пользователям минимальный набор команд, достаточный для выполнения требуемых операций.
Таким образом, можно сделать вывод, что подсистема безопасности ОС семейства Unix достаточно эффективна, и большинство систем Unix по всем параметрам соответствуют классу безопасности C2. Однако стоит отметить, что администратор системы должен очень ответственно подходить к вопросам безопасности, поскольку какое-либо некорректное действие (например, предоставление пользователям возможности доступа к файлу паролей, возможности запуска командного интерпретатора с правами root, возможности запуска непроверенных или ненадежных скриптов и программ от имени суперпользователя) могут свести на нет все достоинства системы безопасности Unix.
Подсистема аудита в операционных системах семейства UNIX позволяет эффективно отслеживать действия пользователей в системе. В большинстве операционных систем семейства Unix используется централизованная система регистрации системных сообщений Syslog. Данная система позволяет администратору вести полный контроль за сообщениями как самой системы и системных процессов, так и прикладных процессов. Она обладает очень большой гибкостью и позволяет сортировать сообщения как по источникам, так и по степени важности и направлять их в различные пункты назначения: в журнальные файлы, на терминалы пользователей и даже на другие машины в сети. Таким образом, администратор может организовать централизованную процедуру регистрации системных сообщений во всей сети.
Система Syslog состоит из трех компонентов:
демона syslogd, который осуществляет регистрацию событий;
библиотечных функций openlog(),syslog(),closelog(), которые передают сообщения демону syslogd;
команды logger, которая принимает сообщения от интерпретатора команд.
Демон syslogd запускается во время начальной загрузки системы и работает непрерывно. Процессы и демоны взаимодействуют с этим демоном через библиотечные функции syslog, openlog, closelog, которые описаны в /usr/include/sys/syslog.h. Файл /etc/syslog.conf является конфигурационным файлом демона syslogd. Для того что бы демон перечитал файл конфигурации, ему необходимо послать сигнал HUP.
Сам файл конфигурации состоит из строк вида
селектор <Tab> действие
Пустые строки и строки, начинающиеся с символа ‘#’, игнорируются. Допускается наличие нескольких символов табуляции между селектором и действием, однако использование пробелов в качестве разделителей не допускается. Это может приводить к скрытым ошибкам при использовании различных редакторов, поэтому администратор должен быть очень внимательным при редактировании данного файла.
Формат селектора следующий:
средство.уровень
где средство указывает источник сообщений, а уровень определяет уровень серьезности сообщения. И имена средств, и уровни имеют стандартный набор значений, администратор не может использовать произвольные значения для них. Допускается также использование символов ‘*’ и none в качестве значений средства и уровня. Эти символы обозначают «все» и «ничего» соответственно. Допускается указание нескольких селекторов, разделенных символом ';' или ',' в одной строке. Например
средство1.уровень1;средство2.*;*.уровень3 <Tab> действие
В этом случае селекторы объединяются по схеме «ИЛИ», т.е. действие будет выполнено для сообщения, соответствующего любому из селекторов. Базовый набор средств и уровней приведен в таблицах 6.1 и 6.2 соответственно [13].
Таблица 6.1
Средства системы syslog.
Средство |
Программы и сообщения, которые его используют |
Kern |
Ядро системы |
User |
Пользовательские процессы (по умолчанию, если не указано иное ) |
Система sendmail и другие почтовые программы |
|
Daemon |
Системные демоны |
Auth |
Команды, связанные с безопасностью и авторизацией |
Lpr |
Система буферизации печати |
News |
Система телеконференций usenet |
Cron |
Демон cron |
Mark |
Метки времени, генерируемые через определенные промежутки времени |
Таблица 6.2
Уровни серьезности системы syslog
Уровень |
Значение |
Emerg |
Экстренные ситуации |
Alert |
Срочные ситуации |
Crit |
Критические состояния |
Err |
Ошибочные состояния |
Warning |
Предупреждающие сообщения |
Notice |
Необычные события, заслуживающие внимания |
Info |
Информационные сообщения |
Debug |
Отладочные сообщения |
Уровень сообщения определяет его важность. В таблице 6.2 уровни приведены в порядке убывания важности. По умолчанию в файле syslog.conf указывается минимальная важность, которую должно иметь сообщение, чтобы быть зарегистрированным. Другими словами, если указано
mail.warning <tab> действие1
то «действие1» будет выполнено для всех сообщений от почтовой подсистемы с уровнями warning, а также с уровнями err,crit,alert и emerg. В BSD системах допускается также дополнительные возможности указания уровня. Например, mail.>=warning – аналогично использованию mail.warning; mail.=warning – для регистрации сообщений только уровня warning; mail.<=warning - для регистрации сообщений уровня warning и ниже; mail.<warning - для регистрации сообщений ниже уровня warning; mail.>warning - для регистрации сообщений выше уровня warning.
Действие определяет, что нужно делать с сообщением. Возможны следующие варианты: имя_файла – записать сообщение в указанный файл (необходимо использовать абсолютный путь к файлу); @имя_машины – переслать сообщение демону syslogd на машину с указанным именем; @ip_адрес – переслать сообщение демону syslogd на машину с указанным IP адресом; пользователь1, пользователь2 – вывести сообщение на терминалы указанных пользователей; * - вывести сообщение на терминалы всех пользователей.
По умолчанию демон syslogd работает на 514 UDP порту, можно использовать флаг ss при запуске демона, для запрета работы по сети. Кроме того, в BSD системах допускается регистрация сообщений от прикладных процессов, которые не соответствуют ни одному стандартному средству. Для этого используется следующий синтаксис.
!myprog
*.error /var/log/myprog_error.log
*.* /var/log/myprog.log
В этом случае после строчки !myprog в качестве средства подразумевается процесс myprog, вплоть до следующей строчки со знаком ‘!’.
Следует также особо отметить, что демон syslogd не создает файлы, указанные в поле «действие», и для его корректной работы файлы должны уже существовать. Для создания файлов можно использовать команду touch или использовать специальную утилиту newsyslog, которая будет рассмотрена далее. Администратор должен быть особенно осторожным при задании прав доступа для журнальных файлов, поскольку в этих файлах может оказаться некоторая важная информация и даже в некоторых случаях пароли пользователей.
В процессе работы системы объем журнальных файлов может значительно увеличиться. Работать с большими файлами не очень удобно, кроме того, если не предпринимать никаких действий, эти файлы могут заполнить все свободное пространство на жестком диске. Кроме того, администратору вряд ли будет полезна информация с очень большим сроком давности. Поэтому периодически необходимо архивировать старые журнальные файлы. В большинстве систем для этого применяется утилита newsyslog. Данная утилита использует принцип ротации журнальных файлов. Это означает, что хранится несколько заархивированных версий файлов, и при необходимости текущий журнальный файл архивируется, все версии переименовываются, а самая старая версия удаляется. По умолчанию утилита newsyslog запускается демоном cron каждый час и проверяет необходимость архивации тех или иных файлов. Файл /etc/newsyslog.conf является файлом конфигурации этой утилиты. Использование утилиты newsyslog позволяет администратору очень гибко и эффективно настроить процедуру архивации журнальных файлов. Кроме того, утилита newsyslog после архивации файла создает пустой файл с указанными правами доступа, что облегчает использование системы syslog.
Файл newsyslog.conf состоит из текстовых строк, содержащих следующие поля: logfilename – имя журнального файла, owner.group – имя пользователя и группа, которые будут использованы в качестве владельцев для нового журнального файла; mode – режим доступа для нового журнального файла; count – количество архивных копий файла, которые необходимо хранить; size – выполнять архивацию и ротацию журнального файла, заданного в поле logfilename, если его размер превысил указанное количество килобайт; time - выполнять архивацию и ротацию журнального файла, если с момента последней архивации прошло указанное количество часов; ZB – поле флагов, если присутствует флаг Z, то файлы должны архивироваться при ротации, если присутствует флаг B, то файл считается двоичным и newsyslog не будет добавлять в этот файл никакой своей информации (по умолчанию newsyslog добавляет в новый созданный файл текстовую строку); в последних двух полях задается файл, в котором хранится идентификатор процесса и номер сигнала. Если эти поля не пустые, то после создания нового файла указанный сигнал будет послан указанному процессу. Таким образом процесс будет проинформирован о замене журнального файла. Обычно заполняется либо поле size, либо поле time, символ '*’ в этих полях обозначают любое значение. Если заполнены оба поля, то архивация будет произведена при выполнении хотя бы одного из двух условий.
Таким образом, можно сделать вывод, что в операционных системах семейства Unix система аудита реализована очень эффективно и позволяет администратору организовать централизованную политику учета сообщений для всей сети с возможностью своевременного архивирования журнальных файлов.
6.3. Вывод
Современные операционные системы располагают встроенными средствами обеспечения безопасности, которые позволяют обеспечить эффективные аутентификацию, авторизацию и аудит действий пользователей. Эти средства могут стать основой реализации политики безопасности. Однако, одних только встроенных средств операционных систем недостаточно для решения всех вопросов защиты, их необходимо дополнить специализированным программным обеспечением (антивирусное ПО, межсетевые экраны и т.п.).
Список литературы
Анин Б. Ю. Защита компьютерной информации. – СПб.: "BHV-Санкт-Петербург" - 2000, 384 стр
Баричев С. В. Криптография без секретов. –М.: Наука, 1998. –120 с.
Галатенко В. А. Информационная безопасность. –М.: Финансы и статистика, 1997. –158 с.
Герасименко В. А. Защита информации в автоматизированных системах обработки данных кн. 1.-М.: Энергоатомиздат, 1994.-400с.
Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации. Москва, 1992.
Конеев И. Р., Беляев А. В. Информационная безопасность предприятия.-СПб.: БХВ-Петербург, 2003.- 752с.:ил.
Мелюк А. А., Пазизин С. В., Погожин Н. С. Введение в защиту информации в автоматизированных системах. -М.: Горячая линия - Телеком, 2001.- 48с.:ил.
Оглтри Т. Практическое применение межсетевых экранов: Пер. с англ.-М.: ДМК Пресс, 2001.- 400с.:ил.
Сетевые операционные системы/ В. Г. Олифер, Н. А. Олифер. – СПб.: Питер, 2002. – 544с.: ил.
Соколов А. В., Степанюк О. М. Защита от компьютерного терроризма. Справочное пособие. - СПб.: БХВ - Петербург, Арлит, 2002.- 496с.:ил.
Чмора А. Л. Современная прикладная криптография. 2-е изд. -М.:Гелиос АРВ, 2002.-256с.:ил.
Шнайер Б. Прикладная криптография.- М. : Триумф, 2002. – 816с.
Эви Немет, Гарт Снайдер, Скотт Сибасс, Трент Р. Хейн. Unix, руководство системного администратора./Пер с англ. – СПб.: Питер: K.Издательская группа BHV,2002. – 928 c.: ил.