
最近有一台運行 CentOS 6.7 的專用伺服器,我們運行了更新並注意到頂部僅顯示當前用戶的進程。
[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
但是,當使用 sudo 運行時,我得到了我期望的正常輸出
[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~~~~~
我嘗試過不在批次模式下運行 top 並使用“u”和“U”並將其留空並按 [enter],但沒有成功。
我很確定我正在運行實際的頂部,使用絕對路徑啟動沒有影響。
$ 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'
/etc/ 中不存在 toprc
$ ls -a /etc | grep -c toprc
0
proc掛載如下
$ 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
有關過程的更多詳細信息
[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
有任何想法嗎?
答案1
一種可能性是使用或 來/proc
安裝。此掛載選項已添加到後來的 Linux 核心中,並在 CentOS 5.9 和 6.3 周圍的某個時間向後移植。 hidepid=1
hidepid=2
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).
另一種可能性(由發布者發現並添加到此答案作為參考資訊)是網路安全它具有向非特權用戶隱藏其他用戶進程的功能,作為其一部分文件系統強化。
為非特權使用者隱藏其他使用者的進程
雖然上游核心現在為/proc 提供了一個掛載選項來隱藏其他非特權用戶的進程,但grsecurity 超越了這一點,默認情況下隱藏此類信息,隱藏/proc 中內核提供的其他敏感信息源,並隱藏專用網路 -所有使用者的相關資訊。網路資訊不僅侵犯了系統上其他使用者的隱私,而且在過去對於 TCP 劫持攻擊也很有用。
答案2
根據以下帖子中的信息,我確定了 3 種可能的解決方案。
其中指出 grsecurety 可能會導致用戶無法看到其他用戶的 pid,/proc/
並且 OVH(我的託管公司)使用使用 Grsecurity 編譯的自訂內核
$ uname -r
3.14.32-xxxx-grs-ipv6-64
可能的解決方案是:
- 刪除安全性
- 編輯策略以允許此類使用
- 確保其他管理員了解新的安全措施
對我來說,教育其他管理員是最好的選擇,因為安全是第一位的。不過還是有點希望他們能告訴我們這樣的事情。謝謝你的幫忙!
答案3
我以 root 使用者身分登錄,分多個步驟執行此操作。
尋找所有已登入的用戶
last | grep 'logged'
檢查特定使用者的活動
top -u username1
等top -u username2
。