forked from vlsergey/infosec
-
Notifications
You must be signed in to change notification settings - Fork 0
/
os_access_controls.tex
58 lines (43 loc) · 8.57 KB
/
os_access_controls.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
\section{Контроль доступа в ОС}
\selectlanguage{russian}
\subsection{Windows}
%http://www.gentlesecurity.com/blog/andr/cracking_windows_access_control.pdf
%http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx#upm_ovwim
%http://msdn.microsoft.com/en-us/library/bb625963.aspx
%http://msdn.microsoft.com/en-us/library/bb625964.aspx
Операционные системы Windows, вплоть до Windows Vista, использовали только дискреционную модель безопасности. Владелец файла имел возможность изменить права доступа или разрешить доступ другому пользователю.
Начиная с Windows Vista, в дополнение к стандартной дискреционной модели субъекты и объекты стали обладать мандатным уровнем доступа, устанавливаемым администратором (или по умолчанию системой для новых созданных объектов) и имеющим приоритет над стандартным дискреционным доступом, который может менять владелец.
В Vista мандатный уровень доступа предназначен в большей степени для обеспечения \emph{целостности} и устойчивости системы, чем для обеспечения секретности.
Уровень доступа объекта (\langen{integrity level} в терминологии Windows) помечается шестнадцатеричным числом в диапазоне от \texttt{0} до \texttt{0x4000}, большее число означает более высокий уровень доступа. В Vista определены 5 базовых уровней:
\begin{itemize}
\item ненадёжный (Untrusted, \texttt{0x0000});
\item низкий (Low Integrity, \texttt{0x1000});
\item средний (Medium Integrity, \texttt{0x2000});
\item высокий (High Integrity, \texttt{0x3000});
\item системный (System Integrity, \texttt{0x4000}).
\end{itemize}
Дополнительно объекты имеют три атрибута, которые, если они установлены, запрещают доступ субъектов с более низким уровнем доступа к ним: cубъекты с более низким уровнем доступа не могут:
\begin{itemize}
\item читать (\langen{no read-up});
\item изменять (\langen{no write-up});
\item исполнять (\langen{no execute-up}).
\end{itemize}
объекты с более высоким уровнем доступа. Для всех объектов по умолчанию установлен атрибут запрета записи объектов с более высоким уровнем доступа, чем имеет субъект (no write-up).
Субъекты имеют два атрибута:
\begin{itemize}
\item запрет записи объектов с более высоким уровнем доступа, чем у субъекта (no write-up, эквивалентно аналогичному атрибуту объекта);
\item установка уровня доступа созданного процесса-потомка как минимума от уровня доступа родительского процесса (субъекта) и исполняемого файла (объекта файловой системы).
\end{itemize}
Оба атрибута установлены по умолчанию.
Все пользовательские данные и процессы по умолчанию имеют средний уровень доступа, а системные файлы -- системный. Например, если в Internet Explorer, который в защищённом (\langen{protected}) режиме запускается с низким уровнем доступа, обнаружится уязвимость, злоумышленник не будет иметь возможности изменить системные данные на диске, даже если браузер запущен администратором.
Уровень доступа процесса соответствует уровню доступа пользователя (процесса), который запустил процесс. Например, пользователи LocalSystem, LocalService, NetworkService получают системный уровень, администраторы -- высокий, обычные пользователи системы -- средний, остальные (\langen{everyone}) -- низкий.
По каким-то причинам, вероятно, для целей совместимости с ранее разработанными программами и/или для упрощения разработки и настройки новых сторонних программ других производителей, субъекты с системным, высоким и средним уровнями доступа создают объекты или владеют объектами со \emph{средним} уровнем доступа. И только субъекты с низким уровнем доступа создают объекты с низким уровнем доступа. Это означает, что системный процесс может владеть файлом или создать файл со средним уровнем доступа, и другой процесс с более низким уровнем доступа, например средним, может получить доступ к файлу, в том числе и на запись. Это нарушает принцип запрета записи в объекты, созданные субъектами с более высоким уровнем доступа.
\subsection{Linux}
Стандартная ОС Unix обеспечивает дискреционную модель контроля доступа на следующей основе.
\begin{itemize}
\item Каждый субъект (процесс) и объект (файл) имеют владельца, пользователя и группу, которые могут изменять доступ к данному объекту для себя, других пользователей и групп.
\item Каждый объект (файл) имеет атрибуты доступа на чтение (r), запись (w) и исполнение (x) для трёх типов пользователей: владельца-пользователя (u), владельца-группы (g), остальных пользователей (o) -- (u=rwx, g=rwx, o=rwx).
\item Субъект может входить в несколько групп.
\end{itemize}
В 2000 г. Агентство Национальной Безопасности США (NSA) выпустило набор изменений SELinux с открытым исходным кодом к ядру ОС Linux версии 2.4. Начиная с версии ядра 2.6, SELinux входит как часть стандартного ядра. SELinux реализует комбинацию ролевой, мандатной и дискреционной моделей контроля доступа, которые могут быть изменены только администратором системы (и/или администратором безопасности). По сути, SELinux приписывает каждому субъекту одну или несколько ролей, и для каждой роли указано, к объектам с какими атрибутами они могут иметь доступ и какого вида.
Основная проблема ролевых систем контроля доступа -- очень большой список описания ролей и атрибутов объектов, что увеличивает сложность системы и приводит к регулярным ошибкам в таблицах описания контроля доступа.