Don't setenv in multi-threaded code on glibc

Re:Don't setenv in multi-threaded code on glibc by cesarb on Tuesday January 31, 2017 @01:42PM (#13533753)

> Only if we define "trusted" to include "known to be bug free" in e.g. it's truncation or bounding of output over the pipe to the child. I argue that, in theory, this is impossible to know, and thus that it this level of trust is impossible, and thus that this is not an example of a potential safe use of gets.

"In the security engineering subspecialty of computer science, a trusted system is a system that is relied upon to a specified extent to enforce a specified security policy. As such, a trusted system is one whose failure may break a specified security policy." -- https://en.wikipedia.org/wiki/Trusted_system

That's the definition of "trusted" I'm using.

> This is also insufficient - one must also prevent nonstandard invocations of the child process.

I'm thinking of pure fork(), not fork+exec. That is, the child process is the same executable image, so the only way to invoke the child process in a nonstandard way would be through a debugger. And that is why the child process can trust the parent process in my example: they're the same process until the fork().

(As I said, it's a really contrived scenario. In more realistic scenarios, gets() is unsafe.)

[ Parent | on HN ]

Re:Don't setenv in multi-threaded code on glibc by comex on Wednesday February 01, 2017 @03:16AM (#13539220)

Well, on Linux, there are various hardening mechanisms that lock down ptrace, as well as things like /proc/PID/mem/, but I don't think the same restrictions apply to grabbing fds from other processes via /proc/PID/fd/. So in theory a process running as the same user (but which can't just debug your process due to hardening) could steal your pipe and exploit your program... probably not a terribly realistic threat, but a contrived objection to a contrived scenario :)

[ Parent | on HN ]