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

"Microsoft предложил систему управления доступом IPE для ядра Linux"	+/–
Сообщение от opennews (??), 29-Фев-24, 14:02
Компания выставила на обсуждение в списке рассылки разработчиков ядра Linux код  LSM-модуля с реализацией механизма IPE (Integrity Policy Enforcemen), расширяющего существующие системы мандатного управления доступом. Вместо привязки к меткам и путям в IPE  решение о разрешении или запрете операции принимается на основе  постоянных свойств системного компонента с  которым выполняется операция. Модуль позволяет определить общую политику обеспечения целостности для всей системы, указывающую какие операции допустимы и каким способом следует верифицировать подлинность компонентов... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60695
Ответить | Правка | Cообщить модератору

Сообщения

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

2. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
Сообщение от Аноним (2), 29-Фев-24, 14:06
Это в обмен на sudo?) а по факту: это альтернатива SELinux и AppArmor?
Ответить | Правка | Наверх | Cообщить модератору

	4. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (4), 29-Фев-24, 14:13
	MS ещё chmod и chown не осилило, не говоря о расширенных аттрибутах. А необходимость перезапускать хосты потому что NAS ребутнулся, когда самбе было просто пофиг - это вообще песня
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Минона (ok), 29-Фев-24, 14:22
	> необходимость перезапускать хосты потому что NAS ребутнулся Хост на винде? Зачем?
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Microsoft предложил систему управления доступом IPE для ядра..."	–3 +/–
	Сообщение от Аноним (-), 29-Фев-24, 14:26
	Мне кажется или ты сам себе сделал проблемы, потом героически их решал, но получилось все равно криво? -_-ʼ Возможно что-то не так с твоими настройками.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	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
	Ты точно дурак, раз уперся в цифры, а не в смысл. При чем тут нумерология, когда тебе говорят, что системные процессы в Windows не запускаются с правами администратора, для которого не существует ограничений. В Windows я могу запретить SYSTEM доступ к *.dat в профиле пользователя, и никакие групповые политики для пользователя применяться не будут, так как у системных процессов не будет доступа туда. В Unix можно запретить только самому пользователю доступ для профиля, но не системе. Для совсем тупых повторяю, аналог SID S-1-5-18 - ID 1-99. >  У меня просто нет слов от твоего вероломного лицемерия. Если ты не понимаешь, разницу между работающим цифровым идентификатором пользователя и разницу между неработающим идентификатором пользователя, то это только твоя проблема. Для тупых повторю. На несуществующий в системе SID нельзя повесить ACL, чтобы они были доступны для внешнего пользователя. На несуществующий UID можно. Файл с несуществующим UID можно изменять, а файл с несуществующим SID-ом нельзя, чтобы в журнале ФС не появились хвосты, которые не позволят ее восстановить в случае сбоя. > Unix PAM не понимает разницу локального входа в систему от сетевого. Windows AUTH точно не понимает разницу между локальным входом и сетевым. Для нее существуют SID, которые Ю  Алгоритм расчёта прав доступа работает так как я написал. > Этот вонючий маппинг не является самоцелью. Зачем тогда винда делает вонючий маппинг каждый раз, когда по Kerberos ключи получает? Ты хоть в курсе, что в Kerberos передается UID, а не вонючий SID? Зачем винда в лесу каждый раз мапит SID домена пользователя на SID корневого домена? Если грохнешь корневой домен в лесу, то ты не найдешь свои файлы на соседнем домене по SID из своего домена, даже если ты его знаешь. Маппинг придумали как раз в MS, так как в разных уровнях леса и разных уровнях домена SID-ы формируются по разному. Сейчас их ШЕСТЬ вариантов: NT4, NT2000, Server 2003, Server 2008R2 Server 2012R2, Server 2016. > Это сделано специально, чтобы не нужно было делать маппинг по цифрам. Серьезно? А что же тогда SID-ы перестают работать, если винда теряет связь с доменом или перестает работать доверие доменов?  Что же винда теряет SID-ы, если текущий домен был исключен из леса? SID и есть маппинг по цифрам. И если у тебя домен на базе OpenLDAP+MIT, Nowell eDirectory Kerberos, то винда делает маппинг с UID - на SID каждый раз по новому на каждой машине. И твой SID на машине А в таком домене будет отличным от SID-а на машине B. Маппинг нужен лишь для того, чтобы связать домены/системы работающие rfc2307 с теми доменами/клиентами, которые не смогли это осилить. >  Алгоритм расчёта прав доступа работает так как я написал. У тебя по ссылке неписано, что в одном уровне не должно быть противоположных правил. >  а с ним уже даже соединиться нельзя на современных версиях Windows (криптографические шифры в блеклисте), равно как и LanManager, и SMB1 Расскажи это MS, когда они требуют для построения доверия леса включить NTLMv1, так как NTLMv2 не поддерживает передачу SID нижнего по дереву в лесу домена. > Давай ты скинешь ссылку хотя бы на внешнюю статью https://googlegiksearch.github.io/?q=ntlm+%D0%B0&#... >  пожалуйста, перепиши. Во всех системах MacOS, Linux, *BSD, iOS вначале пользователь получает билет kerberos, потом с этим билетом обращается к logon-службе за авторизацией на машине. В Windows пользователь вначале авторизовывается по NTLMv2, то есть обратившись к службе Logon в Windows, а потом уже с авторизационными данными получает билет Kerberos. Именно поэтому нельзя ввести Windows в домен FreeIPA.
	Ответить | Правка | Наверх | 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ообщить модератору

	60. "Microsoft предложил систему управления доступом IPE для ядра..."	–1 +/–
	Сообщение от OpenEcho (?), 29-Фев-24, 16:54
	> MS ещё chmod и chown не осилило, Спецы опен нет а :( ```    mkdir supertest && cd supertest    cp /usr/bin/sh . &&  chmod 600 ./sh    /lib64/ld-linux-x86-64.so.2 ./sh -c 'echo "Привет а нон им!"' ``` Помог чмод ?
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	124. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от ананим.orig (?), 29-Фев-24, 22:23
	ух ты, ld-linux-x86-64.so.2 может запускать программы! а шел может запускать скрипты! круто! cd .. && chmod -x supertest/ /lib64/ld-linux-x86-64.so.2 ./supertest/sh -c 'echo "Привет OpenEcho"' ./supertest/sh: error while loading shared libraries: ./supertest/sh: cannot open shared object file: Permission denied
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от OpenEcho (?), 01-Мрт-24, 14:39
	> ух ты, ld-linux-x86-64.so.2 может запускать программы! аха, даже те, у которых нет executable bit > cd .. && chmod -x supertest/ и так будешь охотится с -х за каждым юзверским экаунтом? И перекрывать им кислород в их же каталоги?
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (184), 01-Мрт-24, 21:45
	> и так будешь охотится с -х за каждым юзверским экаунтом? > И перекрывать им кислород в их же каталоги? Для этого существуют user namespaces (mount namespace) и MAC (AppArmor, SELinux, Smack, etc).
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от OpenEcho (?), 02-Мрт-24, 00:49
	>> и так будешь охотится с -х за каждым юзверским экаунтом? >> И перекрывать им кислород в их же каталоги? > Для этого существуют user namespaces (mount namespace) и MAC (AppArmor, SELinux, Smack, > etc). Вы это не мне, а тому анониму которому чмод-а достаточно обьясните
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от ананим.orig (?), 02-Мрт-24, 22:09
	для начала для этого есть umask но обсуждать пример гражданина выше, в котором пользователю разрешен и доступ к файлу, и запуск программ - шизофрения
	Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

	204. "Microsoft предложил систему управления доступом IPE для ядра..."	–1 +/–
	Сообщение от ананим.orig (?), 03-Мрт-24, 02:44
	>> ух ты, ld-linux-x86-64.so.2 может запускать программы! > аха, даже те, у которых нет executable bit именно. и в этом то весь смысл а баш может запускать скрипты, и перл, и питон, и … кто угодно и тоже без executable bit вам нужно пересмотреть свое понимание на «access permissions»
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	225. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от OpenEcho (?), 05-Мрт-24, 15:10
	> вам нужно пересмотреть свое понимание на «access permissions» Да, ну ?! Сильная заява! А как же мелкософт "который не одолел" chmod? Им тоже совет "опытного анонима" нужен, ну чтоб от запуска защищать c chmod
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от PnD (??), 01-Мрт-24, 16:21
	Следите за руками. # file /usr/bin/sh /usr/bin/sh: symbolic link to bash Фокусник, блин. "А вы за что сидите? Да, за фокусы…"© анекдот.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	178. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от OpenEcho (?), 01-Мрт-24, 17:37
	> Следите за руками. > # file /usr/bin/sh > /usr/bin/sh: symbolic link to bash У кого как, у тех кто понимает опастность баша, то у них симлинк на dash Ну скопируй бинарник, /usr/bin/dash && chmod 644 А в чем фокус то?
	Ответить | Правка | Наверх | Cообщить модератору

	226. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от PnD (??), 05-Мрт-24, 15:14
	> Ну скопируй бинарник, /usr/bin/dash && chmod 644 > А в чем фокус то?   Да, тут погорячился (показалось что копировали ссылку, но на самом-то деле — цель ссылки). Исполнителю, да, пофиг на атрибуты. Запуск "в лоб" обломается только на ФС с noexec. Но если уж задаться такой целью, можно наверное придумать и "по лбу.
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (184), 01-Мрт-24, 21:59
	> Помог чмод ? Он прежде всего для read/write. Для exec/mmap нужны более комплексные средства. В любой пользовательской ОС.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	190. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от OpenEcho (?), 02-Мрт-24, 00:52
	>> Помог чмод ? > Он прежде всего для read/write. Для exec/mmap нужны более комплексные средства. В > любой пользовательской ОС. Именно !
	Ответить | Правка | Наверх | Cообщить модератору

	205. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от ананим.orig (?), 03-Мрт-24, 02:50
	не совсем хинт - если вы не cможете прочитать, то не сможете это и запустить ну и записать :D
	Ответить | Правка | К родителю #185 | Наверх | Cообщить модератору

	227. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от OpenEcho (?), 05-Мрт-24, 19:08
	> не совсем > хинт - если вы не cможете прочитать, то не сможете это и > запустить > ну и записать :D Тебе заняться не чем вместо троллинга? Статья про "IPE  решение о разрешении или запрете операций" и твое предложение поучить мелкосовт пользоваться chmod вместо ... есть просто тролинг т.к. имея права на чтение, этого достаточно чтоб запустить файл на выполнение, к чему в итоге ты и пришел
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от aname (?), 01-Мрт-24, 21:28
	s/MS/ты/
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	95. "Microsoft предложил систему управления доступом IPE для ядра..."	+3 +/–
	Сообщение от Аноним (95), 29-Фев-24, 18:50
	> а по факту: это альтернатива SELinux и AppArmor? Скорее IMA/EVM от IBM.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	117. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от L29Ah (ok), 29-Фев-24, 21:22
	Нет, это новый раунд тивоизации.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	197. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (-), 02-Мрт-24, 11:10
	> Нет, это новый раунд тивоизации. Или подготовка к тому чтобы ядро NT таки бортануть - и уволить зиллион индусов, кодящих тормощную безблагодатную гамняку.
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Андрей04091977 (ok), 04-Мрт-24, 08:09
	Есть ещё PARSEC от астры
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

3. "Microsoft предложил систему управления доступом IPE для ядра..."	+7 +/–
Сообщение от Аноним (2), 29-Фев-24, 14:08
> Список хэшей может быть получен от пакетного менеджера RPM Угадаю в коопе с кем это будет проталкиваться с семи нот...
Ответить | Правка | Наверх | Cообщить модератору

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

	196. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (-), 02-Мрт-24, 11:09
	> линукс это виндовс. Не, просто майкрософт кажется шутку про MS Linux воспринял довольно серьезно. Есть скажем некий CBL Mariner (дистр Linux!!!) для ... внутреннего использования мс в основном. Оказывается и такое вот бывает. Так что если в винде 12, или что уж там, 13 лучше подойдет - кернель заменят, ну, упс, давно к этому шло.
	Ответить | Правка | Наверх | Cообщить модератору

5. "Microsoft предложил систему управления доступом IPE для ядра..."	+14 +/–
Сообщение от Аноним (5), 29-Фев-24, 14:19
А потом окажется, что всё это должно быть подписано ключом M$.
Ответить | Правка | Наверх | Cообщить модератору

	22. "Microsoft предложил систему управления доступом IPE для ядра..."	+5 +/–
	Сообщение от LinAlex (ok), 29-Фев-24, 14:45
	.... потому что другие биос не пропустит.
	Ответить | Правка | Наверх | Cообщить модератору

6. "Microsoft предложил систему управления доступом IPE для ядра..."	+3 +/–
Сообщение от Cyber100 (ok), 29-Фев-24, 14:20
ну все - это киста... следующий шаг - лицензирование ms kernel home, pro, datacenter, edu...
Ответить | Правка | Наверх | Cообщить модератору

	10. "Microsoft предложил систему управления доступом IPE для ядра..."	–5 +/–
	Сообщение от Аноним (-), 29-Фев-24, 14:25
	Странное сравнение. То что su/sudo это просто дыярвое шерето и так понятно, достаточно посмотреть сколько новостей про очередную уязвимость находится на этом сайте. То что они что-то предложили, не факт что его примут вообще, не факт что примут в том виде как оно предложено сейчас. Но то что управление доступом в линуксе сделано через одно место... Для того чтобы его исправить, нужно хотя бы признать наличие проблемы.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от Аноним (184), 01-Мрт-24, 22:03
	> достаточно посмотреть сколько новостей про очередную уязвимость находится на этом сайте Чтобы понять, что в sudo уязвимости ищут и исправляют. > просто дыярвое шерето Тот Неуловимый Джо, о котором не пишут новостей. > Но то что управление доступом в линуксе сделано через одно место... Опеннет-экспертиза подъехала.
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от Минона (ok), 29-Фев-24, 14:27
	> ms kernel home, pro, datacenter, edu... MS/Linux ...
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	17. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (17), 29-Фев-24, 14:32
	А вы друг друга предупреждали, товыарищи )
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	28. "Microsoft предложил систему управления доступом IPE для ядра..."	+3 +/–
	Сообщение от xxx000111 (?), 29-Фев-24, 14:59
	не просто лицензирование, а отдельно покупаются лицензии на 1) ядра 2) сервера 3) юзеров 4) число строк правил 5) день рождения Билла Гейтса
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	101. "Microsoft предложил систему управления доступом IPE для ядра..."	–1 +/–
	Сообщение от Аноним (5), 29-Фев-24, 19:31
	7) Code of Conduckt
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от OpenEcho (?), 29-Фев-24, 17:00
	> следующий шаг - лицензирование ms kernel home, pro, datacenter, edu... Не... это сыр, халявный(!!!),  зачем? Данные для ИИ - то к чему это все двигается, каждая херня должна быть идентифицирована и скормлена Так что следующий шаг будет "для заботы о мышах", - быстрое обновление хэш таблиц с облачков и в случае not found -> send samples для анализа
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

9. "Microsoft предложил систему управления доступом IPE для ядра..."	+4 +/–
Сообщение от Аноним (-), 29-Фев-24, 14:25
А что удивительного? Если платиновому спонсору Linux Foundation понадобилась какая-то фича для своих серваков и WSL, то им же не будут отказывать! И ведь сделают, негоже из-за мнения каких-то из "сообщества" отношения с ним портить.
Ответить | Правка | Наверх | Cообщить модератору

	15. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от Минона (ok), 29-Фев-24, 14:29
	> платиновому спонсору Linux Foundation Пора переименовать в Linux Corporation.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от Аноним (-), 29-Фев-24, 14:41
	Я не против. Все равно 80% кода пишут корпы, а васяны только пользуются плодами их трудов. Ну и плюют в колодец) Хотя Linux Foundation for money of Corporation будет совсем идеально.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от OpenEcho (?), 29-Фев-24, 17:02
	> Все равно 80% кода пишут корпы Вы уверены что остальные 20% - коммунисты, работающих за идею и за корочку хлеба???
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (77), 29-Фев-24, 17:29
	Ваши 80%, это показатель на сколько глубоко Linux вошел корпам. Не правда ли!?
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	79. "Microsoft предложил систему управления доступом IPE для ядра..."	–1 +/–
	Сообщение от Аноним (-), 29-Фев-24, 17:39
	Скорее насколько рука корпов прочно засела в Linux Foundation. Ну как у перчаточной куклы. Кукловод слегка пальцем пошевелит, а кукла презабавно паясничает и кланяется. Фишка в том, что корпы с линуксом пока им выгодно. И корпы без линукса выживут, возможно им будет плохо и дорого переходить на что-то другое, но примеры есть: винда, бздя, макось - это все системы разработанные корпорациями (плюс жменя встраеваемых) А без корпов линукс помрет, опустится на уровень хурда. Вот такие пирожки(
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (77), 29-Фев-24, 19:20
	С Вами интересно! Но на сегодня хватит. Спасибо.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Вася (??), 01-Мрт-24, 05:07
	корпы тут пока им выгодно, факт, но ведь выгодно от этого всем. выгодно корпам выгодно разрабам - их кормят корпы, может они и так бы этим занимались, но тут им еще и платят - минусы есть? выгодно юзерам - корпоративного уровня софт и прочее в доступе бесплатно. а все минусы, которые приносят корпы - ну так они всегда тут и были, но без плюсов
	Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

	165. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (-), 01-Мрт-24, 13:25
	> выгодно юзерам Так почему столько нытья? Что в новости про ХОрг "азаза! корпы навязывают вейланд", что в теме про всякие УЕФИ, про хром и хромиум (зонды, зонды везде) и тд тысячи их. Ну и тут. Вроде юзерам выгодно получать "корпоративного уровня софт и прочее в доступе бесплатно", а не Хурд-без-соли, но что-то они опять ноют и бухтят.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Вася (??), 01-Мрт-24, 13:39
	>> выгодно юзерам > Так почему столько нытья? линуксоиды, сэр > Что в новости про ХОрг "азаза! корпы навязывают вейланд", что в теме вейланд все ещё не готов, я б не против был, если б его nvidia нормально так навязывала, но что-то у нее даже свои стандарты не получается в этой области навязать, в итоге прогиб > про всякие УЕФИ, про хром и хромиум (зонды, зонды везде) и > тд тысячи их. это везде так, не только в линукс-мирке. > Ну и тут. > Вроде юзерам выгодно получать "корпоративного уровня софт и прочее в доступе бесплатно", > а не Хурд-без-соли, но что-то они опять ноют и бухтят. линуксоиды, сэр!
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (45), 29-Фев-24, 15:32
	>> платиновому спонсору Linux Foundation > Пора переименовать в Linux Corporation. Лучше сразу в Linux Submission Inc
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	72. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от anonymous (??), 29-Фев-24, 17:19
	Linux Consortium же.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	119. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от penetrator (?), 29-Фев-24, 21:50
	прям для серваков? что-то мне подсказывает, что для сурфейса это все в котором WSL
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	187. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (184), 01-Мрт-24, 22:11
	> И ведь сделают Уже сделали. Корпоративные рабы из M$. >  платиновому спонсору Linux Foundation понадобилась какая-то фича LF не принимает технических решений, в том числе о принятии/отклонении кода в конкретный проект.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

13. "Microsoft предложил систему управления доступом IPE для ядра..."	+2 +/–
Сообщение от Аноним (13), 29-Фев-24, 14:28
Ух какие шустрые. Сами придумали, сами предложили. А почему ядерный модель для их ФС написали и предложили не они?
Ответить | Правка | Наверх | Cообщить модератору

	19. "Microsoft предложил систему управления доступом IPE для ядра..."	+5 +/–
	Сообщение от SharkKey follower (?), 29-Фев-24, 14:34
	Потому что они уже сами не знают, как их ФС работает
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от oficsu (ok), 29-Фев-24, 14:54
	Пишут код только для того, чем сами пользуются. Н̶у̶ ̶н̶е̶ ̶б̶у̶д̶у̶т̶ ̶ж̶е̶ ̶о̶н̶и̶ ̶N̶T̶F̶S̶ ̶у̶ ̶с̶е̶б̶я̶ ̶и̶с̶п̶о̶л̶ь̶з̶о̶в̶а̶т̶ь
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	31. "Microsoft предложил систему управления доступом IPE для ядра..."	+2 +/–
	Сообщение от Аноним (-), 29-Фев-24, 15:01
	Если найти немамонта который тебе бесплатно напишет код, а ты его можешь просто взять и использовать.. Так это просто win ситуация! Не зря что ли всякие аппологеты опенсорса, на гранты от корпов, рассказывают "как клево писать открытый код на благо Сообщества (и вон того уважаемого господина, который отслюнавил мне котлету денег)"
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	118. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (118), 29-Фев-24, 21:42
	А нафига он им нужен в Azure?
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

18. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
Сообщение от Аноним (18), 29-Фев-24, 14:33
Поясните, в чем подвох?
Ответить | Правка | Наверх | Cообщить модератору

Часть нити удалена модератором

	44. Скрыто модератором	+1 +/–
	Сообщение от Аноним (44), 29-Фев-24, 15:30
	Тебе три с половиной миллиона раз уже сказали боятся данайцев дары приносящих. Учи матчасть что от этого бывает. Заодно про индейцев почитай и дары с оспой от европейцев.
	Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

	46. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от Аноним (46), 29-Фев-24, 15:34
	Вы просто забываете, что Linux был написан и долгое время поддерживался энтузиастами, а твои любимые корпы налезли потому как им понадобилась специфическая корпарасткая хрень, которой в ядре не было, а Linux то бесплатный - экономия. Так, что не надо ля-ля.... Прям картина перед глазами злые ЖПЛщики силой заставляют несчастных копорастов писать код для ядра.
	Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

	54. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от Аноним (-), 29-Фев-24, 15:57
	> Вы просто забываете, что Linux был написан и долгое время поддерживался энтузиастами, > а твои любимые корпы налезли потому как им понадобилась специфическая корпарасткая > хрень, которой в ядре не было, а Linux то бесплатный - экономия. Начали писать в 91. Версия 2.0 вышла в 96 году и была уже более менее пригодна. В 98 в ядро уже вкладывалис ИБМ (1,5к инжинеров) и Оракл. Если бы не эти вливания - получили бы очередной Хурд без соли. > Так, что не надо ля-ля.... Прям картина перед глазами злые ЖПЛщики силой заставляют несчастных копорастов писать код для ядра. Злые ЖПЛщики начинали с воровства емаксов) И привычки к сожалению остались. Код брался их БЗДи (иногда даже с выпиливанием файлов лицензии), заражался гпл-раком, а потом возникали проблемы с патчами в самой BSD. Но с точки зрения корпов - это отлично. Тк такие кода практически невозможно продавать, то монетизация тоже очень-очень сложная. Поэтому проект живет, пока на него дают деньги. Значит им можно управлять)
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 29-Фев-24, 16:03
	> Вы просто забываете, что Linux был написан и долгое время поддерживался энтузиастами Hurd и сейчас "поддерживался энтузиастами". А вот корпами хурд не поддерживается. Результат поддержки корпами налицо.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	103. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от Аноним (95), 29-Фев-24, 19:44
	Наезд на IMA/EVM от IBM. Точнее сабж аналог IMA, а dm-veriti,  fs-verity аналог EVM.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	173. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от n00by (ok), 01-Мрт-24, 15:19
	> Наезд на IMA/EVM от IBM. > Точнее сабж аналог IMA, а dm-veriti,  fs-verity аналог EVM. Не понятно, на кого делать ставку. Вдруг выиграет Трамп, а тут помимо Микрософт еще и Хуавэй, явно мешает делать Америку снова великой.
	Ответить | Правка | Наверх | Cообщить модератору

36. Скрыто модератором	+4 +/–
Сообщение от Аноним (-), 29-Фев-24, 15:07
От Microsoft нам ничего не нужно.
Ответить | Правка | Наверх | Cообщить модератору

41. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
Сообщение от Аноним (41), 29-Фев-24, 15:23
>  файла с хэшем "401fce...0dec146938". А кукушка не поедет всё это сопровождать?
Ответить | Правка | Наверх | Cообщить модератору

	42. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (44), 29-Фев-24, 15:29
	Возможно в будущем сделают опцию запускать только файл с этим хешем, тогда не придется блеклитить все исполняемые файлы в мире.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от Аноним (62), 29-Фев-24, 16:57
	Каноничный вендорлок, не?
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от OpenEcho (?), 29-Фев-24, 17:08
	Ну зачем вы так? Здесь много-ходовка
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Microsoft предложил систему управления доступом IPE для ядра..."	–1 +/–
	Сообщение от Аноним (73), 29-Фев-24, 17:21
	> вендорлок Значение знаешь?
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

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

	51. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (-), 29-Фев-24, 15:47
	> Вот поэтому и нужен хурд - чтобы кто попало коммитил гадость в > свой форк сервера, а не в ядро. Хурд, это вообще что? Какая-то кривая подделка 1,5 калек которую пилят лет 30? Ну... можешь им пользоваться. Но это отличнй пример, чем бы было ядро линукса без корпораций, их программеров. их денег.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от Аноним (5), 29-Фев-24, 19:26
	Ожил Хурд в последнее время. 64 бита пилят.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Microsoft предложил систему управления доступом IPE для ядра..."	–1 +/–
	Сообщение от Онанимб (?), 01-Мрт-24, 12:23
	Отлично, ещё пару десятилетий и сделают.
	Ответить | Правка | Наверх | Cообщить модератору

50. "Microsoft предложил систему управления доступом IPE для ядра..."	+4 +/–
Сообщение от Котофалк (?), 29-Фев-24, 15:40
Данайцы с дарами подъехали...
Ответить | Правка | Наверх | Cообщить модератору

	70. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от OpenEcho (?), 29-Фев-24, 17:10
	Да они уже давно не данайцы, а руководяйцы
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (5), 29-Фев-24, 19:17
	Не смогли победить, возглавили?
	Ответить | Правка | Наверх | Cообщить модератору

	210. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (210), 03-Мрт-24, 15:53
	возглавить тоже не смогли, но пытаются всё ещё
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (152), 01-Мрт-24, 05:15
	> Данайцы с дарами подъехали... Да у этих нанайцев просто линуха уже используется больше чем винды, они и чешут репу как с этим жить. Так, глядишь, выкинут NT kernel скоро...
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

52. "Microsoft предложил систему управления доступом IPE для ядра..."	+2 +/–
Сообщение от Бывалый Смузихлёб (ok), 29-Фев-24, 15:51
Ну вот хомяков и загоняют окончательно в клетку. Добавить ещё ту хреновину по проверке целостности ОЗУ и памяти конкретных процессов и потоков - и практически идеальная тюрьма, которая не снилась ни винде ни яблоку
Ответить | Правка | Наверх | Cообщить модератору

	58. "Microsoft предложил систему управления доступом IPE для ядра..."	–1 +/–
	Сообщение от Аноним (-), 29-Фев-24, 16:14
	> Ну вот хомяков и загоняют окончательно в клетку. Неправда, никто никого в клетку не загонял Хомячки сами туда зашли. С радостью и под лозунги об "открытом коде, свободе и сообществе энтузиастов". Сначала убедили, что код должен быть бесплатный, что копировать можно сколько влезет, а потом оказалось ВНЕЗАПНО, что найти немамонтов писать код нашару очень сложно. Пришлось делать прогиб под корпов и их грантики. > Добавить ещё ту хреновину по проверке целостности ОЗУ и памяти конкретных процессов и потоков - > и практически идеальная тюрьма, которая не снилась ни винде ни яблоку Думаю добавят) Не в этом году конечно, но цель видна, осталось реализовать.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Бывалый Смузихлёб (ok), 29-Фев-24, 17:39
	да даже на опеннете недавно публиковались новости по тому проекту это настолько анальная эксплуатация, что даже венда с принудительным обновлением иным покажется сказкой Ведь, даже динамических правок в систему внести не удастся ибо проверка целостности ОЗУ
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от Аноним (-), 29-Фев-24, 18:55
	Спасибо за упоминание, со второго раза нашел) www.opennet.ru/opennews/art.shtml?num=52691 Т.е это довольно новый проект, всего 4 года пилят. Но опасения у форумчан возникли еще тогда))
	Ответить | Правка | Наверх | Cообщить модератору

53. "Microsoft предложил систему управления доступом IPE для ядра..."	+2 +/–
Сообщение от Аноним (53), 29-Фев-24, 15:52
Как они  задрали пытаться "верифицировать" мою систему! Кстати, перед тем, как говорить мне что все отключаемо, попробуйте отключить selinux.
Ответить | Правка | Наверх | Cообщить модератору

	56. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от Аноним (-), 29-Фев-24, 16:05
	> Как они  задрали пытаться "верифицировать" мою систему! А вообще, кто тебе сказал, что это "твоя" система? > Кстати, перед тем, как говорить мне что все отключаемо, попробуйте отключить selinux. Ядро открытое, всегда можно накатить патчи и выпилить. Есть же могучее Сообщество™, которое пишет ядро, а корпы им только мешают. Ну так пусть форкнут, сделают LibreKernel и избавятся от гнет корпораций!
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (137), 01-Мрт-24, 00:02
	Установленную на его хосте систему GNU/Linux он точно может считать своей и делать с ней, что хочет. Ибо, в отличие от системы под EULA, никто ему на его компе не диктует, как использовать систему.
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от _ (??), 01-Мрт-24, 04:45
	Хороший анекдот, надо таки рассказать Сарочке(С) ;-D
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (-), 01-Мрт-24, 05:12
	> Хороший анекдот, надо таки рассказать Сарочке(С) ;-D Анекдот, не анекдот - а я по совету того анона 137 и действую. Если я сам отстроил кернел, модули подписаны моими ключами, и в конфиге ядра то что я посчитал нужным - как вы собираетесь мне вообще там что-то указывать? Я чисто технически свое при таком раскладе всегда отспорю. Если ончень надо - окей, я пропатчу кернел. Скажем regulatory вафли - подбешивает, поэтому у меня для него есть аморальный но полезный патч. Вам я его ессно не дам - и вас оно таки будет строить. Потому что тем кому это на самом деле надо - сами его себе и сделают. Это такой тест на разумность существа - если может, очевидно, понимает что делает. А позволить каждому хомяку произвольно гадить в эфир - не очень осмотрительная идея. В целом.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (137), 01-Мрт-24, 00:05
	LibreKernel, как бы, уже довольно давно существует. Новости о нём на OpenNet регулярно постят.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	148. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от _ (??), 01-Мрт-24, 04:46
	И кто из вас его пользует? А чесно? :)
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (175), 01-Мрт-24, 17:00
	Из замеченного мной. Видеокарта работает только в текстовых режимах. Если графика ненужна (сервер), пользовать можно.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (-), 29-Фев-24, 16:18
	> мою систему Ты всего лишь безымянный юзер, пользующийся их ядром и их системой потому что... А потому что так исторически сложилось. И всё. И выбор у тебя, учитывая что selinux ты отключить не в состоянии, только один - "жричодают". Ну и жаловаться в коммента, как же без этого.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	120. "Microsoft предложил систему управления доступом IPE для ядра..."	+2 +/–
	Сообщение от penetrator (?), 29-Фев-24, 21:52
	setenforce 0
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	150. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от Аноним (-), 01-Мрт-24, 05:08
	> Как они  задрали пытаться "верифицировать" мою систему! > Кстати, перед тем, как говорить мне что все отключаемо, попробуйте отключить selinux. Ну вот у меня в моем линухе - никакого SELinux вообще совсем нету. А в чем собственно проблема? :)
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

68. "Microsoft предложил систему управления доступом IPE для ядра..."	+5 +/–
Сообщение от Kuromi (ok), 29-Фев-24, 17:03
Даже не вчитываясь видно что это очередной голый DRM. Вот такая вот свобода.
Ответить | Правка | Наверх | Cообщить модератору

	74. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от OpenEcho (?), 29-Фев-24, 17:22
	> Даже не вчитываясь видно что это очередной голый DRM. Да нет, - это покруче будет. Задумка она конечно не плохая, но и давно и не новая (привет mtree !), хотя защищать систему, этой же самой системой - классический тупой антивирус, которые обходились, обходятся и будут обходиться тем кому надо, но вот лакомый кусок  под видом заботы о мышах, - можно будет потом привязать к клаудам (ну да,"верю", - исключительно для реал-тайма защиты) и собирать samples
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Kuromi (ok), 29-Фев-24, 17:47
	>> Даже не вчитываясь видно что это очередной голый DRM. > Да нет, - это покруче будет. > Задумка она конечно не плохая, но и давно и не новая (привет > mtree !), хотя защищать систему, этой же самой системой - классический > тупой антивирус, которые обходились, обходятся и будут обходиться тем кому надо, > но вот лакомый кусок  под видом заботы о мышах, - > можно будет потом привязать к клаудам (ну да,"верю", - исключительно для > реал-тайма защиты) и собирать samples Не, я  понимаю что применение там не одно единственное, но в консумерском сегменте сразу в голову приходит огораживание от запуска всякого "неразрешенного". Уверен, легко можно будет прикрутить это к "авторизованному" магазину приложений. В корпоративном мире все тоже мило, полный локдаун. И да, идея "разрешить запуск только разрешенных исполняемых файлов" - не новая, но тут вопрос насколько во эта реализация обходима.
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от OpenEcho (?), 01-Мрт-24, 14:49
	> Уверен, легко можно будет прикрутить это к "авторизованному" магазину приложений. Я не думаю что это грозит в ближайшем будующем, т.к. на их же уровне есть им равные и они не поведутся на такой безпредел, но если гуглы лягут под них, то все возможно >  И да, идея "разрешить запуск только разрешенных исполняемых файлов" - не новая, но тут вопрос > насколько во эта реализация обходима. Судя по тому как появляются новые вирусы, которые просачиваются через real-time cloud protection + samples submission то это подтверждает старую как мир правду: "Защищать систему самой системой - не получится", всегда были, есть и будут дыры.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (137), 01-Мрт-24, 00:09
	>Предложенный механизм может применяться в прошивках для встраиваемых устройств, в которых всё программное обеспечение и настройки специально собираются и предоставляются владельцем Тивоизатор
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

75. "Microsoft предложил систему управления доступом IPE для ядра..."	–1 +/–
Сообщение от Аноним (75), 29-Фев-24, 17:25
Пора дистростроителям переходить на какое-то другое ядро, тянуть дальше чревато. Линукса зохватили корпорасты, хурд ни жив ни мёртв... Остаётся illumos. Заодно и zfs искаропки получим.
Ответить | Правка | Наверх | Cообщить модератору

	84. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от Kuromi (ok), 29-Фев-24, 17:49
	> Пора дистростроителям переходить на какое-то другое ядро, тянуть дальше чревато. Линукса > зохватили корпорасты, хурд ни жив ни мёртв... Остаётся illumos. Заодно и > zfs искаропки получим. В теории можно воставить ядро собранное без всего вот этого. Кастомные ядра тоже не новость, были же на заре нетбуков (помните) ядра собранные специально для eeePC.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от Аноним (-), 29-Фев-24, 17:53
	А код писать кто будет? Дистростроители в большинстве своем, просто собирают из уже готовых блоков. Ну макисимум системд выпилят. Зато у нас 100500 дистров с нескучными обоями)
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	220. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Андрей04091977 (ok), 04-Мрт-24, 08:12
	Астра PARSEC написали
	Ответить | Правка | Наверх | Cообщить модератору

76. "Microsoft предложил систему управления доступом IPE для ядра..."	–3 +/–
Сообщение от Аноним (73), 29-Фев-24, 17:28
В очередной раз Майкрософт делает за день для опенсорс больше, чем все комментаторы опеннета за год вместе взятые. То, что происходит с правами доступа в Линуксе — это позор, который с нами с 70х. Даже такую простую штуку как SELinux не осилили настолько, что все гайды начинаются с «setenforce 0». Принесли на блюдечке готовое решение чтобы сделать уже наконец-то Линукс многопользовательской системой по современным меркам, но местная нердота всё равно воет про данайцев и оспяные одеяла. Не нать нам ваша безопасность. Диды от рута запускали, и мы будем.
Ответить | Правка | Наверх | Cообщить модератору

	83. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (-), 29-Фев-24, 17:48
	О, тебе еще не попадались упорыши (обычно в темах про Раст) рассказывющие, что уязвимости в ядре это хорошо ? Потому что, та-дам, так можно рутануть телефон на который уже забил производитель. Так что неудивительна такая реакция)
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (141), 01-Мрт-24, 01:18
	Попадались, куда ж без них? Скоро очередной виток будет, CloudFlare отрыла исходники своей замены Nginx на Расте, которая и быстрее, и гибче, и безопаснее.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (155), 01-Мрт-24, 09:18
	потому что selinux совсем не простой и малопригоден для практического применения
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	181. "Microsoft предложил систему управления доступом IPE для ядра..."	–1 +/–
	Сообщение от Аноним (73), 01-Мрт-24, 19:07
	SELinux простой настолько, что для тех, кто не умеет читать текст выпустили руководство в виде комикса. А его пригодность к повседневному использованию зависит только от тебя. С установкой линукса разобрался, значит и с RBAC не должно возникнуть проблем.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (210), 03-Мрт-24, 15:50
	тыкающие в интернете ни к чему не пригодны практикой доказано
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (175), 01-Мрт-24, 17:11
	Ну вот всё запускать от админа или назначить своего юзера админом, это к 90% виндохомячков.
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	180. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (73), 01-Мрт-24, 19:00
	Вторая проблема линуксоидов заключается а том, что они склонны путать прод и локалхост.
	Ответить | Правка | Наверх | Cообщить модератору

89. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
Сообщение от anonymous (??), 29-Фев-24, 18:16
О, у нас такая система на работе стоит и работает. Определяет, какие программы можно запускать, какие нет.
Ответить | Правка | Наверх | Cообщить модератору

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

	146. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от Аноним (146), 01-Мрт-24, 04:23
	Ну как... во-первых, git видит все файлы как двоичные, из-за чего пользоваться им неудобно. Во-вторых, пароль от сервера, который это контролирует, написан на бумажке, наклеенной на монитор, потому что иначе заставить это нормально работать, невозможно. В-третьих, эта система крайне нестабильно работает на виртуалках и вообще не работает в докере, потому что виртуалка воспринимается как tampering. Но в целом, это штука хорошая, потому что босс теперь имеет ощущение, что "у него всё безопасно", а значит не докапывается до того, что у каждого на компе стоит TeamViewer.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (-), 01-Мрт-24, 13:30
	С гитом звчит неудобно( > пароль от сервера, который это контролирует, написан на бумажке Думаю если у кого-то есть физический доступ в помещение с серваком, то это гораздо большая проблема, чем пародль на бумажке)) > нестабильно работает на виртуалках и вообще не работает в докере Тоже неприятно, но если нет виртуалок, то можно использовать. Главное знать о таком ограничении.
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от anonymous (??), 02-Мрт-24, 07:51
	>Тоже неприятно, но если нет виртуалок, то можно использовать. Если бы эта система администрировалась компетентным администратором, работать было бы невозможно.
	Ответить | Правка | Наверх | Cообщить модератору

	209. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (210), 03-Мрт-24, 15:52
	товарищ маеор внедрил?
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

99. "Microsoft предложил систему управления доступом IPE для ядра..."	+5 +/–
Сообщение от Анонист (?), 29-Фев-24, 19:22
> Microsoft предложил систему управления доступом IPE для ядра Linux Как это поможет исправить рваный скроллинг в линпусе? Когда уже запилят нормальный десктоп, хотя бы как в винде? (не заикаюсь про божественный как в macOS)
Ответить | Правка | Наверх | Cообщить модератору

	105. "Microsoft предложил систему управления доступом IPE для ядра..."	–1 +/–
	Сообщение от Аноним (-), 29-Фев-24, 19:53
	> Когда уже запилят нормальный десктоп, хотя бы как в винде? С этим вопросом лучше в соседнюю тему про КДЕ6. Там тебе сразу расскажут что линуксовый декстоп лучше и винды и мака вместе взятых, но не на гноме или кедах, а на каком-ир васяноДЕ для особенных. При этом все что кривое - "вы просто не поняли задумку художника", а все что не работает - оно нинужна. И да, вяленый тоже нинужон!
	Ответить | Правка | Наверх | Cообщить модератору

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

	121. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от penetrator (?), 29-Фев-24, 21:55
	KDE вполне себе лучше и мака и винды, есть конечно огрехи, но даже не замечаешь по сравнению с двумя последними
	Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

	122. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (122), 29-Фев-24, 21:58
	> KDE вполне себе лучше и мака и винды Если решил набрасывать, пиши про федору, гном и гтк.
	Ответить | Правка | Наверх | Cообщить модератору

110. "Microsoft предложил систему управления доступом IPE для ядра..."	+4 +/–
Сообщение от 12yoexpert (ok), 29-Фев-24, 20:52
> IPE нацелен на создание полностью контролируемых корпорастами систем поправил
Ответить | Правка | Наверх | Cообщить модератору

127. "Microsoft предложил систему управления доступом IPE для ядра..."	–2 +/–
Сообщение от Леонид (??), 29-Фев-24, 23:08
Это настолько круто, что даже представить сложно не админам и не ИБ спецам какая карусель с мороженым нас закружила! Теперь реально загрузится то что нужно, а не что попало. Если в вашей организации хранятся реально ценные данные, то исключение из возможности запуска с сторонних устройств хранения и/или загрузочных образов (для сетевой загрузки актуально) с белым списком на запуск с ФС это оч. круто и сужает возможности атак до минимума.
Ответить | Правка | Наверх | Cообщить модератору

	140. "Microsoft предложил систему управления доступом IPE для ядра..."	+1 +/–
	Сообщение от Аноним (140), 01-Мрт-24, 01:10
	Но только не припомню, чтоб какое-либо начинание мелкомягких хорошо кончилось одновременно качественным софтом и применением дома. Поэтому - выбросить.
	Ответить | Правка | Наверх | Cообщить модератору

	142. Скрыто модератором	+/–
	Сообщение от Аноним (141), 01-Мрт-24, 01:24
	Ну это от того, что у тебя память избирательная и больше последнего ТикТока не помнит. Майкрософт за свою историю создал множество передовых вещей, начиная да хотя бы с банальной Винды.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от anonymous (??), 01-Мрт-24, 18:07
	Lsp/dap
	Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

	154. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от n00by (ok), 01-Мрт-24, 08:23
	Да, занятная карусель. Что бы вот это вот всё имело смысл в Windows, потребовался PatchGuard. А что бы PG работал, он должен быть: закрыт, обфусцирован и обновляться оперативно.
	Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

	169. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
	Сообщение от Аноним (169), 01-Мрт-24, 14:07
	а кто мешает сделать свой загрузчик?
	Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

217. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
Сообщение от Аноним (217), 04-Мрт-24, 07:37
Хана Linux-у !  Насуёт ему майфкософт анальных зондов и развалит  :( Они так Borland убили
Ответить | Правка | Наверх | Cообщить модератору

218. "Microsoft предложил систему управления доступом IPE для ядра..."	+/–
Сообщение от Diozan (ok), 04-Мрт-24, 07:55
Ждём сертификат от ФСТЭК?
Ответить | Правка | Наверх | Cообщить модератору

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

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