Desmontar /boot após a inicialização

Em teoria, nem /boot/nem /boot/efisão comumente usados ​​após a inicialização. Os dois formam uma ponte entre o BIOS (ou similar) e o sistema operacional. Eles geralmente não são usados ​​em tempo de execução.

Eles são montados para que você possa reconfigurar sua inicialização e para que seu sistema operacional possa atualizar/atualizar sua sequência de inicialização. Ou seja, no Debian, apt/ dpkgdesencadeará alterações em ambos.

Além do dpkg (ou rpm em derivados redhat), seria improvável que qualquer coisa quisesse acessar a /bootárvore de arquivos.

Do ponto de vista da segurança, eu desafiaria a sabedoria de desmontar o . Ambos devem ser somente leitura para todos os usuários, exceto root. Se um usuário obtiver acesso root, ele poderá apenas montá-los. Por outro lado, impedir que seu sistema aplique atualizações (incluindo patches de segurança) pode abrir mais brechas do que você fecha.

Em vez disso, você considerou isolar o acesso ao bastião com chrootetc.? Chroot permite que aqueles logados acessem apenas uma árvore de arquivos filho e um namespace pid e namespace de usuário podem proteger contra algo escapando ( chrootsomente não é suficiente).

A maneira mais fácil de fazer isso pode ser substituir seu servidor SSH por docker (ou podman ) executando openssh dentro de um contêiner. Isso deixaria qualquer cliente SSH dentro de um contêiner docker que não teria visão do sistema host. O sistema de arquivos dentro desse contêiner pode ser realmente mínimo, como um contêiner linux alpino com quase nada além de uma linha de comando mínima.

Nota para maior clareza: chroot não é suficiente para isolar um processo. Com acesso root, um processo pode escapar do chroot. No entanto, outros isolamentos, como pid e namespaces de usuário e recursos de descarte, devem fazer muito para proteger um processo dentro de uma jaula chroot... Daí a sugestão de usar o docker.

Efeitos colaterais: Nenhum que eu tenha notado. Além, é claro, do fardo trazido pela necessidade de ter certeza de montá-lo antes de instalar um novo kernel. (tenha certeza porque, caso não seja, a instalação irá graciosamente e silenciosamente instalar o kernel no diretório root /boot…)
Os benefícios em termos de segurança são, no entanto, discutíveis.

A maneira correta de proceder (qualquer que seja o sistema init) é quase certamente… não montá-lo durante a inicialização… já que nunca é realmente necessário ;-P
Verifique a entrada associada em seu fstab e simplesmente adicione um parâmetro noauto , isso pode parecer :LABEL=LTUX_BOOT /boot ext4 noauto,noatime 0 2

Se você definitivamente deseja montá-lo (para desmontar mais tarde), você pode se beneficiar do recurso x-systemd.idle-timeout do sistema de montagem. Adicionar algo parecido noauto,x-systemd.automount,x-systemd.idle-timeout=1sà entrada /boot do seu fstab teria seu sistema de arquivos desmontado automaticamente após 1 segundo de tempo ocioso.

Agora que penso nisso, você está perguntando isso do ponto de vista específico de uma máquina virtual bastião. Estes normalmente são sem estado com muito pouco instalado.

Se você estiver remotamente preocupado com os danos que um hacker pode causar usando /boot, a maioria desses danos entrará em vigor quando a VM for reiniciada.

Se você quisesse uma visão extremista disso, você poderia destruir completamente sua partição de inicialização e após a inicialização. Afinal, é uma VM. Para "reiniciar" ou até mesmo aplicar atualizações de segurança, basta ativar uma nova VM e derrubar a antiga. Então não há "nada" que um hacker possa fazer para interferir na sequência de inicialização da VM.

Conforme declarado em minha outra resposta, não há motivo real para manter /boote /boot/efimontar, exceto para aplicar atualizações de segurança.

Testando isso, nenhum problema parece aparecer; pode ter algum efeito colateral que estou perdendo?

Não, não realmente, exceto que algumas ferramentas podem realmente precisar dele montado que você pode não ter pensado (por exemplo, o GRUB precisará dele montado sempre que for atualizado, não apenas para atualizações do kernel).

Os sistemas provavelmente serão baseados no Debian Linux (outro cenário, no Redhat). Ambos são systemd. Qual é a maneira correta de desmontar /boot em um sistema systemd após a reinicialização? Para testar, apenas sudo umount /boot.

Como apontado em outro lugar, apenas não monte em primeiro lugar. Basta adicionar noautoas opções na /etc/fstabentrada para ele.

Estou me debatendo se vou usar BIOS ou UEFI. Como serão VMs, é uma questão de escolha. UEFI parece ser uma escolha mais sensata quanto mais moderna. Mas não tenho certeza em relação aos benefícios de segurança, se houver. Pelo contrário, por ser mais complicado, mais chances de vulnerabilidades talvez.

Se você usa UEFI você pode, teoricamente, evitar a necessidade de um carregador de inicialização, mas fazer isso com o Debian (e a maioria das outras distribuições Linux além do Gentoo) é extremamente complicado.

O UEFI também é geralmente necessário para o Secure Boot, o que parece que você provavelmente deseja, embora seja difícil acertar em uma VM.

Fora isso, não há muito benefício de uma forma ou de outra, porque você não pode auditar o código envolvido em nenhum dos casos (o que significa que você não pode raciocinar corretamente sobre uma opção ser mais segura que a outra).

No caso de UEFI, e a partição efi? Ele é montado dentro de /boot por padrão, embora eu ache que /efi possa ser usado (não tentei), para separá-los e manuseá-los de forma mais transparente, do lado do administrador. /boot/efi ou /efi também pode ser desmontado após a inicialização sem efeitos colaterais?

Os mesmos comentários que para /boot. Ele pode ser montado em qualquer lugar, mas a convenção indica que /boot/efié o ponto de montagem esperado.

Há duas razões para isso:

• Isso facilita a escrita de políticas de segurança para sistemas de controle de acesso obrigatório orientados por caminho (como AppArmor), porque eles podem ter apenas uma cláusula geral para tudo em /boot.
• Mantém as coisas organizadas onde deveriam estar. As coisas envolvidas na inicialização do sistema são colocadas em /boot, como tem sido na maioria dos sistemas do tipo UNIX por muito tempo.

Como um aparte, isso na verdade não fornece uma melhoria significativa na segurança em relação à dificuldade geral envolvida em fazê-lo corretamente.

A maneira normal de proteger /booté garantir que não seja gravável por ninguém além do usuário root, ou se você estiver se sentindo especialmente paranóico, não legível ou atravessável por qualquer pessoa além do root. Essa abordagem significa que qualquer pessoa que não tenha um EUID de 0 ou o recurso CAP_DAC_OVERRIDE não pode modificar nada em /boot, mas, notadamente, não requer nenhum tratamento especial para que as atualizações funcionem corretamente.

Sua abordagem também significa que qualquer pessoa que não tenha um EUID de 0 ou o recurso CAP_DAC_OVERRIDE (alguém com esse recurso pode, por exemplo, reescrever /etc/fstabpara que /bootseja montado na inicialização e, em seguida, encontrar várias maneiras criativas de forçar um reinicialização do sistema, ou como outro exemplo poderia apenas escrever diretamente no dispositivo de bloco subjacente) não pode modificar nada em /boot, mas somente quando não há nada modificando legitimamente nada em /boot(porque a modificação legítima requer/bootpara ser montado). Ele também requer tratamento especial para garantir que atualizações do kernel, atualizações do carregador de inicialização e uma pequena seleção de outros tipos de atualizações (como atualizações de módulos do kernel de terceiros) funcionem corretamente. Observe que a montagem automática não funciona aqui, porque se você configurar a montagem automática, alguém precisará tentar acessar o diretório para montá-lo.

Observe que sua abordagem não oferece proteção significativa contra um invasor dedicado, mas torna mais provável que você realmente quebre algo por acidente (por exemplo, mas executando atualizações sem ele montado).

/booté normalmente usado pelo bootloader , geralmente pelo GRUB. No uso típico, /bootconterá quaisquer arquivos de configuração do carregador de inicialização que possam precisar de atualização nas atualizações do kernel e os arquivos kernel e initramfs para as versões do kernel instaladas. Se o bootloader requer alguns outros arquivos, eles também podem ser colocados em /boot.

Como o bootloader precisa ser executado antes que o kernel do sistema operacional esteja presente, ele não pode confiar nos conceitos do kernel do Linux como "montar um sistema de arquivos". Em vez disso, quando o carregador de inicialização acessa um sistema de arquivos, ele deve fazê-lo usando suporte de firmware (partição de sistema EFI em sistemas UEFI) ou os próprios drivers do sistema de arquivos do carregador de inicialização. Esses drivers de nível de bootloader geralmente são simplificados e oferecem acesso somente de leitura, sem usar cache avançado ou qualquer outro método para aumentar o desempenho, pois seu único trabalho será carregar os poucos arquivos necessários para inicializar o kernel do sistema operacional.

Você normalmente não pode transferir o estado do driver do sistema de arquivos do carregador de inicialização para o controle do kernel, e como o kernel normalmente tem drivers de sistema de arquivos de maior desempenho de qualquer maneira, você nem gostaria de fazê-lo.

Uma vez que o bootloader tenha carregado com sucesso o kernel (e no caso do Linux, geralmente também o arquivo initramfs) na memória RAM e iniciado o kernel, o trabalho do sistema de /bootarquivos está essencialmente feito. Nem o kernel Linux nem o arquivo initramfs normalmente requerem algo mais do sistema de /bootarquivos. A única razão para montar /bootcomo parte da inicialização do sistema é tê-lo prontamente disponível caso atualizações do kernel sejam instaladas.

E assim, a melhor maneira de "desmontar /bootapós a inicialização" é, na grande maioria dos casos, simplesmente comentar /etc/fstabou adicionar uma noautoopção de montagem, ou seja, não montá-la no momento da inicialização.

Parece haver um conjunto de diretórios padrão para scripts a serem executados nas atualizações do kernel:

• /etc/kernel/preinst.d/para scripts que devem ser executados antes de instalar um novo kernel
• /etc/kernel/postinst.d/para scripts que devem ser executados após a instalação de um novo kernel
• e /etc/kernel/prerm.d/e /etc/kernel/postrm.d/para scripts que devem ser executados antes e depois de remover um kernel instalado, respectivamente.

Os scripts nesses diretórios serão executados na ordem usual de classificação US-ASCII por nome de arquivo. Se você colocar um script para montar /bootcomo /etc/kernel/preinst.d/000-mountboote /etc/kernel/prerm.d/000-mountboote outro script para desmontá-lo novamente como /etc/kernel/postinst.d/zzz-umountboote /etc/kernel/postrm.d/zzz-umountboot, você deverá obter exatamente a funcionalidade desejada, assumindo que os pacotes de kernel padrão de sua distribuição são construídos para chamar esses scripts nas fases apropriadas.

A partição ESP do UEFI (geralmente montada como /boot/efi) é exatamente a mesma, mas para o firmware do sistema em vez do carregador de inicialização. Assim que o firmware tiver carregado com sucesso o *.efiarquivo do carregador de inicialização da partição ESP (e quaisquer arquivos suplementares que o carregador de inicialização possa ter lá), o trabalho principal do ESP será feito e não será necessário novamente até uma atualização do carregador de inicialização ou o próximo ciclo de inicialização .

No entanto, a partição UEFI ESP pode ter uma função secundária: se o firmware UEFI suportar "cápsulas de atualização de firmware" (ou seja, uma maneira padronizada de agendar uma atualização de firmware do sistema a partir de um sistema operacional em execução), os arquivos de atualização de firmware precisariam ser gravados em o ESP antes de configurar o processo de atualização. O Linux tem ferramentas para usar este mecanismo: veja as man pages para comandos fwupdate, fwupdmgre/ou fwupdtool. Se esse mecanismo eventualmente substituir as ferramentas de atualização UEFI/BIOS específicas do fornecedor, você terá pelo menos duas condições em que o ESP deve ser montado:

• ao instalar uma atualização do bootloader
• ao instalar uma atualização de firmware UEFI

Por enquanto, não parece haver um gancho padrão para adicionar scripts personalizados a esses eventos, diferentemente do caso das atualizações do kernel.

Desmontar /boot depois que o sistema operacional estiver ativo é certamente possível. Na verdade, é uma prática padrão em muitas distribuições Linux. O Gentoo gudie certamente assume isso e eu fiz isso em todas as instalações do Gentoo que já fiz (o que é MUITO).

Se ele alcança o que você acha que obterá é uma questão completamente diferente.