The security concern

Posted Nov 27, 2024 19:24 UTC (Wed) by carlosrodfern (subscriber, #166486)
In reply to: The security concern by roc
Parent article: The kernel's command-line commotion

I was referring to this:

> the kernel uses comm for its own purposes, and letting user space control it could help attackers to hide the actual executable being run. Copying argv[0] into comm will slow program start, he said. The right solution, according to Torvalds, is to use the file name stored in the directory entry ("dentry") associated with the file to be executed. That information is always present and is reliably under the kernel's control.

to post comments

The security concern

Posted Nov 27, 2024 20:22 UTC (Wed) by Wol (subscriber, #4433) [Link]

> That information is always present and is reliably under the kernel's control.

But it's "lying" to the user - it's not the executable they "asked for" ...

That said, I'm a bit surprised that systemd doesn't want to use the secure fexecv or whatever it was - the usual attitude is "do it right and if buggy code breaks, tough". Probably what they should do is implement it as an option, off by default to start with, then on, then only choice. If buggy code isn't fixed, it'll just have to deal with the consequences.

Cheers,
Wol

The security concern

Posted Nov 27, 2024 21:20 UTC (Wed) by roc (subscriber, #30627) [Link] (2 responses)

Yes, I think that's incorrect. Userspace can already control "comm" via PR_SET_NAME. Seems like Linus forgot about that... while ranting about what idiots other developers are.

The security concern

Posted Nov 27, 2024 21:35 UTC (Wed) by carlosrodfern (subscriber, #166486) [Link] (1 responses)

Perhaps he was referring to hiding processes the attacker didn't provide the binary for? For example, using some existing sftp, httpd, etc... program and hiding it with some `comm` looking like something else?

The security concern

Posted Nov 27, 2024 23:20 UTC (Wed) by roc (subscriber, #30627) [Link]

The attacker can create a hard link to get the same effect. Or they can use ptrace to inject a prctl call after exec.

There are some situations where a restricted attacker could manipulate argv[0] but not comm. But they're very narrow. Just ranting that "comm is THE TRUTH" is totally misleading.