The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Microsoft предложил систему управления доступом IPE для ядра Linux, opennews (??), 29-Фев-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


16. "Microsoft предложил систему управления доступом IPE для ядра..."  +1 +/–
Сообщение от Аноним (16), 29-Фев-24, 14:31 
NTFS/ntoskrnl ACL на порядок (!) круче, чем то, что есть в Linux.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

23. "Microsoft предложил систему управления доступом IPE для ядра..."  –3 +/–
Сообщение от GaB4taa6 (?), 29-Фев-24, 14:50 
А чего вы дизлайкаете? Он ведь правду говорит. В винде можно создать, например несколько групп пользователей, и для кажой из групп настроить права доступа, когда в линуксе у тебя только настройки для одного пользователя, одной грппы и для всех остальных.
Ответить | Правка | Наверх | Cообщить модератору
Часть нити удалена модератором

34. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от commiethebeastie (ok), 29-Фев-24, 15:05 
> ps насколько я помню в макоси так же, но что характерно она
> основана на бздяшных кодах и ядре XNU.
> вот оно превосходство академического кода, над поделками студней.

Ты даже понятия не имеешь что ты несешь. ACL это лютый антипаттерн программирования, когда вместо группировки, выдергивают отдельные части наружу и делают лапшу.

Ответить | Правка | Наверх | Cообщить модератору

40. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от User (??), 29-Фев-24, 15:20 
Да-да, надо только организовать работу так, чтобы один человек работал над одной задачей и у каждой задачи был один набор данных - и все-все нормально без вот этих вот ваших acl будет!
Ответить | Правка | Наверх | Cообщить модератору

43. "Microsoft предложил систему управления доступом IPE для ядра..."  –1 +/–
Сообщение от commiethebeastie (ok), 29-Фев-24, 15:30 
Еще раз, ты понятия не имеешь, что несёшь. Apple и Microsoft сами не пишут код в стиле, в котором работает ACL. Создавался он во времена, когда файловый сервер был помоечкой на группе жестких дисков. И закрытый через ACL файлик твоего жирного директора не создавал проблем с лапшой из прав.
Ответить | Правка | Наверх | Cообщить модератору

61. "Microsoft предложил систему управления доступом IPE для ядра..."  –1 +/–
Сообщение от User (??), 29-Фев-24, 16:56 
> Еще раз, ты понятия не имеешь, что несёшь. Apple и Microsoft сами
> не пишут код в стиле, в котором работает ACL. Создавался он
> во времена, когда файловый сервер был помоечкой на группе жестких дисков.
> И закрытый через ACL файлик твоего жирного директора не создавал проблем
> с лапшой из прав.

Я тоби одну вещь скажу - только ты не обижайся! Ты, как программист, её не поймешь - но постарайся запомнить, ладно? Всем вот НАСТОЛЬКО пофиг что там "пишут" или "не пишут" программисты - что просто ПОФИГ. Важно - решает ли ПО задачи бизнес-области или не решает.
Задача совместного владения группами ресурсов в отношении многие-ко-многим - бизнесовая, и от того, что какому-то нитакусику не хочется её решать... ну ой. От "хотения" или "неписания" конкретного илитария - acl никуда не исчезнут, они могут двигаться с ФС на уровень БД или там приклада - но они останутся.
Да, конечно от абстракции "файл" можно-и-нужно переходить к более высокоуровневым абстракциям - там "документ", "проект" вот это всё - но вот беда, с т.з. большинства бизнесов абстракция "файл" примерно "бесплатная" (Реально - нет, но порог входа и кривая сложности создают неприятную иллюзию), а вот СЭД или там Система Управления Проектами, электронный архив или еще что - штука изрядно "дорогая" с самых разных сторон, так что "файловые сервера" с нами очень и очень надолго.
Конечно, современные системы организации совместной работы эту стоимость изрядно снижают - но тут, сюрприиз! Линуксам похвастаться ровным счетом нечем. Неамае у вас своих onedrive'ов\googledrive'ов, а то, что есть - ну прям такоЭ.

Ответить | Правка | Наверх | Cообщить модератору

67. "Microsoft предложил систему управления доступом IPE для ядра..."  –2 +/–
Сообщение от commiethebeastie (ok), 29-Фев-24, 17:03 
Правильно, большой бизнес выбрал ACL в базе данных (облака), а не в файловой системе и реестре. А что у вас на самом днище IT происходит, всем пофигу. Собственно такие днищеайтишники и получают соответствующую зарплату.
Ответить | Правка | Наверх | Cообщить модератору

215. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от Аноним (215), 03-Мрт-24, 23:09 
Я давно не читал столь отборную ахинею, даже не поленился лог модерирования открыть...
Мне только одно не понятно, на каких пропагандистских курсах тебе преподали, что ACL - это "лютый антипаттерн программирования". Убери эту дурь из головы.

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

В ОС Windows ACL развивались, чтобы решать бизнес задачи ПОВЕРХ них. Самих ACL для бизнес-задач никогда не достаточно. Да, они самые продвинутые из всех, но, нет, их никогда не хватит. В разных государствах в СНГ исторически существует порочная практика - пихать все корпоративные файлы на единый файловый сервер и решать вопросы авторизации средствами ACL файловой системы NTFS. То что это вообще работает на мелких и средних развертываниях - это лишний плюсик в карму авторов NT ACL, но на крупных развертываниях так делать нельзя, потому что это тяжело администрировать.

Исторически сложилось, что ACL легко интегрируются в службы каталогов, например, AD DACLs (Directory ACL), но и там это используется для низкоуровневых задач. Люди часто не понимают, что если речь идёт о корпоративной авторизации для доступа к данным вам нужен RBAC или даже ABAC, который, в общем случае, нельзя построить поверх ACL. Теоретически, минимальный можно построить поверх конкретно AD и его ACL, но это не пригодно к внедрению как RBAC. Но это я говорю про один портал, а если их много?

А если их много, вам нужны не ACL, Access Control Policy Sets. Например у вас есть набор фронтендов публикации вебсервисов и вам нужно вменять политики прав доступа относительно каких-нибудь токенов полученных из децентрализированной системы аутентификации. Это значит, что вы реализуете PEP (Policy Enforcement Point), сервер, который стоит между публикацией и запросом клиентского приложения. И вот если у вас таких политик много, написаны бизнес-процессы по их изменению на уровне организации, то обычно их принято оформлять как XACML: https://en.wikipedia.org/wiki/XACML
Это, кстати, к вопросу, почему "кровавый ынтерпрайз" так любит свой SAML2 и его расширения.

Начиная с 2014-го года активно (и важно понимать, что параллельно) развивается иная консьюмерская модель, которая применяется в рещениях B2C и работает поверх OpenID Connect и OAuth2. Разница в том, что у вас в корпоративной модели безопасники вменяют политики (клиенту можно, что безопасники разрешили), а в консьюмерской пользователь разрешает передачу данных, отправляя OAuth2 Consent (приложению можно, что клиенты разрешили). Обе эти модели имеют право на жизнь и прекрасно сосуществуют в корпоративном мире.

Казалось бы, причем тут ACL? ACL - это тот низкоуровневый механизм в каталоге, базе или на ФС, на который смотрят все эти системы. То что ACL на файловой системе не масштабируется - это стало понятно с появления функционала Public Folders в Microsoft Exchange. Они были предложены на замену файловым серверам. Когда оказалось, что Exchange не справляется и нужно еще больше функционала, этот кусок вытащили как Microsoft Office Server, а затем переименовали в Microsoft SharePoint. Причем старый урезанный функционал Public Folders с ACL-ками внутри Exchange до сих пор жив внутри в режиме какой-то там legacy-совместимости.

В самом крупном случае для организации вменяемое модели прав доступа в приложениях вам нужно:
Для B2B
1. Каталог пользователей с кучей стандартных атрибутов, для последующей конвертации в утверждения (claims)
2. База данных на стороне каждого приложения с расширенными атрибутами, специфичными для каждого конкретного приложения. Тоже для последующей конвертации в утверждения. В этих базах создаётся внутреннее понимание ролей, специфичных для приложения.
3. Secure Token Service - реализующий выдачу OAuth2 Token и SAML2 Assertion причём обоих одновременно. Он реализует выдачу подписанных сертификатами атрибутов в соответствующий формат и реализует федерации между партнерами (с другими организациями), когда нужно выдать доступы работникам одного предприятия в сервисах партнёра. Также STS должен уметь конвертировать утверждения в Kerberos-билеты.
4. Автоматизация кадрового учёта - формирует отражение ролей в смысле RBAC на НСИ в виде штатного расписания и должностных инструкций
5. Identity Management System - система управления ролями, реализующая модель "авторизация как бизнес-процесс", там у вас будут и политики и администрирование политик. Здесь определяются группы ролей.
6. ACL - на стороне операционных систем конечных устройств, файловых серверов, терминалов и всего остального.

Для B2C или взаимоотношениями с франч/ДЗО
7. Еще один федерированный (в смысле Kerberos) каталог с пользователями дочерних франч-организаций или пользователи-клиенты бизнеса
8. Облегченный STS реализующий исключительно OAuth2
9. CRM-система - формирует отражение ролей (в смысле RBAC) на НСИ в виде справочников контрагентов и услуги.
10. Еще одна IMS (опционально) - нужна, если существует множество разных клиентских порталов и личных кабинетов (у операторов связи так часто случается).

В случае применения парадигмы Bring yout own device или в случае внешнего контроля над конечным оборудованием дочерних предприятий
11. Инфраструктура интеграции с облачным провайдером-поставщиком Mobile Device Management и Endpoint Security. То что называется гибридным облаком.
12. Удаленное управление на стороне конечных мобильных устройств

Иными словами, если в вашей ОС ACL реализованы плохо, то она не придёт на Workstation и её не будет в терминале. Обратите внимание, что для мобильных телефонов ACL не особо-то и актуален, потому что они не шибко многопользовательские. Кроме того, мандатный контроль в ОС реализован c использованием ACL. То что входит в официальный стандарт POSIX является

Теперь что касается Linux:
Эта ОС исторически любит сопротивляться объективной реальности. Её пользователи часто напоминают адептов культа, бредящих о величии. Примеров много:
- ACL не нужен, нам хватит POSIX Permissions из 70-х.
- Ой нет, нас не хотят нигде использовать, давайте всунем недоделанные всеми выброшенные и никем кроме Linux не поддерживаемые POSIX ACLs, которые черновик.
- Ой, они не подходят большинству людей, давайте сделаем их опциональными
- Нам не нужен мандатный контроль.
... Пришло АНБ и написало SELinux...
- Из-за того что у нас нет нормальных ACL на уровне ядра система мандатного контроля обязана вменять ACL в своем собственном формате.
Когда до придурков, которые разрабатывают недо-каталоги вроде FreeIPA дойдёт, что контейнер OU (Organizational Unit) - это средство применяемое сервис провайдерами для синхронизации одних каталогов внутрь других и корпоративными пользователями в случае поглощения вновь купленных предприятий, то может кто-то догадается это куда-то ставить вместо AD в крупное развертывание. Придурки ведь умают, что пользователей нужно хранить в базах, как бы не понимая как медленно работает БД по сравнению с каталогом и как сложно в базе поменять схему.

Ну то есть такие необразованные фанатики как ты встречаются чаще чем хотелось бы и им там даже доверяют принимать решения:
https://en.wikipedia.org/wiki/TCP_offload_engine#Support_in_...
Это конечно оффтопик. Но да, разработчики-программисты ядра Linux решили, что TOE им не нужно, годами сопротивлялись внедрениям LRO и LSO и вот теперь мы имеем то что имеем: для работы с сетью тебе нужно взять драйверы сетевки разной степени проприетарности и работать с ними через DPDK, потому что ядро Linux и его адепты прибывают в состоянии вечного отрицания. Про подсистему хранения даже начинать не хочу. Про
И я уже не говорю про сеть и подсистему хранения. Ой всё...

Вот тебе пара тезисов попроще:
- То что в компаниях в которых ты работал точечно выдавали права на шаре каждому пользователю руками, даже не используя утверждения и не смотрели на атрибуты каталога - это не проблема ACL, это твои личные трудности, травмы детства и прочий бред.
- ACL - это низкоуровневый функционал, который лежит в основе много каких компонентов. От того что вы положили файлы в SharePoint Sites / Sharepoint Online, которые лежат в SQL, который кладут Blob Storage на SMB-шару (я сейчас не шучу, это так деплоится RBS и Azure Blob Storage) и вот там-то у вас что... вы не поверите...

Что ACL у него на файловой системе прямо совсем не нужны? "UNIX Permissions из 70-х хватит всем" или эти ископаемые права доступа тоже не нужны? А что нужно? Office 365? А ты знаешь как он работает? Про RBS и SMB-шары я сказал. Про то что outlook.com и Exchange Online хранят данные в Jet Blue (ESE) причем террабайтами рассказать? Или про то что AzureAD/Entra - это Active Directory работающее поверх того же Jet Blue. С теми самыми DACL, которые SharePoint Online так же как и On-Prem версия высасывает в базу чтобы присобачить к внутренним ролям портала.

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

221. "Microsoft предложил систему управления доступом IPE для ядра..."  +1 +/–
Сообщение от EULA (?), 04-Мрт-24, 09:54 
ACL такая классная вещь, которую можно сломать такой простой операцией, как удаление объекта в системе авторизации, которому присвоен определенный SID для файла, каталога или процесса, а потом удивляться, почему для удаления данного SID-а нужно перезапускать всю службу. И не дай Бламер SID не будет известен ресурсу, на котором сервис развернут, тогда доступа к объекту не будет даже у службы, которая его создала.
Пример, когда все падает: NFS, WebDAV, NextCloud. Да, Балмер побери, даже шара в доверенном домене Windows падалет, если ты хочешь прочитать атрибуты для объекта, созданного удаленным SID-ом.
Конфликтные ACL никак не фиксятся. Если у для объекта определены доступы по группам A разрешено, и B - запрещено, то пользователь, который входит в обе эти группы в одно время будет иметь доступ к объекту, а в другом не будет иметь.
Двадцать лет назад для той же винды 2000, 2003, XP неизвестный SID означал, что доступ для него доступен всем.
Третья дыра с ACL - это наличие "broadcast SID", которые всегда валидны для любого объекта. Поэтому помимо SID для доступа к службе всегда нужно подключаться через третью службу, которая всегда будет проверять, а не подменил ли ты себе SID.
Ответить | Правка | Наверх | Cообщить модератору

222. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от Аноним (215), 04-Мрт-24, 17:03 
О! Очередная ахинея! Вы просто каталогами пользоваться не умели, что в 2000 году, что сейчас, раз такое пишете.

SID - это идентификатор субъекта. Он состоит из блоков, которые хорошо известны:
S-(version 1)-(base authority)-(sub aiuthority-1)-...-(sub aiuthority-N)-(RID)
RID - это относительный идентификатор, часть из которых, что называется, well-known и они есть не у всех субъектов.
base authority у обычных пользователей 5 (NT Authority), но есть и другие.
Например:
S-1-5-18 - это SYSTEM, то же самое что и root.
S-1-5-21-ХХХХХ-ХХХХХ - доменные пользователи и группы.
Их там много, есть документация. https://learn.microsoft.com/en-us/openspecs/windows_protocol...
Эта нотация нужна чтобы максимально избежать коллизий в именовании субъектов, локализовав их в sub-authority. При этом есть выделенные base authority для тех задач, когда разработчику нужно чтобы SID специально были не уникальны.

Вы понимаете, что это просто идентификатор пользователя?! RID - это числовой идентификатор пользователя, это то же самое, что UID и GID. SID выполняет ту же самую функцию.

> ACL такая классная вещь, которую можно сломать такой простой операцией, как удаление объекта в системе авторизации, которому присвоен определенный SID для файла

Ну то есть если вы ввели Linux в домен, например в ту же FreeIPA и выдали UNIX Permissions для пользователя с определенным идентификатором, или создали локального пользователя и выдали права ему. А потом их удалили, то что у вас будет на ФС? А?! Правильно! UID и GID там будет торчать от старого пользователя. И когда там старый SID остался торчать в Windows, то это чем отличается от от торчащих UID и GID, я стесняюсь спросить?

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

А альтернатива какая? Запускать всё под тонной локальных пользователей? Ну на твоём локалхосте это работает, на то он и локалхост.

> Конфликтные ACL никак не фиксятся.

Вот тебе каноничный алгоритм:
1. Применить все явные Deny записи в ACL
2. Применить все явные Allow записи в ACL
3. Применить все унаследованные Deny записи в ACL
4. Применить все унаследованные Allow записи в ACL
У тебя лапки, просто. Во-первых если уж ты так ненавидишь ACL, то зачем тебе Deny-правила. Тебе же с UNIX Permissions всё будет хорошо. Во-вторых, наследование всегда имеет низкий приоритет.
- Если ты унаследовал записи от вышестоящего каталога, они всегда пойдут во вторую очередь
- Windows Explorer создаёт временные (volatile) записи в ACL, если пользователь с правами администратора лазит по каталогам, в которых ему быть нельзя, но нажимает кнопочку со щитком "Продолжить" в GUI.
В изначальном каталоге эти временные записи будут явными, а в дочерних, если для объекта включено наследование всех прав, станут унаследованными.
Твоя временность и конфликты все от неграмотности и не умения читать документацию.

> наличие "broadcast SID", которые всегда валидны для любого объекта. Поэтому помимо SID для доступа к службе всегда нужно подключаться через третью службу, которая всегда будет проверять, а не подменил ли ты себе SID.

Вся эта инфраструктура рассчитана на применение Kerberos. KDC должен выдать билет, который ты там будешь предъявлять. Если тебе нужно аутентифицироваться НА службе, тебе нужен TGS, SPN и делегирование. Опять же, Kerberos 5 он не только в Windows так работает. Он везде такой, там всегда есть третья проверяющая сторона.

Объясни членораздельно, что ты собрался проверять и что ты имеешь в виду под "broadcast SID"? Ты имеешь в виду какие-то well-known учетные записи вроде NT AUTHORITY\NETWORK SERVICE, которые могут указывать на разные учетные записи в каталоге. Или ты говоришь про виртуальные SID в стиле NT SERVICE\myservicename
Опять же, не вижу связи конкретно с ACL. Применение виртуальных аккаунтов как раз наоборот помогает абстрагироваться от доменных и локальных пользователей при работе с локальной файловой системой. В чем тут дыра?

Ответить | Правка | Наверх | Cообщить модератору

224. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от EULA (?), 05-Мрт-24, 12:41 
>  Он состоит из блоков, которые хорошо известны..

Я где-то заявлял обратное?

> S-1-5-18 - это SYSTEM, то же самое что и root.

Ваша первая ошибка в понимании аналогичных объектов в Windows и Unix. У root ID всегда 0, а вот у системных процессов он варьируется от 1 до 99. Рут всегда имеет права. System в Windows можно запретить доступ к объектам ФС.

> А потом их удалили, то что у вас будет на ФС?

Внезапно, в Posix-правах наличие пользователя/группы для заданного ID у объекта ФС, вторично. Файловой системе, ядру и окружению глубоко пофиг есть ли объект пользователь для которого задан ID. Я могу в правах на объект указать ID, которого нет в системе. Например, я могу для объекта доступного по NFS или WebDAV шаре на машине не в домене, из которого придет прльзователь, указать ID, скажем, 300185, зная что для доменного пользователя на на его машине доменный SID маппится в такой UID.
Для ACL - наличие объекта, к которому привязан SID, обязательно. Если его нет, я не могу задать для него права. А если он удален, то я не могу изменить права. При этом, если это права унаследованные от вышестоящего объекта, то я не могу вообще удалить объект, не слома ФС.

> Ну не принято удалять пользователей в каталогах, если в других частях инфраструктуры есть ссылки на них.

Вот именно из-за проблем с жесткой привязкой ACL к пользователю, удалять его "не принято". Так же как и не принято удалять построенное доверие между доменами, если пользователи поучали возможность создавать свои объекты в "чужих" сервисах.


> Вот тебе каноничный алгоритм:

Ничего, что этот алгоритм для объектов файловой системы работает не так, как для каталога?

> Во-вторых, наследование всегда имеет низкий приоритет.
>  они всегда пойдут во вторую очередь

Низкий приоритет имеет только, если противоположные права находятся на разных уровнях, например на уровне группы, в которой пользователь находится, и уровне пользователя из этой группы. А если для пользователя, который есть сразу в двух группах с противоположными правами, политики применяются случайным образом, Об этом сказано в документации MS раз пять или шесть. Для тупых выделено специально через особое привлечения внимания. И раз в пол года на форумах MSDN появляется тип, который не может понять почему у него такая проблема.
Для наглядного примера. Есть пользователь Вася, который состоит в группе "Друзья директора" и в группе "Пойманные за фаппингом на работе". Первой группе разрешено заходить в каталог "клубничка", второй - нет. Бедный Вася то имеет доступ к клубничке, то не имеет.

> то зачем тебе Deny-правила

Когда изначально права - все, что не разрешено, то запрещено, наличие deny-правил не нужно. Deny-правила появились во времена NT 4, когда ФС, имеющаяся у MS не знала запретов на доступ пользователя. И тогда было "все, что не запрещено, то разрешено". И только, когда MS сделала клиент для домена Novell, тогда они столкнулись с тем, что нужно добавлять разрешения "allow".

> Вся эта инфраструктура рассчитана на применение Kerberos

Изначально Kerberos предполагался для другого - для единой авторизации сразу на всех связанных сервисах. Проверку верификации SID внедрили только с в 2005 году. Именно по этому в Windows билет kerberos выдается после авторизации в домене, а не авторизация на ПК происходит после получения билета kerbros и идентификации пользователя.

> Ты имеешь в виду какие-то well-known учетные записи вроде NT AUTHORITY\NETWORK SERVICE, которые могут указывать на разные учетные записи в каталоге

Не на разные. На все учетные записи, по индивидуально. На этом была основана атака на сервер, если используется для авторизации LanManger или NTLMv1.
> Опять же, не вижу связи конкретно с ACL

Если ты убеждаешь систему, что твой SID валиден для доступа к объекту, ты получаешь доступ к этому объекту.И все из-за того, что allow понимается СИСТЕМОЙ по умолчанию.

Ответить | Правка | Наверх | Cообщить модератору

228. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от Аноним (228), 05-Мрт-24, 22:11 
Понятно, это не молодой дурак, а старый, что делает ситуацию еще печальнее:
1. Я вполне понимаю, что SID S-1-5-18 != 0. Но меня не интересует нумерология.
И да, у него пониженные привилегии. То за что в Linux борются последние лет так 10. То X от него не запускать, то в Gnome не входить, то в SSH запретить. Ничего плохого в этом нет. Опять же, пользователь LocalSystem имеет бесконечные и неотъемлемые права на ФС. А вот 2 его виртуальных учетных записи BUILTIN\Administrators и NT AUTHORITY\SYSTEM могут быть ограничены в правах. Даже если вы зачем-то забрали права у обеих учетных записей их всегда можно восстановить.

2. У меня просто нет слов от твоего вероломного лицемерия. Когда на ФС в атрибутах торчит UID 300185 удаленного объекта  - это нормально, а когда SID S-1-5-21-1004336348-1177238915-682003330-1234 - то ФС сломана. Ой прости, не от удаленного, а от "несуществующего".

3. SID всегда жестко привязывается к объекту. В этом его суть. Это сделано специально, чтобы не нужно было делать маппинг по цифрам. Вся это косорылая ископаемая нумерология берется от того что Unix PAM не понимает разницу локального входа в систему от сетевого. Из-за этого поддержки Kerberos SSO в нем нет и типов сессий в нем тоже нет. Когда его "стандартизировали", тогда на Windows все и перешили, потому что, среди прочего, не надо морочить голову с МАППИНГОМ. Этот вонючий маппинг не является самоцелью. Он решает какую-то другую проблему, потому что иначе в мире Unix её решить не получается в силу убогости кода и архитектуры, на которой он основан.
В тех редчайших случаях, когда маппинг доменного к локальному пользователю Windows всё же нужен, то вы делаете либо через сертификаты (примеры можно найти в документации к WSMAN, там такое часто нужно, когда доменный пользователь олицетворяется под локальным) либо выносите аутентификацию на OpenID Connect или SAML2 и затем через WIF (c2WTS) возвращаете обратно, но это разработка. При этом взаимодействие с NFS и её маппингами до сих пор есть и работает. В AD специально по случаю UID и GID завели для этого и рядом другой LDAP-каталог можно поставить, если от AD вас прыщит.

4. Алгоритм расчёта прав доступа работает так как я написал. На основании алгоритма выстраивается канонический порядок ACL. https://learn.microsoft.com/en-us/windows/win32/secauthz/ord...
Я уже тебе написал один раз повторю еще раз. Такое может возникнуть только от волатильных записей, которые со временем пропадают. Приведи, пожалуйста, одну из тех "пяти или шести" статей документации, где сказано о случайностях в поведении ACL.

5. Домен NT4/2000 не просто стар и не поддерживается, а с ним уже даже соединиться нельзя на современных версиях Windows (криптографические шифры в блеклисте), равно как и LanManager, и SMB1, и почти весь старый сетевой стек, который MS купил у IBM когда-то. Остались только куски NetBIOS и dclocator, который признаны устаревшими, но не отключены по умолчанию для всех. От этих технологий давно избавились. Но для старых дураков у кого Windows XP в голове - это самый последний Windows, а Kerberos - шайтан-машина и они не понимают и не применяют ни в одной ОС. И конечно тут именно ACL виноваты. И SID-ы (я напоминаю это просто набор цифр!) плохие. И безопасность IBM-овского старого барахла откапали с помойки и притащили как проблему безопасности (отключено это всё уже давно).

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

> Именно по этому в Windows билет kerberos выдается после авторизации в домене, а не авторизация на ПК происходит после получения билета kerbros и идентификации пользователя.

И вот этот "казнить нельзя помиловать", пожалуйста, перепиши. Нужно, чтобы понятно было, кто там, на ком авторизуется (или может всё таки аутентифицируется?) и в каком порядке, и при чем тут "проверка верификации SID". А то это единственное, что я не понимаю в твоем буквенном тексте, и хотелось бы получить членораздельные пояснительные объяснения касательно Broadcast SID и вновь появившейся "проверки верификации SID".

Ответить | Правка | Наверх | Cообщить модератору

231. Скрыто модератором  +/–
Сообщение от EULA (?), 06-Мрт-24, 06:01 
Ответить | Правка | Наверх | Cообщить модератору

229. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от Аноним (228), 05-Мрт-24, 22:18 
> Файловой системе, ядру и окружению глубоко пофиг есть ли объект пользователь для которого задан ID.

Разработчикам же специально выдали S-1-4-... для неуникальных идентификаторов в ACL, мало кто этим пользуется, потому что в венде это не надо.

Ответить | Правка | К родителю #224 | Наверх | Cообщить модератору

232. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от EULA (?), 06-Мрт-24, 07:53 
Вопрос не про неуникальные, а про неизвестные для ОС.
Ответить | Правка | Наверх | Cообщить модератору

235. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от Аноним (235), 07-Мрт-24, 03:48 
Твой предыдущий пост скушал бот-модератор поэтому отвечу тебе тут:

Вот тебе RFC4120: https://www.ietf.org/rfc/rfc4120.txt
Ткни меня носом, где там UID-ы пользователей о говоришь. Kerberos Principal - бывает разный и типы у него бывают разные. Кстати, MS поддерживает только нотацию user@domain о чем написано даже на заборе^W в документации IBM: https://www.ibm.com/docs/en/db2/11.5?topic=authentication-na...
Покажи, в каком пакете у тебя KDC принимает UID особенно интересен пример с Windows.

SID формируются по стандарту, который описан и не менялся: https://learn.microsoft.com/en-us/openspecs/windows_protocol...
SID всегда включает в себя идентификатор Authority к котором относится субъект. Из-за этого v.pupkin@contoso.com и v.pupkin@fabrikam.com будут иметь разные SID, даже если у них случайно совпадёт RID. Это архитектурный дизайн такой. Оно специально делает так, чтобы не было случайных пересечений и не даёт тебе повесить никакие дополнительные права на SID, чей NT Account не известен. Что в этом такого страшного? Если тебе нужно выдать права внешнему пользователю, то тебе придется построить какие-то отшения доверия с его Authority.
В каком конретно "журнале ФС" у тебя появляются хвосты? Который в System Volume Information лежит или у тебя какой-то filter driver NTFS вякнул в журнал событий? Скинь пример того, о чем пишешь.

Если ты грохнул корень леса, а вместе с ним глобальный каталог домена, то не удивительно что у тебя не получается сопоставить SID с объектом каталога. Ничего удивительного.

> Маппинг нужен лишь для того, чтобы связать домены/системы работающие rfc2307 с теми доменами/клиентами, которые не смогли это осилить.

Нет, маппинг нужен всегда, где есть PAM, потому что операционная система, работающая с реализациями UNIX/Linux PAM понимает только локальную нумерацию и не принимает нумерацию из другого Authority без маппинга. И это как раз и есть главная проблема PAM. В нем всё исключительно локальной и сессии, и пользователи, вообще абсолютно всё. Winlogon при этом четко видит эту разницу и принимает SID из других доменов AD как есть, не пересчитывая число SID в локального пользователя. Нет ничего удивительного в том, что Windows потеряла возможность определять, где чей SID, если домен из которого она на себя применяла стал не доступен. "Windows AUTH", если ты имеешь в виду "Windows Authentication" или Negotiate тут вообще не при чем. Мне кажется ты не до конца понимаешь, о чем ты говоришь.

>В Windows пользователь вначале авторизовывается по NTLMv2, то есть обратившись к службе Logon в Windows, а потом уже с авторизационными данными получает билет Kerberos.
>Именно поэтому нельзя ввести Windows в домен FreeIPA.

Ну да, ты не понимаешь. Это просуществовало вплоть до 2003/XP. Оно осталось в староформатной аутентификации для RDS. Её иногда включают для старых тонких клиентов, но это не рекомендовано. При этом полный и окончательный переход на Kerberos, начавшийся в Vista/2008 закончился в 8.1/2012R2. Странно вообще такое читать. Ты мне рассказываешь про то, как NTLMv2 требуется для входа, а в мире Windows все последние годы с непривычки ныли, что начиная с 8 их принуждают пользоваться Kerberos везде и отжали не только NTLM, но и CredSSP.
Winlogon использует CredentialProviders: https://learn.microsoft.com/en-us/windows/win32/secauthn/win...
FreeIPA могла бы радостно написать свой очередной sssd для Windows, добавить его как службу и добавить провайдера. Вот только это никому не надо. NTLM тут вообще не при чем. Windows не может войти во FreeIPA, потому что там не та схема и не так входится в домен.

Кроме того, Windows не просто сразу идёт и получает TGT. Он кладёт его в кэш в LSA и автоматически запрашивает TGS при общении пользователя к известному сервису. Вообще сам процесс аутентификации пользователя - происходит сквозь учётную запись пользователя-компьютера. Она делегирует учетные данные, и на ней висит SPN. Раньше так делал NTLM, пока это не запретили.

Вот примеры маппинга для Windows:
- Маппинг NT Account и его SID в POSIX user и UID/GID для работы, например, с NFS.
- Маппинг NT Account в другой NT Account. Используется, например, при работе с WS-Management, когда внешнему (пусть даже доменному) пользователю ставится в соответствие локальная учетная запись, от лица которой он ходит на ФС и в другие части ОС. Это пример олицетворения (impersonation), и оно производится через сертификаты X.509.
В остальных случаях нужно использовать какие-то отношения доверия между Authority (Oauth2, SAML2, Kerberos).

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

> Расскажи это MS, когда они требуют для построения доверия леса включить NTLMv1, так как NTLMv2 не поддерживает передачу SID нижнего по дереву в лесу домена.

Невозможность передачи SID между доменами без включения старых NTLM говорит о том, что у тебя либо слишком старый домен был, либо сломана аутентификация на Netlogon RPC, либо файрвол блочит рендж портов RPC. Случались такие проблемы на рубеже 2008R2/2012.

P.S. Мой тебе совет: если люди тебя не понимают, постарайся выражаться яснее. Я, вот, совершенно не понимаю, за что ты топишь. То тебе не нравится, что у учетной записи LocalSystem виртуальные SID могут быть ограничены в правах, то потом ругаешься, на NTLM и как там всё не безопасно. Так нужно ограничивать в правах или нет, определись уже.
S-1-5-18 NT AUTHORITY\SYSTEM - виртуальный пользователь для служебных нужд и нужд планировщика задач
S-1-5-32-544 BUILTIN\Administrators - это группа в которую входит LocalSystem
В Linux же тоже отжимают права у root постепенно методично и уже очень давно.
А пользовательский рендж 1-99 скорее соответствует S-1-5-32-... (BUILTIN). И всяким другим principals.

Ответить | Правка | Наверх | Cообщить модератору

236. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от EULA (?), 07-Мрт-24, 06:12 
>  Кстати, MS поддерживает только нотацию user@domain

Нотация определяет UID пользователя для его идентификации.

> SID формируются по стандарту, который описан и не менялся:

По твоей ссылке же написано для разных ОС применяются разные хэш генераторы.

> Нет, маппинг нужен всегда, где есть PAM, потому что операционная система, работающая с реализациями UNIX/Linux PAM понимает только локальную нумерацию и не принимает нумерацию из другого Authority без маппинга.

Еще раз. Маппинг есть и в Windows. В том числе в Kerberos. Где нотация маппится в UID, потому,что RFC на Krb появилось задолго до Windows. В том числе в лесу. Том числе в доверии. Только там SID мапится в SID.

> Winlogon при этом четко видит эту разницу и принимает SID из других доменов AD как есть,

Да ни фига. Маппинг SID-а происходит на КД. Примером этого является старый баг, когда после перетаскивания пользователя из одного домена в другой в лесу, пользователь теряет права на файлы за пределами каталога с профилем и SMB-шар.

> Оно осталось в староформатной аутентификации для RDS.

Это когда NTLMv2 стала устаревшим? "Сетевая безопасность: уровень проверки подлинности LAN Manager" есть возможность только запретить все до NTLMv2, но сам NTLMv2 не запрещается.

> автоматически запрашивает TGS при общении пользователя к известному сервису

При известному WINDOWS сервису через известное WINDOWS приложение. В список таких приложений внезапно не входит Edge, а список сервисов не входит NFS, WebDAV, Zabbix...

> Невозможность передачи SID между доменами без включения старых NTLM говорит о том, что у тебя либо слишком старый домен был, либо сломана аутентификация на Netlogon RPC

Ну да. Уровень леса 2016 и уровень домена 2016 очень старые. 8 лет им уже. Только новее нет.
Для NTLM и NTLMv2 используются одни и те же порты. Разница в том, что SID из DEC можно расшифровать, а из HMAC-MD5 нет.

> S-1-5-18 NT AUTHORITY\SYSTEM
> S-1-5-32-544 BUILTIN\Administrators

Эти сиды не будут валидными для ЛЮБОГО SID. А когда ты приходишь с сидом вида S-1-5-21-FFFFFFFFFF-0000000000-0000000000-FFFF (еще раз это не пример такого SID-а, а просто его вид, чтобы было понятно про что говорю) и он оказывается валидным для  S-1-5-21-1507001333-1204550764-1011284298-1003 и S-1-5-21-1507001333-1204550764-1012184276-9567, вот тогда и будет веселье.

Ответить | Правка | К родителю #235 | Наверх | Cообщить модератору

233. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от commiethebeastie (ok), 06-Мрт-24, 18:38 
>DPDK
>Потому что ядро Linux и его адепты прибывают в состоянии вечного отрицания.
>DPDK is a set of libraries and drivers for fast packet processing.

It supports many processor architectures and both FreeBSD and Linux.

А шо случилось, что тут FreeBSD тогда забыла?

А почему же через божественный некривой сетевой стек FreeBSD или Windows не реализовали виртуальную память GPU через RDMA? Подозреваю ты же не встречал такое даже.

Вот у Линукса убогий стек, а системы с распределенной виртуальной памятью захвачены Линуксом на 100%. Даже в Microsoft. Странно да?

>для работы с сетью тебе нужно взять драйверы сетевки разной степени проприетарности

firmware никакого отношения к драйверам не имеет. У мелланоксов например из проприентарных компонентов только они.

Визг User был по поводу ACL в файловой системе. Первый же пост был именно про файловую систему, а не поддержку внутри ядра ОС. ВСЁ.

ACL в кривых руках, использующих в 2024 году шары - зло. ВСЁ.

Я ему писал, что методы работы с ФС, как с конечным ресурсом убоги. ВСЁ.

Ты же сам в итоге и написал про ESE.

Keystone, OpenStack и Swift вам привет передают из 2024 года.

Ответить | Правка | К родителю #215 | Наверх | Cообщить модератору

132. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от Аноним (132), 29-Фев-24, 23:45 
Мантра? Про взаимосвязь системы мандатного доступа и системы контроля целостности пояснить сможите? А как насчет опасений, связанных с использованием сертификата?
Ответить | Правка | Наверх | Cообщить модератору

87. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от glad_valakas (-), 29-Фев-24, 18:07 
предлагаю вам настроить для группы Users политику W^X для файлов. хотя бы внутри юзерских профилей. хотя бы внутри уже существующих профилей. при этом она должна применяться для всех вновь создаваемых файлов (иначе нет смысла). желаю удачи и попутного ветра в куда-нибудь.
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

137. "Microsoft предложил систему управления доступом IPE для ядра..."  +1 +/–
Сообщение от Аноним (137), 01-Мрт-24, 00:24 
>в линуксе у тебя только настройки для одного пользователя, одной грппы и для всех остальных

Товарисч, тебя когда в криокамеру-то поместили? Ты застрял во временах классических прав UNIX. В Linux давно есть ACL, расширенные атрибуты.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

138. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от Аноним (137), 01-Мрт-24, 00:37 
>В винде можно создать, например несколько групп пользователей, и для кажой из групп настроить права доступа

В Linux можно создать 2^32 групп и для каждой группы свои права.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

161. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от User (??), 01-Мрт-24, 09:43 
>>В винде можно создать, например несколько групп пользователей, и для кажой из групп настроить права доступа
> В Linux можно создать 2^32 групп и для каждой группы свои права.

А еще из буханки хлеба - троллейбус сделать можно. Да.

Ответить | Правка | Наверх | Cообщить модератору

183. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от aname (?), 01-Мрт-24, 21:31 
Т.е. Линукс
Ответить | Правка | Наверх | Cообщить модератору

30. "Microsoft предложил систему управления доступом IPE для ядра..."  +1 +/–
Сообщение от User (??), 29-Фев-24, 15:01 
Вопрос: "Считать ли что nfsv4acl "есть в linux'е" или не считать?"
С одной стороны - они почти что и не накосячили, передирая ntfs'ную модель доступа (Ну, подумаешь - нет ордеринга ACE и легким движением руки можно создать "вотпрямсовсем" неработоспособную конфигурацию... которую винда при монтировании шары через SMB любезно предлагает привести в удобоваримый вид - и что характерно, приводит!) - с другой, в тех ФС, где оно есть - реализовано вот это прям линупц-стайл вида "шел костыль через костыль" так, что немножко даже и стыдно.
В общем "на порядки" - не "на порядки", но хуже преизрядно, да.
Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

104. "Microsoft предложил систему управления доступом IPE для ядра..."  +1 +/–
Сообщение от ананим.orig (?), 29-Фев-24, 19:51 
вы ведь в курсе, что nfs вообще и nfsv4 в частности - не ноухау линуха?

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

Ответить | Правка | Наверх | Cообщить модератору

111. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от User (??), 29-Фев-24, 21:00 
> вы ведь в курсе, что nfs вообще и nfsv4 в частности - не ноухау линуха?

Оттож. Линуксовая реализация как раз таки изрядно кривая
> лично для меня отлично работает на проксмоксе с АД на самбе и вантузными (и макос, и линукс) клиентами. уже лет десять как

Ну, разве что "отлично от того, как должно". Пардону прошу, но я ЭТО кушал - и это нифига не устрицы. Нет, если слаще морковки ничего не ел - то может и норм, во всех остальных случаях - "жалкое подобие левой руки".
Юзерспейсная реализация acl в samba'е с соответствующим перформансом, есть не во всех ФС, попытка смонтировать одну и ту же шару через smb и nfs - сюрприиз! Реализации acl могут вести себя по разному. Права файла - могут зависеть от версии протокола cifs, тот что новее при копировании делает server side copy - и результат прав может отличаться от "честного" копирования samba'ой. Отсутствие сколько-нибудь вменяемого тулинга по рулежом вот этим вот, отсутствие вменяемых квот, lvm snapshot'ы вместо vss, резервное копирование, которое не умеет работать с этими extattrs (Эт прям ДАВНО было - но осадочек-с остался), какие-то мульки с блокировкой наследования - всего и не упомнишь.
Единственный плюс - оно делает вид, что как-то работает. Доверять этому "какту" сколько-нибудь ценную "нечту" - я бы лично не стал, но неленивые-и-непуганные могут попробовать самостоятельно.

Ответить | Правка | Наверх | Cообщить модератору

125. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от ананим.orig (?), 29-Фев-24, 22:37 
кушать вы можете что угодно

у меня же и nfs и самба на одних шарах с win/linux/mac-клиентов входящими в домен отлично работают уже лет 7-10.
были интересные моменты при переходе nfsv3, nfsv4 (на 4.0 и 4.1), но давно и деталей уже не помню.
помню что связано именно со стандартом и решалось параметрами монтирования как nfs, так и локальных фс

Ответить | Правка | Наверх | Cообщить модератору

158. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от User (??), 01-Мрт-24, 09:37 
> кушать вы можете что угодно
> у меня же и nfs и самба на одних шарах с win/linux/mac-клиентов
> входящими в домен отлично работают уже лет 7-10.
> были интересные моменты при переходе nfsv3, nfsv4 (на 4.0 и 4.1), но
> давно и деталей уже не помню.
> помню что связано именно со стандартом и решалось параметрами монтирования как nfs,
> так и локальных фс

Ну вот про "отлично работают" - рассказывайте пожалуйста тем, кто эту связку на самбавики видел, но до конца не дочитал. Вот если бы вы написали, что работает конечно криво-косо, но с регулярным прикладыванием рук-и-головы можно решить _мои_ задачи - я б даже поверил, а "отлично работает" (в общепринятом, а не линуксоЙдном понимании) - эт однозначно не сюда.

Ответить | Правка | Наверх | Cообщить модератору

102. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от ананим.orig (?), 29-Фев-24, 19:42 
сто лет в обед уже как и один в один как в винде
называется NFS4_ACL
ну матчасть то знать надо https://wiki.linux-nfs.org/wiki/index.php/ACLs#NFSv4_and_Win...

$ aptitude show  nfs4-acl-tools
…
Описание: Commandline and GUI ACL utilities for the NFSv4 client
This package contains commandline ACL utilities for the Linux NFSv4 client.

интегрируется с самбой
[NFS4 ACL overview](https://wiki.samba.org/index.php/NFS4_ACL_overview)

> They can be viewed and managed through the nfs4-acl-tools package, which is part of most Linux distributions. The NFS4 ACLs are revealed here though the system.nfs4_acl xattr.

[Setting up a Share Using Windows ACLs](https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Wi...)
> n a Samba Active Directory (AD) domain controller (DC), extended ACL support is automatically enabled globally. You must not enable the support manually.

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

126. "Microsoft предложил систему управления доступом IPE для ядра..."  +2 +/–
Сообщение от yet another anonymous (?), 29-Фев-24, 22:39 
Заканчивайте уже таскать эти сказки про несравненную NTFS. Там, например, метаинформация FS --- это обычный файл на той же FS, разве что его пользователю не показывают. Что ведёт к эпичной камасутре при определённых операциях над FS.
Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

159. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от User (??), 01-Мрт-24, 09:38 
> Заканчивайте уже таскать эти сказки про несравненную NTFS. Там, например, метаинформация
> FS --- это обычный файл на той же FS, разве что
> его пользователю не показывают. Что ведёт к эпичной камасутре при определённых
> операциях над FS.

Ну, она работает и решает пользовательские задачи, связанные с управлением доступом\совместным владением в многопользовательской среде - чего, в общем, не скажешь про зоопарк ФС linux'а.

Ответить | Правка | Наверх | Cообщить модератору

145. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от Аноним (-), 01-Мрт-24, 02:46 
>  NTFS/ntoskrnl ACL на порядок (!) круче, чем то, что есть в Linux.

Ну так покажи как им вообще вооон то сделать?!

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

153. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от Аноним (-), 01-Мрт-24, 05:20 
> NTFS/ntoskrnl ACL на порядок (!) круче, чем то, что есть в Linux.

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

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

160. "Microsoft предложил систему управления доступом IPE для ядра..."  +1 +/–
Сообщение от User (??), 01-Мрт-24, 09:42 
>> NTFS/ntoskrnl ACL на порядок (!) круче, чем то, что есть в Linux.
> Так то забавная штука если хочется обломать легитимного админа, зарубив ему доступ
> нафиг, да так что он нифига его не снимет так сходу.
> Еще очень удобно себе оставлять левые доступы на что попало -
> все равно в этих наворотах никто никогжа ничего не найдет, там
> черт ногу сломит.

Да-да, разумеется, если постараться выстрелить себе в ногу аналогичным образом, настроив те же самые ACL в linux'е - результат будет совсем-совсем другим, правда? А то, что доступ у лапчатых можно отхреначить - вот просто задав acl не в том порядке - патамучта в ордеринг ACE они нишмагли - так это фича такая, наверное.

Ответить | Правка | Наверх | Cообщить модератору

195. "Microsoft предложил систему управления доступом IPE для ядра..."  +/–
Сообщение от Аноним (-), 02-Мрт-24, 11:06 
> Да-да, разумеется, если постараться выстрелить себе в ногу аналогичным образом, настроив
> те же самые ACL в linux'е - результат будет совсем-совсем другим,

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

> правда? А то, что доступ у лапчатых можно отхреначить - вот
> просто задав acl не в том порядке - патамучта в ордеринг
> ACE они нишмагли - так это фича такая, наверное.

Если в линухе это нарулено - оно уже аномалия и вызывает вопросы :). А в винде оно везде и поэтому плюс-минус пара записей в ACL нисколько не палится - а вот ты попробуй вообще прочухай кто там тебе и где DENY влепил хоть ты там трижды одмин - и тем более попробуй DENY от SYSTEM вообще так сразу и без матюков снять. Наиболее прошареные конечно и это могут. Но...

...понимаешь ли, умеючи в энтерпрайзного админа и R&D я вон ту теорию еще и проверял на коллегах. Посмотреть а как оно.

Ответить | Правка | Наверх | Cообщить модератору

200. "Microsoft предложил систему управления доступом IPE для ядра..."  –1 +/–
Сообщение от User (??), 02-Мрт-24, 20:41 
>> Да-да, разумеется, если постараться выстрелить себе в ногу аналогичным образом, настроив
>> те же самые ACL в linux'е - результат будет совсем-совсем другим,
> Внезапно - да. Во первых, на рута это все не действует и
> обломать рута в линухе - ну это вам не винды, где
> первая скрипка это система (SYSTEM) а администраторы - вообще у нее
> в гостях, и будут делать то что им система скажет и
> позволит. Сие отличие наглядно кажет отношение к юзерям.

Воу. Считать эту ДЫРЕНЬ такой фичей - прям так замечательно что просто замечательно. Очень наглядно показывает отношение к безопасности.

> Если в линухе это нарулено - оно уже аномалия и вызывает вопросы
> :). А в винде оно везде и поэтому плюс-минус пара записей
> в ACL нисколько не палится - а вот ты попробуй вообще
> прочухай кто там тебе и где DENY влепил хоть ты там
> трижды одмин - и тем более попробуй DENY от SYSTEM вообще
> так сразу и без матюков снять. Наиболее прошареные конечно и это
> могут. Но...

Ну да. Если вдруг в общей помойке образовались хоть какие-то ограничения - это прям ПОДОЗРИТЕЛЬНО - не иначе как Васья-зе-грейт со своей винды ломанул и все поисправлял...

> ...понимаешь ли, умеючи в энтерпрайзного админа и R&D я вон ту теорию
> еще и проверял на коллегах. Посмотреть а как оно.

Угу. И еще небось кнопку пуск у баб Зины убирал, для пущей ЭНТЕРПРАЙЗНОСТИ

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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