É fácil iniciar um processo em segundo plano ou torná-lo como systemdserviço.
Porém, se eu quiser iniciar um processo que monitore atividades na máquina Linux, ele cai no alvo de ataques. Se algum usuário quiser fazer algo ruim, ele primeiro matará esse processo, mesmo que sejam apenas sudousuários ou wheelusuários, simplesmente executando killor systemctl stop.
Existe uma maneira de impor um processo que só rootpode matar?
Pessoal, só de pensar que até mesmo rsyslogum serviço pode ser eliminado, vocês deveriam reconhecer o quão vulnerável o Linux realmente é. É como se um piloto pudesse desligar a caixa preta. Alguma companhia aérea permite que isso aconteça? Ou alguém dá ao piloto uma lista de permissões para impedi-lo de fazer qualquer coisa que puder para salvar o avião? É claro que o piloto pode derrubar o avião, mas a caixa preta irá gravá-lo.
Minha proposta de uma lista de banimentos é legítima do ponto de vista da segurança, mesmo que isso possa assustar você. Então não tente culpar o cara que levantou a questão, certo?
Responder1
Tendo privilégios irrestritos de sudo/wheel, qualquer pessoa poderá desfazer qualquer coisa que você tenha feito. Mesmo que você consiga fazer isso removendo a possibilidade de encerrar o processo diretamente, por exemplo, com sudo kill, isso ainda pode ser contornado usando outros comandos sudoed ou você também fica fora da administração.
Pergunte a si mesmo: em primeiro lugar, por que usuários não confiáveis têm privilégio sudo irrestrito? Eles não deveriam. Dê esses privilégios apenas àqueles em quem você confia totalmente. Se houver alguns comandos privilegiados que ainda precisam ser executados, habilite o sudo apenas para esses comandos:
+netmgr /usr/sbin/ifup, /usr/sbin/ifdown
(use visudo -f /etc/sudoers.d/netmgrpara colocar isso no arquivo complementar do sudoers).
Dessa forma, você pode permitir que um usuário execute apenas sudo /usr/sbin/ifupand sudo /usr/sbin/ifdown, mas nenhum outro comando sudo. Muitos outros exemplos, instruções e considerações de segurança estão no arquivo man sudoers. Leia-o!
A auditoria geralmente é feita de outra maneira. Em particular, você configuraoutromáquina, configure seu syslog para aceitar logs de estações remotas. Na máquina em questão você configura o log para que ele envie todos os logs para a máquina de log, além de armazenar localmente. Mesmo que alguém desative esse envio de log, a ação de desativá-lo será registrada, então pelo menos você saberá quem é o culpado.
Responder2
Você não pode dar um poder a alguém e depois impedi-lo de usá-lo. Você tem que focar estritamente o poder que você dá a eles para incluir apenas o que você deseja que eles tenham.
Em um comentário, você disse:
Eu tenho que permitir que eles usem
killousystemctl stopporque existem alguns aplicativos que precisam desses privilégios para fazer seu trabalho
Isso não significa que aquelesUsuáriosprecisa de acesso a esses comandos, apenas aquelesformulários. O usuário tem permissões limitadas para execução sudo ./someprograme, uma vez que o programa esteja sendo executado como root, ele pode usar kill, etc., conforme necessário. O usuário não tem acesso direto a esses comandos internos.
Fundamentalmente falando, os usuários não precisam de acesso acomandos, eles precisam de acesso afuncionalidade. Se killfor muito arriscado, bloqueie o acesso a ele e forneça outra maneira mais segura de obter o mesmo resultado. Talvez você crie um pequeno utilitário safekillque atue como, killmas recuse solicitações para encerrar determinados processos. Dê aos seus usuários acesso sudo, safekillmas não o real kill. Se os usuários estiverem sempre usando esses comandos para fazer a mesma coisa, encapsule todo o processo em um pequeno programa e faça-os usá-lo em vez de fazê-lo manualmente (por exemplo, eles executariam sudo restart_webserversem vez de encerrar e reiniciar todos os vários processos do servidor individualmente) . Seus usuários ainda têm acesso às funcionalidades de que precisam, mas não podem manejar armas perigosas diretamente.
Há outro mecanismo de aplicação mais extremo que pode estar disponível dependendo da sua configuração específica. Alguns processadores têmtemporizadores de vigilânciadisponível. Modifique seu programa de monitoramento de atividades para iniciar o watchdog e redefini-lo a cada dois segundos. Se alguém conseguir matar o seu monitor, o temporizador do watchdog expirará e o sistema será reinicializado, reiniciando o programa do monitor na inicialização. Isso não impediria estritamente que o monitor fosse desativado, mas proibiria qualquer pessoa de fazer algo significativo após desativá-lo. Isso também criará grandes sinais de alerta nos logs do sistema. A maioria dos sistemas com watchdogs reportará quando uma reinicialização específica foi acionada pelo watchdog. Uma reinicialização acionada por watchdog que ocorre enquanto um usuário estava logado no shell deve ser vista comomuitosuspeito.
Responder3
Linux novato aqui. Você poderia considerar escrever programas ou scripts que façam apenas o que esses caras devem fazer, depois torná-los proprietários de root e adicioná-los com o bit setuid? Claro, um grande problema é que você pode não querer que outras pessoas executem esses comandos. Não tenho certeza se você pode obter as informações originais do usuário. E claro, cuidado extra é sempre necessário com setuid/setgid.
Responder4
Eu criei um começo!
rootpode definir um DEFAULT SHELL em um usuário como este:
useradd [someuser] -s [a certain executable]
Então, se o executável específico = Um script de censura que:
Censura automaticamente a execução de determinados comandos. Gosto
stopersyslogcombinado.proíbe comandos para escapar deste shell e usar outro até mesmo o original
bashproíbe comandos para evitar que o usuário obtenha a função
rootcomo @user253751 mencionado acima.Passe o resto dos comandos para
/bin/bash
Depois é só configurá-lo r+xpara qualquer usuário.
Qualquer sugestão é apreciada nesta resposta. Especialmente para 2 e 3, parece haver vários meios.
O Bash carregará as configurações /etc/profileprimeiro /etc/bashrc. Tenho notado que o último lida com a PROMPT_COMMANDvariável. É possível sequestrar isso na última linha para adicionar no script de censura, mas um nome de usuário de isenção é necessário para alguns sistemas, já que por padrão ninguém tem privilégio de root para alterá-lo de volta.
Uma censura completa que satisfaça o 4+1 acima será marcada como resposta legítima.
Nunca marcarei uma resposta "você deve desistir" como legítima.
questões relacionadas são:
Como posso registrar os comandos bash dos usuários?
Como posso fazer o bash para registrar comandos shell no syslog?