Wir haben vor Kurzem einen dedizierten Server mit CentOS 6.7 bekommen, Updates ausgeführt und festgestellt, dass oben nur Prozesse für den aktuellen Benutzer angezeigt werden.
[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
Wenn ich jedoch mit sudo ausführe, erhalte ich die normale Ausgabe, die ich erwarten würde
[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~~~~~
Ich habe versucht, top nicht im Batchmodus auszuführen und „u“ und „U“ zu verwenden, das Feld leer zu lassen und die [Eingabe]-Taste zu drücken, aber ohne Erfolg.
Ich bin ziemlich sicher, dass ich das tatsächliche Top verwende, der Start mit absolutem Pfad hatte keine Auswirkungen.
$ 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'
In /etc/ ist kein toprc vorhanden.
$ ls -a /etc | grep -c toprc
0
proc wird wie folgt gemountet
$ 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
Weitere Details zu 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
Irgendwelche Ideen?
Antwort1
Eine Möglichkeit ist /procdas Mounten mit hidepid=1oder hidepid=2. Diese Mount-Option wurde in späteren Linux-Kerneln hinzugefügt und irgendwann um CentOS 5.9 und 6.3 zurückportiert.
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).
Eine weitere Möglichkeit (vom Poster gefunden und dieser Antwort als Referenzinformation hinzugefügt) istgrsicherheitdas eine Funktion zum Verbergen der Prozesse anderer Benutzer vor nicht privilegierten Benutzern hat, als Teil seinerDateisystemhärtung.
Prozesse anderer Benutzer für nicht privilegierte Benutzer verbergen
Während der Upstream-Kernel jetzt eine Mount-Option für /proc bereitstellt, um die Prozesse anderer nicht privilegierter Benutzer zu verbergen, geht grsecurity noch einen Schritt weiter und verbirgt solche Informationen standardmäßig, weitere Quellen sensibler Informationen, die der Kernel in /proc bereitstellt, sowie private netzwerkbezogene Informationen aller Benutzer. Die Netzwerkinformationen stellen nicht nur eine Verletzung der Privatsphäre anderer Benutzer des Systems dar, sondern waren in der Vergangenheit auch für TCP-Hijacking-Angriffe nützlich.
Antwort2
Basierend auf den Informationen aus den folgenden Beiträgen habe ich drei mögliche Lösungen identifiziert.
- htop zeigt nur die Prozesse des Benutzers an, der es ausführt?unter Unix und Linux
- https://www.centos.org/forums/viewtopic.php?f=14&t=52563
In welchen Staaten kann Grsecurity dazu führen, dass Benutzer die PIDs anderer Benutzer nicht sehen können /proc/und dass OVH (mein Hosting-Unternehmen) einen benutzerdefinierten Kernel verwendet, der mit Grsecurity kompiliert wurde?
$ uname -r
3.14.32-xxxx-grs-ipv6-64
Mögliche Lösungen sind:
- grsecurity entfernen
- Bearbeiten Sie die Richtlinie, um eine solche Nutzung zuzulassen
- Stellen Sie sicher, dass die anderen Administratoren über die neuen Sicherheitsmaßnahmen informiert sind.
Für mich ist es die beste Option, die anderen Administratoren zu informieren, da Sicherheit an erster Stelle steht. Trotzdem wünschte ich mir, sie hätten uns über so etwas informiert. Vielen Dank für all Ihre Hilfe!
Antwort3
Ich mache das in mehreren Schritten und bin dabei als Root-Benutzer angemeldet.
So finden Sie alle angemeldeten Benutzer
last | grep 'logged'Überprüfen Sie die Aktivität bestimmter Benutzer
top -u username1usw.top -u username2