Hello.
Thank you for your comment.
Crispin Cowan wrote:
> What is special about execve()? If the attacker can inject arbitrary
> shell code, they can do any kind of DoS attack, such as "while (1) {}"
> or "while (1) {system=("cat /var/log/messages >/dev/null");}"
Yes, shellcode that triggers "while (1) {}" is the worst code because
it consumes CPU resource but the system cannot know whether it is an attack or
not.
But many attackers's purpose is "Get /bin/sh of the target system to do
something bad"
rather than "Consume CPU resource of the target system to slowdown", and
the CPU resource consumption is a side effect caused by denial of
execve("/bin/sh") request.
So, I thought there is some meaning to do some additional actions to negate
this side effect.
Regarding MAC systems, the administrator tells the system what programs should
be executed.
For example, you won't allow /usr/sbin/smbd to execute /bin/sh
because you know /usr/sbin/smbd doesn't need to execute /bin/sh .
The MAC system can regard execution request of /bin/sh by /usr/sbin/smbd is an
attack
because the administrator told it to the system and the administrator shall not
complain about it.
> * Kill: kill the process if it violates policy
The "Kill" action is the simplest case.
My idea is that replace "execve("/bin/sh") requested by /usr/sbin/smbd"
by "execve("/bin/true") requested by /usr/sbin/smbd",
which will terminate the process soon like "Kill" action.
I have thought the idea of killing process that violated policy in the past,
but I found that it would be dangerous because at the location of policy
checking (i.e. in LSM hooks),
some spinlocks/semaphores may be held or some memories may be allocated.
So, I concluded that killing process that violated policy at the location of
policy checking
is not a safe behavior.
But regarding execve(), I thought I can safely replace /bin/sh by /bin/true or
something else
because it is similar to what binfmt_script does.
> We are also going to add management of rlimits to AppArmor profiles, so
> you can specify in policy the limits of disk, CPU, memory, etc. So in
> principle, you could combine rlimits on CPU with the Kill option to kill
> a runaway CPU hog. However, this would also kill processes that simply
> exceeded their CPU allocation, so use this judiciously.
Yes, just killing process based on CPU usage is a bad criteria.
> 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.
> 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.
-
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
