Disabling SECCOMP with a kernel R/W is quite fun! You need to clear the TIF_SECCOMP flag first in thread_info, then the task->seccomp.filter, and finally task->seccomp.mode. Any other combination leads to kernel panics
The last two I can understand: there is intentional "fail closed" logic in seccomp in those cases. Losing TIF_SECCOMP, though, I'd expect would instantly bypass seccomp. What actually goes wrong if only that is changed? (Also, I assume you unset NNP too?)
-
-
If TIF_SECCOMP is set, it reaches the secure_computing() function which hits this https://github.com/torvalds/linux/blob/5ad18b2e60b75c7297a998dea702451d33a052ed/kernel/seccomp.c#L939 … So the mode needs to be non zero if that flag is set. It doesn't look like NNP was set!
-
Ah, so some privileged process manager (systems?) set seccomp. How are you reaching __secure_computing() if TIF_SECCOMP is unset? https://elixir.bootlin.com/linux/latest/source/arch/x86/entry/common.c#L92 … Got a flaw in ptrace?
- Još 1 odgovor
Novi razgovor -
-
-
You are right but I also need to stop copying on fork()
Hvala. Twitter će to iskoristiti za poboljšanje vaše vremenske crte. PoništiPoništi
-
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.