Tetsuo Handa wrote:
>> 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.
>
This reasoning makes no sense. If you are *sure* that it is a malicious
process, then either kill it, or block its access. Why is it necessary
to screw around with letting it exec something other than what it asked
for, when you could do something much stronger if you are *sure*?
>> 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"
Does the administrator know that? What if the server process wants to
run a shell script?
> 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.
>
All these particulars don't matter. The bottom line is that an LSM can
find itself with an access request and 3 possible states:
* We are sure that this is a benign access request
o so allow it
* We are sure that this is a malicious access request
o so either kill it or block it
* We are unsure; it might be malicious, or it might not
o do something interesting, such as the tar-baby defense
I see no room for substituting /bin/true for the original exec request.
It has all of the negative consequences of just blocking the exec, and
fewer advantages.
Perhaps I'm missing something, but I haven't seen it articulated so far.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor
-
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
