The design of core dump handling in Linux leaves much to be desired. Among its several flaws, the biggest is that it is a global setting, accessible only by the root user. A proper design would either allow it to be isolated via namespace, or delegated to a reaper/subreaper process (in an opt-in fashion for back-compat). There has been discussion of the former idea [0] and even a submitted patch [1], but it seems like it never went anywhere.
I'm having a hard time parsing this because I don't understand what "****" is supposed to mean in "**** API". Is it a "shit API" or "crap API", indicating that the API has problems? Is it a "damn API", which just indicates that the author of the quote is annoyed but there's nothing wrong with the API itself?
I assume it's meant to be the first meaning, that the API is bad? But the censorship honestly makes me a bit unclear.
I have sympathies for your view; but sometimes it's funnier to fake censor things. Though that's more of an artistic choice for comedy, than something to do in a technical piece.
If it was an article posting a censored version of a quote, that would be pretty normal. Some publications care about different audiences than the people they are quoting might.
Seems weird when you click through the link and it's the original social media post where the author censored himself. Just say "super poor" or something then.
>For example, the core-dump handler is launched by the kernel as a user-mode helper, meaning that it runs fully privileged in the root namespace.
Why is it not run as a dedicated core dump user?
>the core-dump socket to a helper can be intercepted
There have been several vulnerabilities related to this feature of passing core files to a container. I question if this feature is actually worth it considering one probably wants to have shared infrastructure for crash reporting anyways.
> Why is it not run as a dedicated core dump user?
You could imagine an API that sets the UID of this user, and the kernel could easily run the coredump handler as that user, but the kernel can't so easily automate the creation of a complicated namespace to contain that process (and the process can't do it itself because it could be exploited before it gets around to it). Look at the code in runc some time to see how complicated setting up a namespace has got.
> one probably wants to have shared infrastructure for crash reporting anyways
Not really on a single machine. coredumpctl actually works very well for solo development, I use it all the time.
You're thinking to complicated. You can configure the coredump helper in a way that the kernel presents it with the coredump on stdin. So you drop privileges and self-sandbox at startup and only then start reading the coredump from stdin.
IIUC Ubuntu and systemd however choose to dump the process manually for some reason and for that you need to have same permission as the target process.
This flurry of effort reminds me of that time in the '90s when I had the privilege of exploiting a core dump mishandling for real after a friend of mine forget the root password for his ISP's nameserver.
The design of core dump handling in Linux leaves much to be desired. Among its several flaws, the biggest is that it is a global setting, accessible only by the root user. A proper design would either allow it to be isolated via namespace, or delegated to a reaper/subreaper process (in an opt-in fashion for back-compat). There has been discussion of the former idea [0] and even a submitted patch [1], but it seems like it never went anywhere.
[0]: https://groups.google.com/g/linux.kernel/c/hJLP3XcKKSY
[1]: https://mail-archive.com/linux-kernel@vger.kernel.org/msg107...
I'm having a hard time parsing this because I don't understand what "****" is supposed to mean in "**** API". Is it a "shit API" or "crap API", indicating that the API has problems? Is it a "damn API", which just indicates that the author of the quote is annoyed but there's nothing wrong with the API itself?
I assume it's meant to be the first meaning, that the API is bad? But the censorship honestly makes me a bit unclear.
4 star API
I'm not sure why people do this censoring; who are they trying to get into good relations with?
Either swear, or don't.
I have sympathies for your view; but sometimes it's funnier to fake censor things. Though that's more of an artistic choice for comedy, than something to do in a technical piece.
Compare https://tvtropes.org/pmwiki/pmwiki.php/Main/CensoredForComed...
This is not that, though.
Yes, it's going off on a tangent and replying only to the 'Either swear, or don't.' bit.
[flagged]
I appreciate the sentiment, but Christian Brauner is German, by heritage and residency.
If it was an article posting a censored version of a quote, that would be pretty normal. Some publications care about different audiences than the people they are quoting might.
Seems weird when you click through the link and it's the original social media post where the author censored himself. Just say "super poor" or something then.
>For example, the core-dump handler is launched by the kernel as a user-mode helper, meaning that it runs fully privileged in the root namespace.
Why is it not run as a dedicated core dump user?
>the core-dump socket to a helper can be intercepted
There have been several vulnerabilities related to this feature of passing core files to a container. I question if this feature is actually worth it considering one probably wants to have shared infrastructure for crash reporting anyways.
> Why is it not run as a dedicated core dump user?
You could imagine an API that sets the UID of this user, and the kernel could easily run the coredump handler as that user, but the kernel can't so easily automate the creation of a complicated namespace to contain that process (and the process can't do it itself because it could be exploited before it gets around to it). Look at the code in runc some time to see how complicated setting up a namespace has got.
> one probably wants to have shared infrastructure for crash reporting anyways
Not really on a single machine. coredumpctl actually works very well for solo development, I use it all the time.
You're thinking to complicated. You can configure the coredump helper in a way that the kernel presents it with the coredump on stdin. So you drop privileges and self-sandbox at startup and only then start reading the coredump from stdin.
IIUC Ubuntu and systemd however choose to dump the process manually for some reason and for that you need to have same permission as the target process.
> start reading the coredump from stdin
How does that work with multi-TB mappings, as used by niche functionality like asan?
The coredump is sparse in elf format.
>You could imagine an API that sets the UID of this user
No, I think there should be a dedicated user. People will configure it in insecure ways if you let them.
>easily automate the creation of a complicated namespace to contain that process
Why is this being done. The core dump has already been created.
>coredumpctl actually works
Coredumpctl would still be possible without forwarding.
Wouldn't that user have to be able to access arbitrary kernel memory, meaning there's little point in it not being root?
Sharing a buffer or fd for the core file to a process running as a "core" user dies not require accessing arbitrary kernel memory.
Good to see CVEs driving design change I guess
This flurry of effort reminds me of that time in the '90s when I had the privilege of exploiting a core dump mishandling for real after a friend of mine forget the root password for his ISP's nameserver.