Centos – Owner can’t read /proc/$pid/io

From what I can tell the smoking gun is this command:

lsattr virus.exe 
lsattr: Operation not permitted While reading flags on virus.exe

This is basically saying that the underlying file system is not EXT2/3/4. Given that the normal permissions can sometimes not be a factor and file attributes may well not be supported either.

Example

I have an NFS mounted share as follows.

$ pwd
/home/sam

If I run lsattr against it:

$ lsattr /home/sam/ 2>&1 | head -3
lsattr: Inappropriate ioctl for device While reading flags on /home/sam/dead.letter
lsattr: Inappropriate ioctl for device While reading flags on /home/sam/bashrc
lsattr: Inappropriate ioctl for device While reading flags on /home/sam/phillip_phillips_home.mp3

My guess is that the filesystem is what's denying you access to it.

Technically there are some ways to allow it. I'm not sure they will be practical or useful in most cases.

You could modify the program you are interested in to call prctl(PR_SET_DUMPABLE, 1, ...). This would be dangerous if the target program is using a capability to access more sensitive information, e.g. password files. This danger cannot apply in your case. Because you are only using the capability CAP_SYS_RESOURCE, which does not allow the program to access any more information than it would otherwise.

Problem 1: We see you are denied access to the directory /proc/[pid]/fd/, because it is only accessible by the owner (r-x------), and the owner is root. This is because:

http://man7.org/linux/man-pages/man5/proc.5.html

The files inside each /proc/[pid] directory are normally owned by the effective user and effective group ID of the process. However, as a security measure, the ownership is made root:root if the process's "dumpable" attribute is set to a value other than 1.

[...]

The process's "dumpable" attribute may change for the following reasons:

• The attribute was explicitly set via the prctl(2) PR_SET_DUMPABLE operation.

• The attribute was reset to the value in the file /proc/sys/fs/suid_dumpable (described below), for the reasons described in prctl(2).

http://man7.org/linux/man-pages/man2/prctl.2.html

PR_SET_DUMPABLE (since Linux 2.3.20)

Set the state of the "dumpable" flag, which determines whether core dumps are produced for the calling process upon delivery of a signal whose default behavior is to produce a core dump.

[...] (See also the description of /proc/sys/fs/ suid_dumpable in proc(5).)

Normally, this flag is set to 1. However, it is reset to the current value contained in the file /proc/sys/fs/suid_dumpable (which by default has the value 0), in the following circumstances:

• The process's effective user or group ID is changed.

• The process's filesystem user or group ID is changed (see credentials(7)).

• The process executes (execve(2)) a set-user-ID or set- group-ID program, resulting in a change of either the effective user ID or the effective group ID.

• The process executes (execve(2)) a program that has file capabilities (see capabilities(7)), but only if the permitted capabilities gained exceed those already permitted for the process.

Problem 2: Simply being able to list /proc/[pid]/fd/ is not very useful on it's own. I expect you at least want to see what the open files refer to.

After the permissions on this directory, and the permissions on the files within it, the proc man page says there is another security check involving this "dumpable" flag:

Permission to dereference or read (readlink(2)) the symbolic links in this directory is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see ptrace(2).

http://man7.org/linux/man-pages/man2/ptrace.2.html

Deny access if the target process "dumpable" attribute has a value other than 1 (SUID_DUMP_USER; see the discussion of PR_SET_DUMPABLE in prctl(2)), and the caller does not have the CAP_SYS_PTRACE capability in the user namespace of the target process.

So another way to bypass problem 2 is if you had the capability CAP_SYS_PTRACE. Note that CAP_SYS_PTRACE would allow you to control any other process. It's arguable whether this would be any less powerful than actually being the root user.

You would also need to bypass problem 1, the file permissions. This could be done if you had the capability CAP_DAC_READ_SEARCH (or CAP_DAC_OVERRIDE).