Bernd Edlinger bernd.edlinger@hotmail.de writes:
On 3/2/20 4:57 PM, Eric W. Biederman wrote:
Bernd Edlinger bernd.edlinger@hotmail.de writes:
I tried this with s/EACCESS/EACCES/.
The test case in this patch is not fixed, but strace does not freeze, at least with my setup where it did freeze repeatable.
Thanks, That is what I was aiming at.
So we have one method we can pursue to fix this in practice.
That is obviously because it bypasses the cred_guard_mutex. But all other process that access this file still freeze, and cannot be interrupted except with kill -9.
However that smells like a denial of service, that this simple test case which can be executed by guest, creates a /proc/$pid/mem that freezes any process, even root, when it looks at it. I mean: "ln -s README /proc/$pid/mem" would be a nice bomb.
Yes. Your the test case in your patch a variant of the original problem.
I have been staring at this trying to understand the fundamentals of the original deeper problem.
The current scope of cred_guard_mutex in exec is because being ptraced causes suid exec to act differently. So we need to know early if we are ptraced.
It has a second use, that it prevents two threads entering execve, which would probably result in disaster.
Exec can fail with an error code up until de_thread. de_thread causes exec to fail with the error code -EAGAIN for the second thread to get into de_thread.
So no. The cred_guard_mutex is not needed for that case at all.
If that case did not exist we could reduce the scope of the cred_guard_mutex in exec to where your patch puts the cred_change_mutex.
I am starting to think reworking how we deal with ptrace and exec is the way to solve this problem.
I am 99% convinced that the fix is to move cred_guard_mutex down.
Then right after we take cred_guard_mutex do: if (ptraced) { use_original_creds(); }
And call it a day.
The details suck but I am 99% certain that would solve everyones problems, and not be too bad to audit either.
Eric