* A problem with prctl(2) and proc(5)
@ 2017-10-23 22:26 Eric Hopper
[not found] ` <CAJWcbJEJDZS34g8v3dG-RAe=W0T-9ti_LUQ=GM9LJiEcetVphA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-04-21 12:29 ` Michael Kerrisk (man-pages)
0 siblings, 2 replies; 4+ messages in thread
From: Eric Hopper @ 2017-10-23 22:26 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w; +Cc: linux-man-u79uwXL29TY76Z2rM5mHXA
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.
Thank you,
--
Eric Hopper -- http://www.omnifarious.org/~hopper/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: A problem with prctl(2) and proc(5)
[not found] ` <CAJWcbJEJDZS34g8v3dG-RAe=W0T-9ti_LUQ=GM9LJiEcetVphA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-10-23 22:47 ` Eric Hopper
2020-04-21 11:13 ` Michael Kerrisk (man-pages)
0 siblings, 1 reply; 4+ messages in thread
From: Eric Hopper @ 2017-10-23 22:47 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w; +Cc: linux-man-u79uwXL29TY76Z2rM5mHXA
Also... execve(2) should make a passing mention of the DUMPABLE flag
and point at the prctl documentation where it talks about set-user-ID
processes. That would've greatly shortened my search for the answer I
needed.
On Mon, Oct 23, 2017 at 3:26 PM, Eric Hopper <hopper-mHNs42olblhbd4swqxETsg@public.gmane.org> 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.
>
> Thank you,
> --
> Eric Hopper -- http://www.omnifarious.org/~hopper/
--
Eric Hopper -- http://www.omnifarious.org/~hopper/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: A problem with prctl(2) and proc(5)
2017-10-23 22:47 ` Eric Hopper
@ 2020-04-21 11:13 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 4+ messages in thread
From: Michael Kerrisk (man-pages) @ 2020-04-21 11:13 UTC (permalink / raw)
To: Eric Hopper; +Cc: linux-man
Hello Eric,
On Tue, 24 Oct 2017 at 00:47, Eric Hopper <hopper@omnifarious.org> wrote:
>
> Also... execve(2) should make a passing mention of the DUMPABLE flag
> and point at the prctl documentation where it talks about set-user-ID
> processes. That would've greatly shortened my search for the answer I
> needed.
I added some sentences to the execve(2) page, so that tehre is now a
piece that reads:
* The process's "dumpable" attribute is set to the value 1,
unless a set-user-ID program, a set-group-ID program, or a pro‐
gram with capabilities is being executed, in which case the
dumpable flag may instead be reset to the value in
/proc/sys/fs/suid_dumpable, in the circumstances described
under PR_SET_DUMPABLE in prctl(2). Note that changes to the
"dumpable" attribute may cause ownership of files in the
process's /proc/[pid] directory to change to root:root, as
described in proc(5).
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: A problem with prctl(2) and proc(5)
2017-10-23 22:26 A problem with prctl(2) and proc(5) Eric Hopper
[not found] ` <CAJWcbJEJDZS34g8v3dG-RAe=W0T-9ti_LUQ=GM9LJiEcetVphA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2020-04-21 12:29 ` Michael Kerrisk (man-pages)
1 sibling, 0 replies; 4+ messages in thread
From: Michael Kerrisk (man-pages) @ 2020-04-21 12:29 UTC (permalink / raw)
To: Eric Hopper; +Cc: mtk.manpages, linux-man
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/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-04-21 12:29 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-23 22:26 A problem with prctl(2) and proc(5) Eric Hopper
[not found] ` <CAJWcbJEJDZS34g8v3dG-RAe=W0T-9ti_LUQ=GM9LJiEcetVphA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-10-23 22:47 ` Eric Hopper
2020-04-21 11:13 ` Michael Kerrisk (man-pages)
2020-04-21 12:29 ` Michael Kerrisk (man-pages)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).