container: bubblewrap runner: use --new-session to mitigate CVE-2017-5226

[kaniini]

Without it, it is possible to escape the sandbox via TIOCSTI ioctls on the session PTY.

Related: containers/bubblewrap#555
Related: containers/bubblewrap#142
Related: https://news.ycombinator.com/item?id=30825088

[hartwork]

Hi, good move!

I see that commit 07cd62e is not part of release 0.2.0 and that 0.2.0 is packaged in Arch Linux and derivatives. My vote for considering a new release and a CVE for this. It only takes filling this form: https://cveform.mitre.org/ .

[kaniini]

Our invocation of bubblewrap does not pass through the terminal file descriptor, so we do not believe there is any practical exposure to CVE-2017-5226. We would be likely to dispute any CVE filed for that reason.

[hartwork]

To be sure I understand: if that is true, why would you want to pass --new-session then? How is exec.Command not passing the controlling terminal to bwrap? Please help me understand what I may be missing.

[kaniini]

To be sure I understand: if that is true, why would you want to pass --new-session then?

We do want the setsid effects for other reasons. And it is better to have it anyway, just in case we begin to use PTYs in the future instead of pipes.

How is exec.Command not passing the controlling terminal to bwrap? Please help me understand what I may be missing.

exec.Command just creates an execution object. The actual execution happens here, after stdio redirection is set up to use pipes: https://github.com/chainguard-dev/melange/blob/main/pkg/container/runner.go#L49

[hartwork]

We do want the setsid effects for other reasons.

Could you elaborate?

The title "to mitigate CVE-2017-5226" communicates a different picture. I'm confused.