"core dump helper" runs always as root

"core dump helper" runs always as root

[Christian Perle]

Hi *

I recently played around with the /proc/sys/kernel/core_pattern file
(2.6.24.7 and 2.6.25) and found out that processes started by the
"|/path/to/executable" notation always run as root, even if the
segfaulting process runs as non-root.

Is there a reason for this behaviour? If not, i would suggest starting the
process which receives the core dump on stdin as the same UID of the
segfaulting process.

With the current behaviour you can do funny things:

(as root)
# echo "|/bin/chmod 4755 /bin/ash" > /proc/sys/kernel/core_pattern

(as user)
$ sleep 2 & kill -11 $!

Of course this is *not* a local root exploit because you need to be root
to write to the proc entry, but IMHO running the "core dump helper" (is
there a better name for this?) always as root is potentially harmful.


Greetings,
  Chris
-- 
Christian Perle                                    chris AT linuxinfotag.de
010111                                              http://chris.silmor.de/
101010                          LinuxGuitarKitesBicyclesBeerPizzaRaytracing

Re: "core dump helper" runs always as root

[Chris Snook]

Christian Perle wrote:
> Hi *
> 
> I recently played around with the /proc/sys/kernel/core_pattern file
> (2.6.24.7 and 2.6.25) and found out that processes started by the
> "|/path/to/executable" notation always run as root, even if the
> segfaulting process runs as non-root.
> 
> Is there a reason for this behaviour? If not, i would suggest starting the
> process which receives the core dump on stdin as the same UID of the
> segfaulting process.
> 
> With the current behaviour you can do funny things:
> 
> (as root)
> # echo "|/bin/chmod 4755 /bin/ash" > /proc/sys/kernel/core_pattern
> 
> (as user)
> $ sleep 2 & kill -11 $!
> 
> Of course this is *not* a local root exploit because you need to be root
> to write to the proc entry, but IMHO running the "core dump helper" (is
> there a better name for this?) always as root is potentially harmful.
> 
> 
> Greetings,
>   Chris

If we run the usermode helper with the privileges of the dying process, what do 
we do about rlimit enforcement?  They don't have a PAM environment, so either 
they get the default rlimits, or we have to make them inherit their limits from 
the dying process.  This is very problematic if the process died due to 
exceeding an rlimit.

Userspace is the best place to resolve complex policy issues.  If it makes you 
uncomfortable having your coredump helper run as root, you can implement 
privilege separation in it, and any arbitrary code you see fit to resolve the 
rlimit dilemma.

Personally, I would not be opposed to honoring setuid permissions for usermode 
helpers, as this maintains the separation of policy and mechanism, and leaves no 
room for ambiguity about the intent of the system administrator.

-- Chris

Re: "core dump helper" runs always as root

[Reto Buerki]

> If we run the usermode helper with the privileges of the dying process, what do 
> we do about rlimit enforcement?  They don't have a PAM environment, so either 
> they get the default rlimits, or we have to make them inherit their limits from 
> the dying process.  This is very problematic if the process died due to 
> exceeding an rlimit.

I'm not sure if I understand your objection correctly, but I thought
RLIMIT_CORE is ignored when using piped syntax with core_pattern.

At least this is how I interpret the code and the corresponding comment
in do_coredump() (fs/exec.c). The comment explicitly states that there's
no need to check RLIMIT_CORE value because file size limits and
permissions apply as they do with any other process.

There are also no further rlimit checks in usermode helper functions, at
least I could not find any ...

- reto