Есть ли бинарный файл (.exe) в папке System32, отвечающий за функциональные возможности Windows UAC? (например, uac.exe). Что произойдет, если этот файл был принудительно удален? Будет ли Windows ломаться или не загружаться?
Здесь нет проблем с XY; Мне просто любопытно узнать, что произойдет, если UAC будет принудительно удален с ПК.
Контроль учетных записей (UAC) относится к нескольким компонентам, которые вместе образуют архитектуру UAC. Я кратко рассмотрю некоторые из них, а также двоичные файлы, отвечающие за их реализацию, но сначала приведу обзор архитектуры UAC из статьи Microsoft Docs « Как работает контроль учетных записей»:
Концептуально "первый" компонент UAC реализуется подсистемой Local Security Authority, которая обрабатывает создание токена доступа пользователя в процессе входа в систему. Начиная с Windows Vista, процесс входа в систему был изменен так, что когда администратор входит в систему с включенным UAC, подсистема LSA создает два отдельных токена доступа для пользователя:
Как показано здесь, этот процесс отличается от обычного входа пользователя в систему:
Служба подсистемы LSA находится в процессе lsass.exe .
Виртуализация файлов и реестра, добавленная в Windows 7, является компонентом UAC, который скрывает старые приложения, которые не совместимы с UAC, но требуют только административных прав для доступа к определенным защищенным областям файловой системы или реестра:
Когда административное приложение, которое не совместимо с UAC, пытается выполнить запись в защищенный каталог, такой как Program Files, UAC предоставляет приложению собственное виртуализированное представление ресурса, которое оно пытается изменить. Виртуализированная копия сохраняется в профиле пользователя.
Путем перенаправления этих попыток доступа в области, для которых не требуются права администратора, эти приложения продолжают функционировать, несмотря на то, что UAC включен в системе.
Эта виртуализация реализована в ядре.
Информационная служба приложения (AIS) считывает манифест приложения и работает с запросом согласия UAC, чтобы определить, может ли приложение выполняться с повышенными правами (т. Е. Запускаться в контексте нефильтрованного токена доступа административного уровня, созданного при входе в систему) , Этот пост в блоге дает хороший обзор его роли в процессе UAC:
AIS Облегчает запуск интерактивных приложений с дополнительными административными привилегиями. Если эта служба остановлена, пользователи не смогут запускать приложения с дополнительными административными привилегиями, которые могут им потребоваться ....Оболочка проверяет этот сервис при запуске приложения. AIS - это тот, который читает манифест и раздел «trustInfo» xml, в котором есть требования для «требуемогоExecutionLevel» ...
Вот рисунок, который следует за приведенной выше цитатой с подробным описанием роли AIS в процессе запроса согласия UAC:
AIS реализована в DLL appinfo.dll которая выполняется svchost.exe .
@ Бенн ответ объясняет ключевую роль (в) известного UAC согласия Prompt. Это реализуется в consent.exe и несет ответственность за получение согласия пользователя или учетных данных пользователя с правами администратора, для того , чтобы обеспечить запуск приложения , требующее права администратора.
На защищенном рабочем столе по умолчанию отображается запрос согласия UAC. UACBlog от Microsoft говорит нам, что уникально в этом рабочем столе по сравнению с рабочим столом пользователя:
Вы чаще всего взаимодействуете с [защищенным рабочим столом] при входе в Windows, поскольку пользовательский интерфейс входа в систему работает на защищенном рабочем столе. Основное отличие Secure Desktop от User Desktop состоит в том, что здесь разрешено запускать только доверенные процессы, работающие в качестве SYSTEM (то есть, ничего, что не работает в качестве уровня привилегий пользователя), и что путь к Secure Desktop с рабочего стола пользователя также должен быть доверенным через вся цепочка.
Идея использования его при запросе согласия пользователя на запуск приложения с повышенными разрешениями заключается в том, что вредоносное ПО не может имитировать защищенный рабочий стол, если у него уже нет административных прав, и в этом случае обман пользователя в их предоставлении является спорным.
Есть еще другие аспекты архитектуры UAC, которые здесь не рассматриваются, но это должно предоставить достаточно доказательств того, что:
С момента своего появления в Windows Vista он был глубоко интегрирован в ключевые части операционной системы, что делает невозможным удаление всего кода, отвечающего за UAC, без ущерба для других вещей (например, вашей возможности входа в систему!)
Я думаю, можно с уверенностью сказать, что если вы "принудительно удалили" UAC, вы сломаете Windows.
Как прекрасно объяснил Твисти, существует множество компонентов, которые помогают реализовать UAC. Часть UAC, с которой люди больше всего знакомы, это диалог повышения / согласия:
Это обеспечивается consent.exe , "Согласие пользовательского интерфейса для административных приложений". Я попытался переименовать его в виртуальной машине и посмотреть, что происходит. Как и ожидалось, при использовании "Запуск от имени администратора" не отображаются подсказки повышения прав - вместо этого вы получаете ошибку "файл не найден", в которой обвиняется то, что вы пытаетесь поднять:
Попытка использовать любой элемент пользовательского интерфейса панели управления, для которого требуется повышение прав (например, имеет значок щита), даже если вы вошли в систему как администратор, завершается неудачно с похожими ошибками. Попытка запустить административные действия из меню «Пуск» приводит к несколько иной ошибке:
В зависимости от ACL, установленного при выполнении переименования, которое нарушает все, это может быть невозможно исправить изнутри ОС, так как файловые операции могут требовать повышения прав (даже если они обычно не создают диалоговое окно согласия). Обычные пользовательские действия, похоже, не ухудшаются.
