Protecao de Senha no GRUB2

Aplicavel a: Linux Server, Proxmox VE, KVM/QEMU, outros hypervisors baseados em Linux Versao do GRUB: 2.x (incluindo o 2.12 que vem no Proxmox 9)

Por que isso importa

Todo servidor Linux que voce administra tem uma porta dos fundos que a maioria dos admins esquece de trancar: o proprio bootloader. Sem senha no GRUB, qualquer pessoa com acesso fisico ao servidor, ou acesso ao console remoto (IPMI, iDRAC, iLO, ou o console web do Proxmox) consegue interromper o boot, apertar e para editar os parametros do kernel, ou apertar c para abrir o shell do GRUB direto. A partir dai da para remover ro quiet splash e colocar init=/bin/bash, e o cara entra no sistema como root sem digitar senha nenhuma.

Isso nao substitui LUKS, nao substitui controle de acesso fisico ao rack, e nao substitui uma politica decente de quem tem acesso ao console de gerenciamento. E so mais uma camada. Mas e uma camada barata de configurar e que fecha um dos vetores de escalada mais simples que existem em auditoria de hardening.

Vale lembrar desde ja: a senha do GRUB, do jeito que vamos configurar aqui, protege a edicao de entradas e o shell, mas nao bloqueia o boot normal na entrada padrao. Isso e proposital, e explico o motivo mais adiante.

Passo 1: gerar o hash da senha

O GRUB nao aceita senha em texto puro no arquivo de configuracao, entao o primeiro passo e gerar um hash PBKDF2:

grub-mkpasswd-pbkdf2

O comando vai pedir a senha duas vezes e devolver algo assim:

Enter password:
Reenter password:
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.XXXXXXXX...

Copie apenas a parte que comeca com grub.pbkdf2.sha512. A frase "PBKDF2 hash of your password is" e so o comando te dizendo o que ele fez, nao faz parte do hash.

Um detalhe que pega bastante gente no primeiro teste: o GRUB usa o mapa de teclado da BIOS/UEFI no momento do boot, que pode ser diferente do layout configurado no seu sistema operacional. Se voce digitar uma senha cheia de caracteres especiais (@, #, !) ou acentos e ela nao funcionar na tela de boot, o problema normalmente e esse. Recomendo testar primeiro com uma senha simples, validar que a autenticacao esta funcionando, e so depois trocar para uma senha mais complexa.

Passo 2: criar o arquivo de usuarios do GRUB

nano /etc/grub.d/01_users

Conteudo do arquivo:

#!/bin/sh
cat << EOF
set superusers="admin-grub"
password_pbkdf2 admin-grub grub.pbkdf2.sha512.10000.SEU_HASH_AQUI
EOF

Troque grub.pbkdf2.sha512.10000.SEU_HASH_AQUI pelo hash completo que voce gerou no passo anterior.

O nome admin-grub e so um rotulo interno do GRUB, ele nao precisa (e normalmente nao deve) corresponder a nenhum usuario real do sistema Linux. Trate como um nome de usuario que existe apenas dentro do contexto do bootloader.

Passo 3: ajustar permissoes

chmod 755 /etc/grub.d/01_users

Esse passo e facil de esquecer e o resultado e frustrante: sem a permissao de execucao, o update-grub simplesmente ignora o script silenciosamente, sem erro nenhum, e voce fica sem entender por que a senha nao aparece no grub.cfg depois.

Passo 4: regenerar o GRUB

update-grub

No Proxmox e em algumas outras distros, o comando equivalente e:

grub-mkconfig -o /boot/grub/grub.cfg

Passo 5: validar a configuracao

Confirme que o usuario e o hash foram realmente gravados no grub.cfg:

grep -n "superusers\|password_pbkdf2" /boot/grub/grub.cfg

Voce deve ver algo assim:

set superusers="admin-grub"
password_pbkdf2 admin-grub grub.pbkdf2.sha512.10000.XXXXXXXX...

Se essas linhas nao aparecerem, volte no passo 3 e confira a permissao do arquivo /etc/grub.d/01_users, e revise se o conteudo esta exatamente como no exemplo.

O que a senha realmente protege

Acao no GRUB	Protegida pela senha?
Navegar no menu de boot	Nao, o menu continua visivel
Editar entradas (`e`)	Sim
Abrir o shell do GRUB (`c`)	Sim
Boot normal na entrada padrao	Nao, inicia sem senha

O comportamento padrao do GRUB2 e pedir autenticacao so para edicao e acesso ao shell, nao para o boot em si. Isso faz sentido do ponto de vista pratico: voce nao quer que o servidor fique travado numa tela pedindo senha toda vez que reinicia sem ninguem fisicamente presente.

Sobre o `--unrestricted` no Proxmox 9 com GRUB 2.12

Esse e um ponto que vale documentar porque circula bastante informacao incorreta sobre ele.

A opcao --unrestricted em um menuentry existe para permitir que entradas especificas iniciem sem exigir senha, mesmo com o superusers configurado. E util em cenarios onde voce quer proteger o shell e a edicao, mas garantir que o boot automatico continue liberado.

O problema: no Proxmox 9 rodando GRUB 2.12, se voce adicionar set CLASS="--unrestricted" no arquivo /etc/grub.d/40_custom, isso nao tem efeito nenhum nas entradas que sao geradas automaticamente pelo script 10_linux. O motivo e simples, o 10_linux monta seus proprios menuentry do zero e nao herda variaveis definidas em 40_custom.

A unica forma de aplicar --unrestricted nas entradas automaticas seria editar diretamente o script /etc/grub.d/10_linux, o que eu nao recomendo em ambiente de producao ou gerenciado, porque esse arquivo pertence ao pacote grub-common e qualquer atualizacao do pacote sobrescreve suas alteracoes sem aviso.

Conclusao pratica: nao documente nem replique por ai a ideia de que set CLASS="--unrestricted" em 40_custom resolve isso no Proxmox 9 / GRUB 2.12. Testei e confirmo que nao funciona para as entradas geradas automaticamente.

Referencia rapida de comandos

# Gerar hash
grub-mkpasswd-pbkdf2

# Criar ou editar arquivo de usuarios
nano /etc/grub.d/01_users

# Corrigir permissoes
chmod 755 /etc/grub.d/01_users

# Regenerar configuracao
update-grub
# ou, em algumas distros
grub-mkconfig -o /boot/grub/grub.cfg

# Validar
grep -n "superusers\|password_pbkdf2" /boot/grub/grub.cfg

Checklist de implantacao

[ ] Hash gerado com grub-mkpasswd-pbkdf2
[ ] Arquivo /etc/grub.d/01_users criado com o hash correto
[ ] Permissao 755 aplicada ao arquivo
[ ] update-grub executado sem erros
[ ] grep no grub.cfg confirma as duas linhas esperadas
[ ] Teste de boot realizado, acesso ao shell do GRUB exige senha
[ ] Hash e senha armazenados em cofre de senhas (Vault, KeePass, etc.)