Hello Eric,
On 10/24/17 12:26 AM, Eric Hopper wrote:
> These two manual pages both imply that a setuid process can call
> prctl(PR_SET_DUMPABLE, 1, 0, 0, 0); to set this flag back to 1 and
> restore the ownership of /proc files back to being the real user id of
> the process. This is not exactly true.
>
> Empirical testing reveals that this flag is ignored in favor of the
> value in /proc/sys/fs/suid_dumpable if either the real group or user id
> fail to match the effective group or user id. You can use prctl to set
> it to 1, and then prctl(PR_GET_DUMPABLE, 0, 0, 0, 0); to fetch it, and
> it will report as '1', but the ownership of files in /proc/self will
> remain as root:root until the effective and real ids match.
>
> This should be mentioned in the manual as it prescribes a very specific
> sequence of events that must happen to restore the ownership of these
> files that the current manual does not make clear.
I believe that you've misapprehended things slightly. I think the
correct summary is this:
1. If the process "dumpable" attribute is not 1, the files in
/proc/PID are owned by root:root. If the dumpable attribute is 1,
then the ownership is <process-eUID>:<process-eGID>. (And in
a set-UID-root program, <process-eUID> is of course "root".)
2. As described in prctl(2), various process credential changes
may cause the value of the process's dumpable attribute to
be reset to the value in /proc/sys/fs/suid_dumpable (which
typically has the value 0).
So, if I understand the scenario you are describing correctly:
(a) We run a set-UID program. Consequently, the process's dumpable
flag is reset to the value in /proc/sys/fs/suid_dumpable
(probably 0) and consequently the ownership of the /proc/PID
files changes to root:root.
(b) [Hypothetically] the process uses prctl(2) to reset the
dumpable flag to 1. This causes the ownership of the
/proc/PID files to reset to <process-eUID>:<process-eGID>.
(c) The process drops its effective UID back to the same value as
the real UID, which brings us back to the same state as in (a).
(d) The process uses prctl(2) to reset the dumpable flag to 1.
This would again cause the ownership of the /proc/PID files
to reset to <process-eUID>:<process-eGID>.
Rule 1 above is I think quite clearly captured in proc(5):
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.
But people trip up over point (c), I think. The question is how
to better alert them, so that they don't trip up. As a step in
that direction, I added some text in proc(5):
Resetting the "dumpable" attribute to 1 reverts the owner‐
ship of the /proc/[pid]/* files to the process's effective
x UID and GID. Note, however, that if the effective UID or
x GID is subsequently modified, then the "dumpable" attribute
x may be reset, as described in prctl(2). Therefore, it may
x be desirable to reset the "dumpable" attribute after making
x any desired changes to the process's effective UID or GID.
If you have specific suggestions about other changes that could
be made to prevent the misunderstanding that you had, please
let me know.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
