The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Проект по реализации утилит sudo и su на языке Rust"
Отправлено Аноним, 30-Апр-23 00:01 
Давайте пройдёмся вкратце по объему работ, чтобы осознать что нужно, чтобы было как в венде:

1. В Windows NT есть ACL/ACE на стороне ядра и есть стандарт SDDL.
Чтобы сформировать функциональный паритет, необходимо избавиться (перевести в легаси) от того наследия 70-х годов, которое стандартизировано в POSIX и предоставляется утилитами chown и chmod. Нужны Rich ACL на стороне ядра, причем так, чтобы они использовалист повсеместно, а не опционально. Есть несколько проблем с ACL в Linux:
Проблема ACL #1: То что в Linux называют POSIX ACL - это не стандарт, а непринятый черновик, который не встречается нигде кроме Linux.
Проблема ACL #2: То что в Linux называют POSIX ACL не достаточно "Rich", поэтому они и не стали стандартом. Нет поддержки утверждений (claims), conditional ACE, deny-правил и ограничено наследование.
Проблема ACL #3: То что в Linux называют POSIX ACL не является обязательным. В Linux всё работает через  "chmod 755" и SUID-биты, а так называемые POSIX ACL (getfacl, setfacl) опционально сбоку.
Героически решив эти проблемы необходимо распространить их на все файлы, сокеты и процессы, стандартизировав дескрипторы безопасности.
2. В Windows NT есть разные типы пользовательских сессий.
Вход в систему организуется службой winlogon. При этом пользовательская сессия может быть сетевой, локальной, интерактивной, пакетной, служебной итд. В зависимости от того каким способом производилась аутентификация. В Linux вместо этого используется PAM, который понимает только локальные сессии и любой успешный вход в систему считает равным по привилегиям другому. Учитывая, что UNIX PAM - это очередная неудаха в вопросах стандартизации входа в систему, а Linux PAM - вольная реализация (NIH от Red Hat) этой неудахи, его проще выкинуть целиком, чем пытаться исправить. Главной проблемой PAM является отсутствие поддержки Kerberos 5 и невозможность повторно использовать TGT, полученный пользователем при входе в систему в приложении запущенном в той же сессии. На самом деле там проблем столько, что проще переписать с нуля, что собственно и порождает костылики вроде sssd.

Процедура элевации (Запустить от имени администратора) - это комбинация п.1 и п.2. Вам нужны ACL на все процессы, файлы и сокеты и вот для интерактивных сессий предусмотрена такая возможность.

3. В Windows NT есть неотключаемая подсистема мандатного контроля и таргетированная политика и она работает поверх тех же ACL.
При этом Windows не использует выдуманные контексты и не пишет эту политику как в SELinux, там вся штука в SDDL. Существует понятие виртуальных дескрипторов безопасности. Они генерируются на службы, и приложения запущенные с пониженными привилегиями. Например, если приложение было установлено из магазина, значит его права ниже чем пользовательская сессия и ему создается виртуальный идентификатор пакета приложения в стиле S-1-5-90-... на основании уникального идентификатора приложения и идентификатора безопасности пользователя и ACL применяются к нему. Также у каждого приложения, которое установлено как служба заводится виртуальный SID, который доступен в форме UPN как NT SERVICE\myservicename. Ине надо сочинять 100500 всяких контекстов под софт из репозиториев и прописывать им глобальную политику внутри которой SELinux в ТРЕТИЙ РАЗ ПЕРЕИЗОБРЕТАЕТ ACL!!1

4. SUID-биты - это зло. Но от них нельзя просто так избавиться в Linux.
Вообще сама идея, что все файлы и все процессы имеют на себе дескрипторы безопасности и ACE и все работает относительно их быстрого расчета ядром, красива и прекрасна, но малореалистина на данном этапе развития юзерспейсных компонентов Linux. Нужно стандартизировать огромное количество подсистем, написать к ним права, написать утилиты, которые понимают это всё, а то уже с ping возникнут проблемы, если конечно не брать реализацию из юзерспейса. Windows NT же архитектурно построена так, что файловой системе нужно верить в последнюю очередь.

5. Local Security Authority
LSAAS - это еще одна подсистема, которая убирает требования к постоянному перезапрашиванию локальных и сетевых паролей и постоянного дозахвата прав. Суть в том, что есть клиент-серверная служба, позволяющая получить доступ к сохраненным паролям, полученным билетам и кэшу аутентификации. Это то что в GNOME и Mac OS делает Keyring. И вроде бы в Linux Keyring есть, но он опциональный и только на то, что умеет с ним работать. Опять же, вызовы API к LSA также требуют аутентификации и авторизации и применяются те же ACL. Но там много всего и большая часть всего функционала там выключена. Именно на эту подсистему действуют "локальные политики безопасности". Я не буду перечислять всего, с чем она работает просто потому что и букв много получилось.

И вот когда все это реализовать, изменить и стандартизировать, то количество обращений ко всяким sudo сведется к минимуму но не уйдёт.
Я напомню, что в Windows NT есть "вторичный вход в систему" seclogon - это служба, а не утилита. Она порождает специфический тип дескриптор и как раз и нужна для того чтобы запустить что-то от имени другого пользователя. При этом есть реализация в форме утилиты, но оно использует те же подсистемы. И это тоже нужно.

> токены имперсонации

Токены имперсонации - это из области SSO. Всё то что я написал имеет отношения преимущественно к локальным подсистемам, кроме пары слов про Kerberos.
Если мы начнем вспоминать про netlogon, про его делегирование на локальных службах, про Kerberos-учетки для компьютера и виртуальную учетную запись NT AUTHORITY\NETWORK SERVICE и сверху припорошим это встроенной поддержкой SAML2 и с некоторых пор OAuth2, то мы уйдем от реальных архитектурных проблем в юзерспейсе Linux, которые вынуждают использовать sudo и su на каждый чих. Сетевые протоколы аутентификации и авторизации в Windows реализуются именно поверх того, что есть, потому что кто-то когда-то в 90-е заоверинженирил Windows NT настолько, что своими стандартными подсистемами она способна реализовать и новые протоколы, хотя в те годы OAuth2 и в планах не было. При этом те функции SSO, которые использовались в NT в те годы выброшены на свалку истории и отключены по умолчанию больше 5-лет (NTLM-привязки пользователей заменены на сертификаты, CredSSP выключен, Digest тоже уничтожен в пользу современных SSO-протоколов).

Тут всё дело именно в архитектуре. Той самой архитектуры ядра и юзерспейсных подсистем, которая вся такая несовместимая с миром UNIX и изначально пришла из VMS.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, [email protected] (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру