最近有一个运行CentOS 6.7的专用服务器,我们运行了更新,注意到top只显示当前用户的进程。
[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~~~~~
我已经尝试在批处理模式下运行顶部,并使用“U”和“U”,并保持空白,并按[enter],没有运气。
我很确定我正在运行实际的顶端,绝对path启动没有影响。
$ 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
有关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
有任何想法吗?
一种可能性是/proc挂载了hidepid=1或者hidepid=2 。 这个挂载选项是在后来的Linux内核中添加的,并且在CentOS 5.9和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 (eg, 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).
另一种可能性(由海报发现并添加到这个答案作为参考信息)是grsecurity ,它具有隐藏其他用户的进程从非特权用户作为其文件系统强化的一部分function 。
为非特权用户隐藏其他用户的进程
虽然上游内核现在为/ proc提供了一个挂载选项来隐藏其他非特权用户的进程,但grsecurity通过默认隐藏这些信息,隐藏了内核在/ proc中提供的额外敏感信息源,并隐藏了专用networking,所有用户的相关信息。 networking信息不仅侵犯了系统上其他用户的隐私,而且在过去的TCP劫持攻击中也是有用的。
根据以下文章的信息,我已经确定了3个可能的解决scheme。
哪个状态grsecurty可以导致用户无法看到/proc/其他用户pids,并且OVH(我的托pipe公司)使用用Grsecurity编译的定制内核
$ uname -r 3.14.32-xxxx-grs-ipv6-64
可能的决议是:
对于我来说,教育其他pipe理员是安全第一的最佳select。 还是希望他们能告诉我们这样的事情。 谢谢你的帮助!