Comment 1 for bug 1839420

Sorry for the delay, I'm on vacation this week and so have very limited time to catch up on bug reports.

For the symlink issue, we should have apport do:
 - chdir(/proc/PID/cwd)
 - chroot(/proc/PID/root)

This will avoid any potential symlink attacks by preventing leaving the root of the container.

The other part of the issue is a tad trickier. Thinking about it, the real issue is if you have a world-executable setuid binary as that would then allow dumping the process. If the binary is owned by a user mapped in the user namespace, then it doesn't matter as you don't actually need its setuid bit and can just trace it whichever way you want.

My solution for this issue would be to check whether the executable which spawned the crashed process is owned by a uid/gid that's part of the container's map. If it is, then there is no security concern, if it isn't, then we shouldn't forward.

So to recap, the changes to apport would be:
 - Check that uid of TASK_EXE is in TASK_SUBUID, if not, log and exit
 - Check that gid of TASK_EXE is in TASK_SUBGID, if not, log and exit
 - chdir(TASK_CWD)
 - chroot(TASK_ROOT)
 - Attempt connect, if not preset/broken symlink, log and exit

It's worth noting that we are specifically NOT attaching to the namespaces of the process here as we don't want to make the host apport visible inside the container as this would pose a further security risk.

Is there an angle of this that I missed which the above changes wouldn't protect against?

If you think those changes would take care of this, I can write a patch for apport tonight, do basic regression testing for the cases that I care about and then let you do more review and landing of this.