Классика.

Воистину чудеса творит!

$ cat rust.cpp
// let us pray to great Cargo
void rust()
{
  int x[24];
  char *y=x[-1];
}

$ g++ rust.cpp
rust.cpp: В функции «void rust()»:
rust.cpp:5:15: ошибка: invalid conversion from «int» to «char*» [-fpermissive]
    5 |   char *y=x[-1];
      |           ~~~~^
      |               |
      |               int

По-моему это плевое дело для одного, максимум нескольких full-time программистов.

Это лишь показывает абсолютную, крайнюю ненужность и нишевость этих архитектур. Ну значит и без sudo поживут))

С другой стороны, у разбрабов e2k наверняка есть настолько круты спецы, что им добавить бек в llvm как два байта. Правда ведь))

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

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

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

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

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

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

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

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

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

Знаем мы, как в Винде. Там каждый хомячок адиминистратор локалхоста.

Самые критичные части ОС должны быть безопасны, т.е. ядро и основные библиотеки, вроде openssl, libz. Это убережёт от условных 80% проблем. Т.е. ядро и эти либы должны быть написаны на Rust. Если вам хочется писать на Сях-х**ях, пожалуйста, но вам гарантируется безопасность и предсказуемость libc (хотя это уже librust, но не важно, posix интерфейс кароч). Т.е. это guardrails but not gates, безопасный интерфейс для имбецилов с топором.

Чукча не читатель.

Я сказал то, что хотел. А ты прочитал, то что удобно твоему манямирку. Мы разные.

https://vk9-sec.com/opensmtpd-6-6-1-remote-code-execution-smtp_mailaddr-cve-20

был лучшего мнения об OpenBSD

Чтобы опубликовать новость на опеннете и вызвать шквал комментариев.