Quero configurar o sudoedit sem senha para editar arquivos, /etccom exceção dos próprios arquivos do sudoer.
Tentei usar o seguinte /etc/sudoers.d/sudoedit:
%sudo ALL=(root) NOPASSWD: sudoedit ^/etc/(?!sudo).*$
mas isso não parece funcionar, pois o sudo usa um mecanismo de regex antigo sem o recurso de lookahead negativo.
Existe outra maneira de conseguir isso? Talvez com a combinação de /etce a negação de !/etc/sudo?
No Linux Ubuntu quando no terminal eu executo sudo suou sudo su -o sistema cria uma nova sessão com um novo controle pts, ou seja
ubuntu@ubuntu:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.5 LTS
Release: 22.04
Codename: jammy
ubuntu@ubuntu:~$
ubuntu@ubuntu:~$ uname -a
Linux ubuntu 5.15.0-124-generic #134-Ubuntu SMP Fri Sep 27 20:20:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@ubuntu:~$
ubuntu@ubuntu:~$ ps
PID TTY TIME CMD
143254 pts/0 00:00:00 bash
143302 pts/0 00:00:00 ps
ubuntu@ubuntu:~$
ubuntu@ubuntu:~$ sudo su -
root@ubuntu:~#
root@ubuntu:~# ps
PID TTY TIME CMD
143304 pts/1 00:00:00 sudo
143305 pts/1 00:00:00 su
143306 pts/1 00:00:00 bash
143316 pts/1 00:00:00 ps
root@ubuntu:~#
É um comportamento esperado?
Conforme solicitado nos comentários:
$ ps
PID TTY TIME CMD
146202 pts/0 00:00:00 bash
146231 pts/0 00:00:00 ps
$ sudo -s
root@ubuntu:/home/ubuntu# ps
PID TTY TIME CMD
146233 pts/1 00:00:00 sudo
146234 pts/1 00:00:00 bash
146240 pts/1 00:00:00 ps
Tenho o Amazon Linux 2023 em execução em um contêiner Docker e gostaria de poder carregar algumas regras de auditoria personalizadas no kernel e garantir que elas persistam quando o contêiner for reiniciado. Eu adicionei as regras /etc/audit/rules.d/audit.rulese posso vê-las quando coloco catesse arquivo e estou tentando usá-lo augenrules --loadpara carregar as regras. No entanto, quando executo este comando, a saída que recebo é
/usr/sbin/augenrules: No change
You must be root to run this program.
Recebo essa mesma resposta mesmo ao executar o comando com sudo( sudo augenrules --load). Já estou logado como root ( whoamiretorna root).
Eu me perguntei se poderia ser porque auditdo serviço não foi iniciado (nesse caso, a saída de augenrulesé enganosa), mas não consigo verificar o status deste serviço como service auditd status(e qualquer outro comando de serviço como service auditd start) o comando me fornece
Redirecting to /bin/systemctl status auditd.service
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
ps -p1indica que o PID 1 é bash
PID TTY TIME CMD
1 pts/0 00:00:00 bash
Presumo que seja porque estou executando em um contêiner, mas não sei se é por isso que augenrulesme recuso a executar quando sou o usuário root, mesmo quando uso using sudo.
O que está causando esse comportamento?
Variável adicionada LD_PRELOADao final de /etc/profile:
export LD_PRELOAD=/tmp/libhooks.so
Então eu inicio uma nova sessão ssh e há uma LD_PRELOADvariável nela:
[admin@Centos8 ~]$ env | grep LD_PRELOAD
LD_PRELOAD=/tmp/libhooks.so
Mas se você executar este comando via sudo enquanto salva as variáveis, por algum motivo LD_PRELOADnão será salvo:
[admin@Centos8 ~]$ sudo --preserve-env env | grep LD_PRELOAD #doesn't output anything
Isso não é realmente um problema, apenas uma peculiaridade que gostaria de entender.
Se eu obtiver um shell root sudo bash -le depois executar, less somefilenamerecebo menos apenas mostrando:
Esta conta não está disponível no momento.
(Isso não é mostrado como um erro , é mostrado dentro de less como se fosse o conteúdo do arquivo.)
No entanto, se eu usar o mesmo shell raiz sudo bash -le executar cat somefilename | less, verei o conteúdo real do arquivo.
Além disso, se eu obtiver um shell de root sudo bashe pular -le executá-lo, less somefilenameele mostrará o conteúdo do arquivo.
O login do Root está desabilitado; a /etc/passwdlinha é root:x:0:0:root:/root:/sbin/nologintão sudo su -não funciona.
Mas, por que a nologinentrada deveria fazer alguma diferença na execução lessde um arquivo? E por que só faz diferença se lessfor executado diretamente no arquivo, em vez de também aplicar menos execução em seu stdin? E por que isso só acontece com um bash -lshell?
(Isso está em um sistema CentOS 7.)
Eu coloquei essa linha sudoers:
Cmnd_Alias NVIDIA = /sbin/sh -c 'echo ON > /proc/acpi/bbswitch; modprobe nvidia; modprobe nvidia_drm modeset=1'
user ALL=(ALL) ALL, NOPASSWD: /sbin/systemctl suspend,NVIDIA
Meu sudo -lme mostra:
sudo -l
User user may run the following commands on devbox:
(ALL) ALL, NOPASSWD: /sbin/systemctl suspend, /sbin/sh -c 'echo ON > /proc/acpi/bbswitch; modprobe nvidia; modprobe nvidia_drm modeset\=1'
No entanto, se eu tentar executar /sbin/sh -c 'echo ON > /proc/acpi/bbswitch; modprobe nvidia; modprobe nvidia_drm modeset=1', ainda serei solicitado a inserir a senha.
Suspeito que haja algo sobre =o sinal que tenho no modesetargumento para carregamento da nvidia.
execute isso no terminal com a internet desligada:
while true;do sudo -n uptime 2>/dev/null;echo "`date`($((i++)))";sleep 0.1;done
agora ligue a internet (WIFI aqui).
O log acontecerá agora a cada 5s a 10s...
Como fazer o sudo ignorar a internet?
Além disso, por que se comporta assim?
Obs.: Ubuntu 22.04
PS.: utilizo sudo -n uptimepara alertar se o terminal tem acesso sudo (pinto tudo de vermelho). Então, recebo esse problema em todos os comandos que executo no terminal.
um registro com os atrasos quando o WIFI está ligado:
Fri 5 Jan 00:07:41 -03 2024(0)
Fri 5 Jan 00:07:47 -03 2024(1)
Fri 5 Jan 00:07:52 -03 2024(2)
Fri 5 Jan 00:07:57 -03 2024(3)
Fri 5 Jan 00:07:57 -03 2024(4)
Fri 5 Jan 00:08:02 -03 2024(5)
Fri 5 Jan 00:08:02 -03 2024(6)
Fri 5 Jan 00:08:13 -03 2024(7)
Fri 5 Jan 00:08:18 -03 2024(8)
Fri 5 Jan 00:08:18 -03 2024(9)
Fri 5 Jan 00:08:23 -03 2024(10)
Fri 5 Jan 00:08:28 -03 2024(11)
Fri 5 Jan 00:08:28 -03 2024(12)
Fri 5 Jan 00:08:34 -03 2024(13)
Fri 5 Jan 00:08:39 -03 2024(14)
Fri 5 Jan 00:08:44 -03 2024(15)
Fri 5 Jan 00:08:44 -03 2024(16)
quando o WIFI está desligado:
Fri 5 Jan 00:11:45 -03 2024(21)
Fri 5 Jan 00:11:45 -03 2024(22)
Fri 5 Jan 00:11:46 -03 2024(23)
Fri 5 Jan 00:11:46 -03 2024(24)
Fri 5 Jan 00:11:46 -03 2024(25)
Fri 5 Jan 00:11:46 -03 2024(26)
Fri 5 Jan 00:11:46 -03 2024(27)
Fri 5 Jan 00:11:46 -03 2024(28)
Fri 5 Jan 00:11:46 -03 2024(29)
Fri 5 Jan 00:11:46 -03 2024(30)
Fri 5 Jan 00:11:47 -03 2024(31)
Fri 5 Jan 00:11:47 -03 2024(32)
Fri 5 Jan 00:11:47 -03 2024(33)
Fri 5 Jan 00:11:47 -03 2024(34)
Fri 5 Jan 00:11:47 -03 2024(35)
Fri 5 Jan 00:11:47 -03 2024(36)
Fri 5 Jan 00:11:47 -03 2024(37)
Fri 5 Jan 00:11:47 -03 2024(38)
Fri 5 Jan 00:11:47 -03 2024(39)
Fri 5 Jan 00:11:48 -03 2024(40)
Fri 5 Jan 00:11:48 -03 2024(41)
Fri 5 Jan 00:11:48 -03 2024(42)
Fri 5 Jan 00:11:48 -03 2024(43)
Fri 5 Jan 00:11:48 -03 2024(44)
Fri 5 Jan 00:11:48 -03 2024(45)
Fri 5 Jan 00:11:48 -03 2024(46)
Fri 5 Jan 00:11:48 -03 2024(47)
Fri 5 Jan 00:11:49 -03 2024(48)
Fri 5 Jan 00:11:49 -03 2024(49)
Fri 5 Jan 00:11:49 -03 2024(50)
Fri 5 Jan 00:11:49 -03 2024(51)
Fri 5 Jan 00:11:49 -03 2024(52)
Fri 5 Jan 00:11:49 -03 2024(53)
Fri 5 Jan 00:11:49 -03 2024(54)
Fri 5 Jan 00:11:49 -03 2024(55)
Fri 5 Jan 00:11:50 -03 2024(56)
Fri 5 Jan 00:11:50 -03 2024(57)
Fri 5 Jan 00:11:50 -03 2024(58)
Fri 5 Jan 00:11:50 -03 2024(59)
Fri 5 Jan 00:11:50 -03 2024(60)
Fri 5 Jan 00:11:50 -03 2024(61)
Fri 5 Jan 00:11:50 -03 2024(62)
Fri 5 Jan 00:11:50 -03 2024(63)
Fri 5 Jan 00:11:50 -03 2024(64)
Fri 5 Jan 00:11:51 -03 2024(65)
Fri 5 Jan 00:11:51 -03 2024(66)
Fri 5 Jan 00:11:51 -03 2024(67)
Fri 5 Jan 00:11:51 -03 2024(68)
Fri 5 Jan 00:11:51 -03 2024(69)
Fri 5 Jan 00:11:51 -03 2024(70)
Fri 5 Jan 00:11:51 -03 2024(71)
Fri 5 Jan 00:11:51 -03 2024(72)
Fri 5 Jan 00:11:52 -03 2024(73)
Fri 5 Jan 00:11:52 -03 2024(74)
Fri 5 Jan 00:11:52 -03 2024(75)
Fri 5 Jan 00:11:52 -03 2024(76)
Fri 5 Jan 00:11:52 -03 2024(77)
Fri 5 Jan 00:11:52 -03 2024(78)
Fri 5 Jan 00:11:52 -03 2024(79)
Fri 5 Jan 00:11:52 -03 2024(80)
Fri 5 Jan 00:11:52 -03 2024(81)
Fri 5 Jan 00:11:53 -03 2024(82)
Fri 5 Jan 00:11:53 -03 2024(83)
Fri 5 Jan 00:11:53 -03 2024(84)
Fri 5 Jan 00:11:53 -03 2024(85)
Fri 5 Jan 00:11:53 -03 2024(86)
Fri 5 Jan 00:11:53 -03 2024(87)
Fri 5 Jan 00:11:53 -03 2024(88)
Fri 5 Jan 00:11:53 -03 2024(89)
Fri 5 Jan 00:11:54 -03 2024(90)
Fri 5 Jan 00:11:54 -03 2024(91)
Fri 5 Jan 00:11:54 -03 2024(92)
Fri 5 Jan 00:11:54 -03 2024(93)
Fri 5 Jan 00:11:54 -03 2024(94)
Fri 5 Jan 00:11:54 -03 2024(95)
Fri 5 Jan 00:11:54 -03 2024(96)
Fri 5 Jan 00:11:54 -03 2024(97)
Fri 5 Jan 00:11:54 -03 2024(98)
Fri 5 Jan 00:11:55 -03 2024(99)
Limitações do '!' operador
Geralmente não é eficaz “subtrair” comandos de ALL usando o '!' operador. Um usuário pode contornar isso trivialmente copiando o comando desejado para um nome diferente e executando-o. Por exemplo:
conta TODOS = TODOS, !SU, !SHELLS
Na verdade, não impede que Bill execute os comandos listados em SU ou SHELLS, pois ele pode simplesmente copiar esses comandos para um nome diferente ou usar um escape de shell de um editor ou outro programa. Portanto, este tipo de restrições deve ser considerado, na melhor das hipóteses, consultivo (e reforçado por políticas).
Em geral, se um usuário tiver sudo ALL, não há nada que o impeça de criar seu próprio programa que forneça um shell root (ou de fazer sua própria cópia de um shell), independentemente de qualquer '!' elementos na especificação do usuário.
O que faz o
ele pode simplesmente copiar esses comandos para um nome diferente
significar? É alias de comando ou algo mais?
Seguindo esta solução, quero conceder ao usuário daemona execução de /bin/date. Aqui está o que eu fiz:
encontre o usuário que apache2usa ao gerar:
# ps | grep httpd
252 root /usr/bin/httpd -k start
260 daemon /usr/bin/httpd -k start
262 daemon /usr/bin/httpd -k start
264 daemon /usr/bin/httpd -k start
467 root grep httpd
encontre o caminho certo para date:
# which date
/bin/date
usando visudoadicione as seguintes linhas:
Cmnd_Alias DATE=/bin/date
daemon ALL=NOPASSWD: DATE
reinício
teste os novos privilégios:
# sudo -u daemon date -s "2023-09-09 10:16:00"
date: can't set date: Operation not permitted
Sat Sep 9 10:16:00 UTC 2023
Há algo errado na minha sintaxe? Eu também tentei com:
ALL ALL=NOPASSWD: DATE
mas é a mesma coisa. É um ambiente Buildroot.
Não vou adicionar sudomeu ambiente Buildroot para RPi 3 B+, pois só preciso apache2atualizar a hora do sistema com date -s TIME.
Existe uma maneira de conceder essa permissão sem instalar e configurar sudo?