Чи є бінарний файл (.exe) у папці System32, який відповідає за функціональні можливості Windows UAC? (наприклад, uac.exe). Що буде, якби цей файл був насильно видалений? Чи зламається Windows або не вдасться до завантаження?

Тут немає жодної проблеми з XY; Мені просто цікаво дізнатися, що буде, якщо UAC буде насильно знятий з ПК.

UAC - це багатокомпонентна архітектура, реалізована декількома бінарними файлами

Контроль облікових записів користувачів (UAC) відноситься до декількох компонентів, які разом утворюють архітектуру UAC . Я коротко ознайомлюсь з деякими з них разом із бінарними файлами, відповідальними за їхню реалізацію, але спочатку огляд архітектури UAC зі статті Microsoft Docs, як працює контроль облікових записів користувачів :

Місцевий орган безпеки (LSA) / Фільтрований маркер

Концептуально "перший" компонент UAC реалізується підсистемою Local Security Authority, яка обробляє створення токена доступу користувача під час процесу входу. Починаючи з Windows Vista, процес входу був змінений так, що коли адміністратор входить із увімкненим UAC, підсистема LSA генерує два окремих маркери доступу для користувача:

1. Один із повним доступом адміністратора та
2. Другий "відфільтрований маркер" зі стандартним доступом користувачів

Як показано тут, цей процес відрізняється від стандартного входу користувача:

Служба підсистеми LSA працює в lsass.exeпроцесі.

Віртуалізація

Додано в Windows 7, віртуалізація файлів і реєстрів - це компонент UAC, який захищає старі програми, не сумісні з UAC, але вимагають лише адміністративних прав для доступу до певних захищених областей файлової системи чи реєстру:

Коли адміністративна програма, яка не відповідає сумісній програмі UAC, намагається записати в захищений каталог, наприклад програмні файли, UAC надає додатку власний віртуалізований вигляд ресурсу, який він намагається змінити. Віртуалізована копія зберігається у профілі користувача.

Джерело

Перенаправлення цих спроб доступу до областей, які не потребують дозволу адміністратора, ці програми продовжують функціонувати, незважаючи на те, що UAC увімкнено.

Ця віртуалізація реалізована в ядрі .

Служба інформації про додатки

Служба інформації про додатки (AIS) читає маніфест програми та працює з підказкою згоди UAC, щоб визначити, чи дозволено виконувати програму з підвищеними правами (тобто запускати в контексті нефільтрованого маркера доступу адміністративного рівня, створеного під час входу) . Цей допис у блозі дає хороший огляд його ролі в процесі UAC:

AIS Полегшує запуск інтерактивних додатків з додатковими адміністративними привілеями. Якщо ця послуга припинена, користувачі не зможуть запускати програми з додатковими адміністративними привілеями, які вони можуть вимагати .... Оболонка перевіряє цю службу під час запуску програми. AIS - це той, хто зчитує маніфест та розділ xml 'trustInfo', який має вимоги до 'requestExecutionLevel' ...

Ось графіка, яка випливає з наведеної вище цитати, в якій детально описується роль AIS у процесі запрошення згоди на підтримку UAC:

AIS реалізований в DLL,appinfo.dll який виконується svchost.exe.

Підказка про згоду

@ Бенн відповідь пояснює ключову роль (в) відомому UAC Згоду Prompt. Це реалізовано в consent.exeі відповідає за отримання згоди користувача або облікових даних адміністратора, щоб дозволити запуск програми, що вимагає прав адміністратора.

Безпечний робочий стіл

На захищеному робочому столі за замовчуванням відображається запит на згоду UAC. UACBlog Майкрософт розповідає, що цього робочого столу унікальне порівняно з робочим столом користувача:

Ви найчастіше взаємодієте з [Безпечним робочим столом] під час входу в Windows, оскільки інтерфейс входу в систему працює на захищеному робочому столі. Основна відмінність захищеного робочого столу від User Desktop полягає в тому, що тут можуть запускатися тільки довірені процеси, що виконуються як SYSTEM (тобто ніщо не працює як рівень привілеїв користувача), і шлях до безпечного робочого столу з робочого столу користувача також слід довіряти через весь ланцюжок.

Ідея його використання при питанні згоди користувача на запуск програми з підвищеними дозволами полягає в тому, що зловмисне програмне забезпечення не може імітувати захищений робочий стіл, якщо воно вже не має адміністративних прав, і в цьому випадку обман користувача в його наданні є суперечливим.

Висновок: UAC - це не лише один двійковий. Це тканина переплетених підсистем.

Існують ще інші аспекти архітектури UAC, не висвітлені тут, але це повинно дати достатньо доказів для фактів, які:

1. UAC не реалізований в одному двійковому.
2. Якщо це включено, це невід'ємна частина виконання адміністративних завдань.

З моменту свого впровадження в Windows Vista він був глибоко інтегрований у ключові частини операційної системи, завдяки чому видалити весь код, відповідальний за UAC, не порушуючи інші речі (наприклад, вашу здатність до входу!).

Я думаю, що можна впевнено сказати, що якщо ви "насильно видалили" UAC, ви б зламали Windows.

Як чудово пояснив Twisty , є багато компонентів, які допомагають реалізувати UAC. Частина UAC, яку люди найбільше знайомі, - це діалог про піднесення / згоду:

Це передбачено consent.exe"Згодою інтерфейсу користувача для адміністративних застосувань". Я спробував перейменувати його в VM і побачив, що відбувається. Як і очікувалося, під час використання "запустити як адміністратор" не з'являться запити щодо висоти - натомість ви отримуєте помилку, що не знайдено файлів, яка звинувачує те, що ви намагаєтеся підняти:

Спроба використовувати будь-який елемент інтерфейсу панелі управління, який потребує піднесення (тобто має піктограму щита), навіть якщо увійшов як адміністратор, не вдається з подібними помилками. Спроба запустити адміністративні речі з меню "Пуск" створює дещо іншу помилку:

Залежно від набору ACL під час перейменування, яке все порушило, це неможливо виправити зсередини ОС, оскільки файлові операції можуть вимагати підвищення (навіть якщо вони зазвичай не створюють діалогове вікно згоди). Хоча видимість, що нагадує звичайним користувачам, діяльність не здається деградованою.