Eu tenho um GitLab Runner e meus colegas de trabalho estão preocupados com comandos como
- Remove-Item $SOME_FOLDER* -Recurse -Force
pode ser perigoso. Por exemplo, se o GitLab Runnier tiver privilégios de administrador, executar acidentalmente este comando pode causar coisas ruins ☢️:
- Remove-Item C:\* -Recurse -Force
Para corrigir isso, criei uma conta de serviço local . Para os propósitos desta pergunta, podemos supor que a conta foi nomeada my_service_account. Não atribuí my_service_account a nenhum grupo. Na verdade, nem o atribuí ao grupo de usuários. Em seguida, dei a my_service_account CONTROLE COMPLETO do diretório de implantação.
Unfortunately, while my_service_account does seem to keep the GitLab Runner from nuking the entire host system with a command like:
- Remove-Item C:\* -Recurse -Force
it does not seem to keep the GitLab Runner from doing stupid stuff like this:
- echo "test" > c:\someExistingDir\someNewGarbageFile.txt
My mentor and I looked into this a bit and we found that we can keep the GitLab Runner from creating random files by applying the deny type to the FULL CONTROL basic permission on all directories we want to protect. Unfortunately, we want to protect the entire system from this and only allow the GitLab Runner to write to the deployment directory.
Então, tentei aplicar um tipo de negação à permissão básica FULL CONTROL em toda a unidade C:, mas quando comecei a usar a GUI do MS Windows para fazer isso, parecia querer substituir as permissões para vários outros usuários e grupos como Administradores, SISTEMA, Usuários e Usuários Autenticados (Ver Figura):
Qual é a maneira mais fácil e segura de NEGAR o acesso a todos os arquivos do sistema para my_service_account sem usar a GUI mencionada, o que pode resultar em "danos colaterais"?
NOTA: A imagem da GUI é, na verdade, do meu PC doméstico e não da máquina que hospeda o GitLab Runner. A imagem é fornecida para ilustrar o problema em que a GUI insiste que eu altere as permissões para usuários e grupos que estão fora do escopo da IMO.
Você deseja garantir que a conta de usuário que o serviço está executando ou o contexto em que os comandos podem ser executados não tenha permissão de administrador local para o sistema.
Quando você configura uma nova "
deny
" regra NTFS no nível "C:\
" , você não pode realmente proteger nenhum arquivo e pasta filho abaixo, a menos que você "Replace all child object permission entries with inheritable permission entries~
" desse objeto pai para o qual você está definindo a nova regra de negação.O que você define no nível pai precisa ser herdado e propagado para todos os objetos filho para que essas restrições de permissão também entrem em vigor nos objetos filho.
Observe também que mesmo marcar essa opção e permitir que novas permissões restritivas NTFS se propaguem para o objeto filho não afetará nenhuma pasta ou arquivo cuja herança esteja explicitamente desativada ou quebrada.
Para mantê-lo simples , eu garantiria que a conta de serviço não tenha acesso de administrador local ao sistema, tenha bons backups do sistema e processos de restauração/recuperação e teste os comandos em execução para tentar quebrá-lo.