Perguntas[sudo](unix)

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:

1. 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
   

2. encontre o caminho certo para date:

   # which date
   /bin/date
   

3. usando visudoadicione as seguintes linhas:

   Cmnd_Alias DATE=/bin/date                                               
   daemon ALL=NOPASSWD: DATE
   

4. reinício

5. 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?

Flatpack está instalando software, certo?

Exemplo: minha distribuição (baseada em Ubuntu) instalou atualizações do navegador Brave e Chrome hoje, nenhuma senha foi necessária.

Não é necessário sudo, ou de outra forma, acesso de administrador para fazer alterações no sistema?