Tetsuo Handa wrote:
> Crispin Cowan wrote:
>
>> However, behavioral detection can generate false positives, so the
>> severe reactions of Enforce, or even Tetsuo's suggestion of replacing
>> the exec target with /bin/true, are quite arduous. In an interesting
>>
> As I said above, execve() is a spacial case that can be replaced in a safe
> and non-arduous way.
>
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.
This is wrong on 2 levels:
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.
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.
>> paper, Anil Somayaji proposed a tar-baby defense, where atypical syscall
>> patterns result in exponential slowdown of the system calls. The kernel
>> puts that process to sleep for 1 second, 2 seconds, 4 seconds .... etc.
>> until the behavior returns to normal. This is a great idea for a
>> defensive action if you don't know whether you have an attack or not.
>>
> Let the caller process sleep for a few seconds before returning error to the
> caller
> when the execve("/bin/sh") is request by /usr/sbin/smbd is not meddlesome
> because the administrator is sure that it is an attack
> and the administrator shall not complain about it
> and sleeping before returning error avoids CPU resource consumption.
>
Yes, that is the obvious implementation of the tar-baby.
I would strongly recommend using the tar-baby *instead* of the /bin/true
idea.
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.
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
