A problem with prctl(2) and proc(5)

A problem with prctl(2) and proc(5)

[Eric Hopper]

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

Re: A problem with prctl(2) and proc(5)

[Eric Hopper]

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

Re: A problem with prctl(2) and proc(5)

[Michael Kerrisk (man-pages)]

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/

Re: A problem with prctl(2) and proc(5)

[Michael Kerrisk (man-pages)]

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/