My knowledge base

пятница, 13 июля 2012 г.

Проблема Windows для разделения прав пользователей

Вот представьте себе такую задачу. Вам нужно считать конфигурацию операционной системы, скажем для контроля настроек. Поскольку это сбор, т.е. чтение информации, вы скорее всего захотите сделать это без прав администратора, чтобы не напрягать владельца ОС (чтобы ничего не сломалось). Получится ли считать всю информацию о настройках Windows без прав администратора? Неа, не получиться. На Unix\Linux получиться - там есть механизм разделения полномочий RBAC. Для на счёт Windows поддержка Microsoft отвечает: "by design, что вы хотите от системы, спроектированной 20 лет назад". Тогда ведь о безопасности особо не пеклись.

Lsa*InformationPolicy APIs were never designed (almost 20 years ago)
for remoting, and were designed to require administrative rights.  These APIs manage the policy that the security subsystem enforces and it’s easy to effectively make someone an admin via policy, without regards to group membership.”, т.е. с точки зрения архитектуры системы аудита подразумевается локальное использование и права администратора.

«Some parts of security policy can be delegated on certain releases,
e.g. with auditpol.exe you can set the DACL on audit policy and delegate it to others; or you can assign SeSecurityPrivilege.», т.е. можно использовать возможность делегирования полномочий через auditpol.exe (DACL на политики аудитора) или назначение привилегии SeSecurityPrivilege.

Ссылка на документацию по LSA: Managing Policy Information
  (“The LSA
provides functions that administrators can use to query and set global policy
information for the local computer and the domain”) и Security Management
  (“The LSA
Policy API, the Password Filter API, the Safer API, and the Service Security
Attachments API are intended for use by developers of applications that enable
administrators to manage and secure their systems”). Т.е код, который
использует LSA функции, должен выполняться в контексте учетной записи
администратора.

Ссылка на документацию по LSA: Managing Policy Information
  (“The LSA provides functions that administrators can use to query and set global policy information for the local computer and the domain”) и Security Management   (“The LSA Policy API, the Password Filter API, the Safer API, and the Service Security Attachments API are intended for use by developers of applications that enable administrators to manage and secure their systems”). Т.е код, который использует LSA функции, должен выполняться в контексте учетной записи администратора.


Единственное, что остается писать в Microsoft Connect просьбу когда-нибудь вспомнить о безопасности и принципе наименьших привилегий

Подробнее, что нельзя получить без прав админа:


                    I.            Информация о жестком диске ПК (чтение информации о жестком диске).
                  II.            Права пользователей (чтение списка пользователей с указанными привилегиями):
1.       доступ к диспетчеру учетных данных от имени доверенного вызывающего;
2.       изменение метки объекта;
3.       создание символических ссылок;
4.       увеличение рабочего набора процесса;
5.       доступ к компьютеру из сети (SeNetworkLogonRight);
6.       работа в режиме операционной системы (SeTcbPrivilege);
7.       настройка квот памяти для процесса (SeIncreaseQuotaPrivilege);
8.       разрешить локальный вход в систему (SeInteractiveLogonRight);
9.       архивирование файлов и каталогов (SeBackupPrivilege);
10.   обход перекрестной проверки (SeChangeNotifyPrivilege);
11.   изменение системного времени (SeSystemTimePrivilege);
12.   создание файла подкачки (SeCreatePagefilePrivilege);
13.   создание маркерного объекта (SeCreateTokenPrivilege);
14.   создание глобальных объектов (SeCreateGlobalPrivilege);
15.   создание постоянных объектов совместного использования (SeCreatePermanentPrivilege);
16.   отладка программ (SeDebugPrivilege);
17.   отказ в доступе к компьютеру из сети (SeDenyNetworkLogonRight);
18.   отклонить локальный вход (SeDenyInteractiveLogonRight);
19.   разрешение доверия к учетным записям и компьютеру при делегировании (SeEnableDelegationPrivilege);
20.   принудительное удаленное завершение (SeRemoteShutdownPrivilege);
21.   создание журналов безопасности (SeAuditPrivilege);
22.   имитация клиента после проверки подлинности (SeImpersonatePrivilege);
23.   увеличение приоритета выполнения (SeIncreaseBasePriorityPrivilege);
24.   загрузка и выгрузка драйверов устройств (SeLoadDriverPrivilege);
25.   закрепление страниц в памяти (SeLockMemoryPrivilege);
26.   вход в качестве пакетного задания (SeBatchLogonRight);
27.   вход в качестве службы (SeServiceLogonRight);
28.   управление аудитом и журналом безопасности (SeSecurityPrivilege);
29.   изменение параметров среды оборудования (SeSystemEnvironmentPrivilege);
30.   запуск операций по обслуживанию логических дисков (SeManageVolumePrivilege);
31.   профилирование одного процесса (SeProfileSingleProcessPrivilege);
32.   профилирование загруженности системы (SeSystemProfilePrivilege);
33.   извлечение компьютера из стыковочного узла (SeUndockPrivilege);
34.   замена маркера уровня процесса (SeAssignPrimaryTokenPrivilege);
35.   восстановление файлов и каталогов (SeRestorePrivilege);
36.   завершение работы системы (SeShutdownPrivilege);
37.   овладение файлами или иными объектами (SeTakeOwnershipPrivilege).
                III.            Политики аудита (чтение информации о статусе включения указанного аудита):
1.       аудит событий входа в систему;
2.       аудит управления учетными записями;
3.       аудит доступа к службе каталогов;
4.       аудит входа в систему;
5.       аудит доступа к объектам;
6.       аудит изменения политики;
7.       аудит использования привилегий;
8.       аудит отслеживания процессов;
9.       аудит системных событий.

Комментариев нет:

Отправить комментарий