En Windows, si rechazo la solicitud de UAC de una aplicación, ¿por qué no debe continuar ejecutándose?

Viniendo de un entorno Linux / Unix, no puedo entender cómo funciona UAC en Windows.

Escuché que UAC funciona así sudo. Mi aplicación de Linux puede hacer otro trabajo antes de llamar sudo.

Pero en Windows, ¡parece que todas las aplicaciones que requieren confirmación de UAC deben tener UAC otorgado antes de realizar cualquier trabajo real! Ejecuto una aplicación, me pide confirmación de UAC y la rechazo; la aplicación simplemente no se ejecutará.

Entonces, ¿UAC funciona así?

sudo su
./run_app

Más bien que:

./do_work1
sudo su
./du_work2

Gracias por la gran respuesta de todos!

Al iniciar sesión en Windows como usuario estándar, se crea una sesión de inicio de sesión y se asigna un token que contiene solo los privilegios más básicos. De esta manera, la nueva sesión de inicio de sesión es incapaz de realizar cambios que afectarían a todo el sistema. Al iniciar sesión como usuario en el grupo Administradores, se asignan dos tokens separados. El primer token contiene todos los privilegios típicamente otorgados a un administrador, y el segundo es un token restringido similar a lo que recibiría un usuario estándar. Las aplicaciones de usuario, incluido el Shell de Windows, se inician con el token restringido, lo que resulta en un entorno de privilegios reducidos incluso bajo una cuenta de administrador. Cuando una aplicación solicita mayores privilegios o se hace clic en "Ejecutar como administrador", UAC solicitará confirmación y, si se da el consentimiento,

Por lo que entiendo, lo que significa la última oración es que el cuadro de diálogo UAC se muestra antes de que se cargue la aplicación para que se inicie con el token no restringido, o si se inicia con privilegios de usuario estándar y necesita privilegios elevados en el medio para algunos para funcionar, necesita obtener el consentimiento del usuario y luego generar un nuevo proceso que luego se ejecuta con derechos elevados . El token asignado cuando se inicia un proceso es lo que determina sus derechos. Este token no se puede cambiar más tarde, por lo que si se requieren más derechos, se debe generar un nuevo proceso.

De esta manera, UAC no es exactamente lo mismo que sudo .

En Windows, la solicitud de UAC se activa cuando intenta ejecutar un archivo ejecutable marcado como que requiere elevación en un manifiesto incrustado en el archivo y aún no está ejecutando elevado. El comportamiento es más como setuid que su en que es el archivo, no el comando que le dice al sistema operativo que el ejecutable debe ejecutarse con credenciales diferentes.

Es porque son diferentes, simples y simples. UAC podría haberse implementado como sudo, pero no fue así.

Puede pensarlo como una analogía con la protección de la red.

sudoes como cuando un programa solicita acceso a la red y su firewall le solicita que lo otorgue o no. Puede decir que sí y el programa abrirá el socket, o puede decir que no y se quejará de la falta de conexión y hará lo que sea posible sin acceso a la red (algunos programas mal diseñados realmente fallan). Por ejemplo:

function1();
input();
function2();
secure_operation(); //requests access
function3();        //may depend on results of previous operation; error-checking important

UAC es más como la advertencia que se obtiene al intentar abrir un archivo que se descargó a un volumen NTFS. Windows le advierte sobre posibles problemas y le pregunta si desea ejecutarlo (en absoluto) o no. Es una operación de todo o nada; no puede elegir confiar solo en una parte del programa y no en otros. Por ejemplo:

if (requires_high_priv(program)) {
  if (request_priv(program))
    program();
}
else {
  program();
}

Debe recordar que, a diferencia de Linux, que está más orientado a usuarios y aplicaciones avanzados, Windows está diseñado para ser fácil de usar para la mayor variedad de usuarios posible, por lo que simplificar la seguridad es primordial. Además, debido a su gran superficie de exposición, es un objetivo frecuente de malware, por lo que tiene más sentido confiar completamente en un programa o no tenerlo en absoluto.

No conozco a fondo la arquitectura de Linux, así que perdóname si me equivoco, pero entiendo que Linux y Windows no son tan diferentes a este respecto ...

Un ejemplo ... Una secuencia de comandos de copia que hace una copia de un archivo normal a una ubicación no protegida y un archivo que intenta copiar a una ubicación protegida, luego una copia normal nuevamente.

Tengo entendido que en Linux, una aplicación simplemente se ejecuta y trata de hacer una acción, si no tiene permiso para hacerlo, fallará esa acción, pero continuará. En el ejemplo anterior, cuando ejecuta el script de copia en Linux como usuario normal, copiará el archivo normal, otorgará un problema de permiso y copiará el segundo archivo; si se ejecuta con sudo, hará las tres copias.

Windows es exactamente lo mismo a este respecto: ejecutar el script como un usuario no administrativo simplemente copiará uno, emitirá permiso el segundo y copiará el siguiente. Con UAC, ejecutará los tres.

La diferencia es que muchas aplicaciones de Windows simplemente tienen un conjunto de configuración para que soliciten la elevación de UAC de forma predeterminada y se cierren / fallen si no lo tienen ... pero eso se está volviendo mucho menor.