☰

Implicações de segurança da execução de scripts graváveis ​​pelo usuário com sudo

tag-icon • tag-icon security sudo root
Implicações de segurança da execução de scripts graváveis ​​pelo usuário com sudo

Preciso executar alguns comandos com sudo. Esses comandos estão localizados em .bashrcou ~/bine armazenados em um repositório git (ou seja, dotfiles).

Coloquei links simbólicos ~rootapontando para o meu usuário $HOME, mas acho que não é uma boa ideia de segurança fazer isso, então os removi.

Minha preocupação é que se umnão raizusuário tiver permissões de gravação para esses arquivos, um programa malicioso poderá executar o escalonamento de privilégios. Mesmo assim, encontro muitos repositórios de dotfiles que não são seguros em meu livro.

Em .bashrc, comandos sudopodeesteja ligado /etc/sudoerscom NOPASSWD. Nos bin/*.shscripts, eu estava pensando em omitir o sudo dos comandos e colocá-los no root, mas isso pode ser um problema, já que o git não armazena propriedade. (Quase) todos os comandos individuais exigem sudo de qualquer maneira, então acho que tecnicamente é o mesmo, exceto que atribuir scripts ao root deve ser mais seguro. Git causaria alguns problemas, eu acho.

Um pensamento: se eu concedesse todos os comandos /etc/sudoerscom NOPASSWD, se a senha do root fosse solicitada, eu sentiria o cheiro de que algo estava errado.

Informações adicionais:

  • Isto é para algumas máquinas locais de usuário único;
  • O acesso não autorizado ao meu computador desktop não é um problema, então configurei o login automático;
  • Meu laptop exige senha para iniciar uma sessão.

Se a questão ainda não estiver clara, pergunto, como posso organizar esses scripts/comandos de forma segura? O escalonamento de privilégios com root pode ser mais prejudicial do que um programa malicioso nos dados do meu próprio usuário? Talvez eu esteja apenas pensando demais?

Responder1

Um script gravável pode ser substituído por algo nefasto enquanto você não está olhando, e se o root executá-lo, o jogo termina.

É verdade que se você for o único usuário da máquina, o risco é baixo. Mas muitas vezes é mais fácil quebrar a conta de um usuário comum (ler e-mails com malware, conectar-se a um site malicioso, compilar quer queira quer não, e executar uma fonte aleatória "para ver o que faz", ...), e isso seria permitir escalar para privilégio de root.

Responder2

Considerando todas as opções que eu conhecia ( /usr/local/bin, raiz do proprietário, remoção da permissão de gravação), optei pelo sinalizador imutável em cada arquivo versionado:

sudo chattr +i filename

Usuários não root, nem mesmo o proprietário, não podem redefinir o sinalizador. Nem o arquivo ou o diretório pai podem ser removidos ou substituídos.

Para editar o arquivo, adicionei a seguinte função a .bashrc:

editrc () {
    sudo chattr -i $1
    nano $1
    sudo chattr +i $1
}

Em outros computadores, tenho que extrair os dotfiles, o sinalizador precisa ser removido antes git pulle depois reaplicado. Criou uma função auxiliar que recebe o sinalizador como argumento.

protect-config () {
    FLAG=$1
    FILES=$(git ls-files | xargs -I @ -- find @ -type f | xargs echo)
    lsattr $FILES
    if [ "$FLAG" ]; then
        sudo chattr $FLAG $FILES
    fi
}

Dito isto, sim, estou pensando demais. Ainda assim, está em vigor agora. Principalmente por bom hábito.

EDIT: Não uso mais isso, pois era mais inconveniente do que a sensação de segurança que acrescentava.

informação relacionada