Sudo for Windows: Elevação de Comandos no Windows 11 24H2

Quem gere parques mistos Linux e Windows conhece bem o sudo do lado Linux. O Windows nunca teve um equivalente nativo — a alternativa era o runas ou clicar com o botão direito e “Executar como administrador”. Desde o Windows 11 24H2 que a Microsoft oferece o Sudo for Windows: um comando sudo nativo que eleva comandos directamente de uma consola sem privilégios, com três modos de configuração. Este artigo mostra como activar, como funciona cada modo, os riscos de segurança do modo inline e como gerir a funcionalidade via política de grupo ou Intune.

O Que é o Sudo for Windows e Como Funciona

O Sudo for Windows é uma forma de os utilizadores executarem comandos elevados (como administrador) directamente de uma sessão de consola não elevada no Windows. Está disponível no Windows 11 24H2 (build 26100) ou superior e o código é open-source no repositório GitHub da Microsoft.

A diferença para o runas clássico é de conveniência e de contexto:

  • O runas lança programas como outro utilizador (incluindo administrador), sempre num contexto novo, e pode pedir password na linha de comandos. O sudo do Windows ainda não executa programas como outros utilizadores — só eleva para administrador.
  • O sudo eleva rapidamente a partir da consola actual, via User Account Control (UAC) — sem password na linha de comandos. E ao contrário do runas, pode ligar o processo elevado à janela de consola actual (nos modos inline e input closed).

O comando não vem activado por omissão. É preciso activá-lo e escolher um dos três modos de configuração.

Como Activar o Sudo nas Definições

O caminho gráfico está em Definições > Sistema > Avançadas (System > Advanced):

  1. Abrir Definições (Win+I) e navegar para Sistema > Avançadas.
  2. Alternar Activar sudo para On.
  3. Escolher o modo por omissão no menu seguinte (nova janela, input fechado ou inline).

Em alternativa, activar pela linha de comandos numa consola elevada:

# Activar com o modo recomendado (forceNewWindow — por omissão do sistema)
sudo config --enable forceNewWindow

O mesmo comando aceita os três modos: sudo config --enable forceNewWindow (nova janela — recomendado), sudo config --enable disableInput (input fechado) e sudo config --enable normal (inline).

Os Três Modos: Nova Janela, Input Fechado e Inline

Modo Nome técnico Comportamento
Nova janela (omissão) forceNewWindow O comando elevado corre numa nova janela de consola. Equivalente ao fluxo do runas.
Input fechado disableInput O comando elevado corre na janela actual, mas com o handle de input fechado — não recebe input da consola.
Inline normal O comando elevado corre na janela actual e recebe input normalmente. Máxima conveniência.

O modo por omissão do Sudo for Windows é forceNewWindow (nova janela) e é o que a Microsoft recomenda por defeito, salvo se conhecer e aceitar os riscos dos outros modos. Os modos inline e input fechado ligam o processo elevado à consola actual — mais convenientes, mas com riscos próprios.

Riscos de Segurança: Porquê Ter Cuidado com o Inline

A própria documentação da Microsoft avisa: o Sudo for Windows pode ser usado como vector de escalada de privilégios em certas configurações. O risco concentra-se nos modos que partilham a consola com processos não elevados.

No modo inline, um processo não elevado na mesma janela de consola pode enviar input ao processo elevado ou ler o output desta. Num cenário de ataque, um processo malicioso com acesso à sessão de consola pode tentar conduzir o processo elevado através da ligação estabelecida pelo sudo.exe não elevado.

O modo disableInput é a mitigação intermédia: corre na janela actual, mas fecha o handle de input — processos não elevados não conseguem escrever no processo elevado. A Microsoft recomenda escolher o modo inline apenas em cenários controlados e conhecer as implicações de segurança.

Na prática para PMEs: o modo por omissão (nova janela) é o mais seguro e o comportamento mais próximo do runas. Reservar o inline para máquinas de administrador onde a conveniência compensa.

Gestão via Política: Intune e GPO

Em gestão empresarial, o controlo faz-se pela política EnableSudo do CSP Sudo, disponível no Windows 11 24H2 e posterior (edições Pro, Enterprise, Education e IoT Enterprise). O caminho do CSP é ./Device/Vendor/MSFT/Policy/Config/Sudo/EnableSudo e os valores são:

Valor Significado
0 Sudo desactivado na máquina
1 Permitido apenas em modo force new window
2 Permitido até disable input
3 (omissão da política) Permitido até inline

Via Intune, criar uma política de definições Catalog com a definição Sudo → EnableSudo. Via GPO, a política mapeia para a configuração do comportamento do sudo nos Administrative Templates. Se a política não estiver configurada, o utilizador consegue usar o sudo depois de activar a definição nas definições — desactivar a política (valor 0) é a forma de garantir que fica indisponível.

Para ambientes geridos, a combinação típica: manter o sudo disponível para administradores em modo nova janela ou disable input, e bloquear por completo em máquinas de utilizadores standard.

Diferenças Face ao Linux: O Que Não Devem Esperar

Quem vem do Linux deve calibrar expectativas:

  • Não há sudo -u para outros utilizadores. O sudo do Windows só eleva para administrador. Correr um comando como outro utilizador continua a ser território do runas.
  • Não há password na linha de comandos — a elevação usa sempre o UAC (popup). Não é possível autenticar com password do administrador em modo texto como no Linux.
  • Não há ficheiro sudoers granular — não existe equivalente ao /etc/sudoers por utilizador/comando. O controlo é binário (activado/desactivado) mais o modo de execução, por política.
  • Não é um substituto de conta de serviço — para scripts automáticos elevados, continuam a preferir-se contas de serviço geridas ou tarefas agendadas com SYSTEM.

Para administradores que gerem os dois mundos, o Sudo for Windows é uma conveniência de consola, não uma re-implementação do modelo de privilégios Linux.

Checklist de Hardening para PMEs

  • Decidir uma política por paragem: valor EnableSudo 0 (desactivado), 1 (nova janela) ou 2 (input fechado) — evitar 3 (inline) em utilizadores standard.
  • Aplicar via Intune definições Catalog (parques geridos na cloud) ou GPO (domínios AD).
  • Inventariar quem usa sudo: os eventos de elevação aparecem no Event Viewer e o uso pode ser monitorizado via logs de Process Creation (Sysmon/Defender).
  • Não activar o inline em servidores: consolas de servidor raramente beneficiam e o vector de input partilhado não compensa.
  • Documentar no runbook interno que runas continua a ser o caminho para execução como outro utilizador.

Erros Comuns

  • Esperar que o sudo aceite password na consola. A elevação é sempre via UAC. A experiência é diferente do Linux por desenho.
  • Activar o modo inline por conveniência em utilizadores standard. É a configuração com mais risco de escalada. Usar disableInput ou nova janela.
  • Assumir que a funcionalidade existe em 23H2. O Sudo for Windows exige Windows 11 24H2 (build 26100) ou superior.
  • Confiar que a política desactivada por omissão chega. Se a política não estiver configurada, o utilizador pode activar o sudo nas Settings. Em parques geridos, definir explicitamente o EnableSudo.

Artigos Relacionados