Hello.
> It is arduous to the confined program, because it expected the child
> program to run, and you made it not run, but then lied to the program
> and said that it did run.
server_process() {
while (1) {
do_startup();
do_something();
do_cleanup();
}
}
The administrator *knows* execve("/bin/sh") is unneeded for server_process().
Before the process loses its control at do_something(),
the process is *not* expecting /bin/sh to run.
> 1. It is bad to lie to the confined program. If it is not malicious,
> you are just breaking the program. If it is malicious, you are
> merely wounding the malicious program instead of killing it.
Thus, a process expecting /bin/sh to run at server_process() is already a
malicious process.
> 2. If you really want to lie to the confined program, then actually
> executing /bin/true is silly. Instead, don't run anything, and
> return any error code you want.
And I don't think it is a bad thing to lie to a malicious process
(execute /bin/true instead of /bin/sh and tell that /bin/sh is executed)
because the administrator *explicitly asks* the system
(through security policy configuration)
run /bin/true instead of /bin/sh for a malicious process.
> However, I still don't understand how you find yourself in the position
> of only half-way knowing whether you have a malicious process or not. In
> a MAC system (like TOMOYO, AppArmor, and SELinux) you don't have
> behavior information, you only know whether the process violated policy
> or not.
The administrator knows that
"execve("/bin/sh") is not needed by server_process() to operate properly" and
"requesting execve("/bin/sh") from server_process() is an insane thing,
which is caused by lost of its control".
MAC system is told information about behaviors needed for proper operation
by the administrator, and the system can regard
a process that requests behaviors unneeded for proper operation
as a malicious process.
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
