top está mostrando apenas os processos atuais do usuário

Question

Recentemente adquirimos um servidor dedicado rodando CentOS 6.7, fizemos atualizações e notamos que top só mostra processos para o usuário atual.

[myuser@server2 ~]$ top -b -n1 
top - 20:19:20 up 1 day, 10:09,  3 users,  load average: 0.80, 0.50, 0.41
Tasks:  11 total,   1 running,  10 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.2%us,  0.0%sy,  0.0%ni, 99.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  32880988k total, 26893324k used,  5987664k free,   140872k buffers
Swap:  1046520k total,        0k used,  1046520k free, 19532120k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND               
 1648 myuser  20   0 98.8m 1020  688 S  0.0  0.0   0:00.00 man                   
 1651 myuser  20   0  103m 1184 1016 S  0.0  0.0   0:00.00 sh                    
 1652 myuser  20   0  103m  684  500 S  0.0  0.0   0:00.00 sh                    
 1656 myuser  20   0  103m  912  752 S  0.0  0.0   0:00.07 less                  
 3363 myuser  20   0  100m 1708  700 S  0.0  0.0   0:00.04 sshd                  
 3364 myuser  20   0  105m 1916 1524 S  0.0  0.0   0:00.00 bash                  
 8337 myuser  20   0 14940 1096  880 R  0.0  0.0   0:00.00 top                   
30429 myuser  20   0  100m 1696  696 S  0.0  0.0   0:00.16 sshd                  
30430 myuser  20   0  105m 1924 1536 S  0.0  0.0   0:00.01 bash                  
31132 myuser  20   0  100m 1692  692 S  0.0  0.0   0:00.05 sshd                  
31133 myuser  20   0  105m 1928 1536 S  0.0  0.0   0:00.04 bash            

No entanto, quando executado com sudo, obtenho a saída normal que esperaria

[myuser@server2 ~]$ sudo top -bn1
top - 20:22:08 up 1 day, 10:12,  3 users,  load average: 0.36, 0.40, 0.39
Tasks: 166 total,   1 running, 165 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.2%us,  0.0%sy,  0.0%ni, 99.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  32880988k total, 26898188k used,  5982800k free,   141196k buffers
Swap:  1046520k total,        0k used,  1046520k free, 19532188k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND               
32705 otherusr  20   0 21.9g 5.8g  15m S 39.8 18.3  28:47.76 java                  
    1 root      20   0 19280 1524 1232 S  0.0  0.0   0:00.76 init                  
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd              
    3 root      20   0     0    0    0 S  0.0  0.0   0:00.40 ksoftirqd/0           
    5 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kworker/0:0H          
    6 root      20   0     0    0    0 S  0.0  0.0   0:03.20 kworker/u16:0  
~~~~~omitted~~~~~

Eu tentei executar top não no modo batch e usar "u" e "U" e deixar em branco e pressionar [enter], sem sorte.

Tenho certeza de que estou executando o top, o lançamento com caminho absoluto não teve impacto.

$ which top
/usr/bin/top
$ file /usr/bin/top
/usr/bin/top: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
$ alias
alias l.='ls -d .* --color=auto'
alias ll='ls -l --color=auto'
alias ls='ls --color=auto'
alias vi='vim'
alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'

Nenhum toprc está presente em /etc/

$ ls -a /etc | grep -c toprc
0

proc é montado da seguinte maneira

$ sudo cat /proc/mounts | grep proc
none /proc proc rw,relatime 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
$ sudo cat /etc/fstab | grep proc
proc        /proc   proc    defaults        0   0

Mais detalhes sobre Procs

[myuser@server2 ~]$ sudo -u otherusr ps -A
  PID TTY          TIME CMD
21921 pts/0    00:00:00 ps
32703 ?        00:00:00 screen
32705 pts/3    01:08:01 java
[myuser@server2 ~]$ sudo ls -l /proc/ | grep 32705
dr-xr-x---  7 otherusr root     0 Sep 23 19:27 32705
[myuser@server2 ~]$ sudo ls -l /proc/32705/ | grep stat
-r--------  1 otherusr root 0 Sep 23 21:54 mountstats
-r--r--r--  1 otherusr root 0 Sep 23 19:27 stat
-r--r--r--  1 otherusr root 0 Sep 23 19:27 statm
-r--r--r--  1 otherusr root 0 Sep 23 19:27 status
[myuser@server2 ~]$ ls /proc/ | egrep "[0-9]{1,9}";
17363
17364
26124
26125
3363
3364
[myuser@server2 ~]$ sudo -u otheruser ls /proc/ | egrep "[0-9]{1,9}"
26132
32703
32705
[myuser@server2 ~]$ umask
0002
[root@server2 ~]# umask
0022

Alguma ideia?

Answer 1

Uma possibilidade é /procmontada com hidepid=1ou hidepid=2. Esta opção de montagem foi adicionada nos últimos kernels do Linux e portada em algum momento por volta do CentOS 5.9 e 6.3.

Mount options
   The proc filesystem supports the following mount options:

   hidepid=n (since Linux 3.3)
          This option controls who can access the information in
          /proc/[pid] directories.  The argument, n, is one of the
          following values:

          0   Everybody may access all /proc/[pid] directories.  This is
              the traditional behavior, and the default if this mount
              option is not specified.

          1   Users may not access files and subdirectories inside any
              /proc/[pid] directories but their own (the /proc/[pid]
              directories themselves remain visible).  Sensitive files
              such as /proc/[pid]/cmdline and /proc/[pid]/status are now
              protected against other users.  This makes it impossible
              to learn whether any user is running a specific program
              (so long as the program doesn't otherwise reveal itself by
              its behavior).

          2   As for mode 1, but in addition the /proc/[pid] directories
              belonging to other users become invisible.  This means
              that /proc/[pid] entries can no longer be used to discover
              the PIDs on the system.  This doesn't hide the fact that a
              process with a specific PID value exists (it can be
              learned by other means, for example, by "kill -0 $PID"),
              but it hides a process's UID and GID, which could
              otherwise be learned by employing stat(2) on a /proc/[pid]
              directory.  This greatly complicates an attacker's task of
              gathering information about running processes (e.g.,
              discovering whether some daemon is running with elevated
              privileges, whether another user is running some sensitive
              program, whether other users are running any program at
              all, and so on).

Outra possibilidade (encontrada pelo autor da postagem e adicionada a esta resposta como informação de referência) ésegurançaque possui um recurso para ocultar processos de outros usuários de usuários sem privilégios como parte de seuendurecimento do sistema de arquivos.

Ocultar processos de outros usuários para usuários sem privilégios

Embora o kernel upstream agora forneça uma opção de montagem para /proc para ocultar processos de outros usuários sem privilégios, grsecurity vai além disso, ocultando tais informações por padrão, ocultando fontes adicionais de informações confidenciais fornecidas pelo kernel em /proc e ocultando redes privadas- informações relacionadas de todos os usuários. As informações de rede não são apenas uma violação da privacidade de outros usuários do sistema, mas também foram úteis no passado para ataques de sequestro de TCP.

Answer 2

Com base nas informações das postagens a seguir, identifiquei três possíveis resoluções.

• htop mostra apenas os processos do usuário que o está executando?em Unix e Linux
• https://www.centos.org/forums/viewtopic.php?f=14&t=52563

O que afirma que o grsecurty pode fazer com que os usuários não consigam ver os pids de outros usuários /proc/e que a OVH (minha empresa de hospedagem) usa um kernel personalizado compilado com Grsecurity

$ uname -r
3.14.32-xxxx-grs-ipv6-64

possíveis resoluções são:

1. remover grsecurity
2. editar a política para permitir tal uso
3. garantir que os outros administradores estejam cientes das novas medidas de segurança em vigor

Para mim, educar os outros administradores é a melhor opção, pois a segurança está em primeiro lugar. Ainda assim, gostaria que eles tivessem nos informado sobre algo assim. Obrigado por toda sua ajuda!

Answer 3

Eu faço isso em várias etapas estando logado como usuário root.

1. Para encontrar todos os usuários logadoslast | grep 'logged'

2. Verifique a atividade de um usuário específico por top -u username1e top -u username2etc.