Hello.
> 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*?
If I kill the hijacked process, I can't get information from the process.
For example, I can get environment variable information using something like
----- Logging program -----
#! /bin/sh
echo "DOMAIN=" $1
shift
echo "You don't have permission to call ""$@"
env
exit 1
----- Logging program -----
and if " touch /etc/f* " is denied because the security policy doesn't allow
execution of /usr/bin/touch ,
I can get the following information of process.
----- Output from logging program -----
DOMAIN= <kernel> /sbin/getty /bin/login /bin/bash
You don't have permission to call /usr/bin/touch /etc/fdmount.conf /etc/fonts
/etc/fstab /etc/fstab~
HZ=100
TERM=linux
SHELL=/bin/bash
HUSHLOGIN=FALSE
USER=root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/root/ccstools
MAIL=/var/mail/root
PWD=/root
LANG=C
HOME=/root
SHLVL=2
LANGUAGE=ja_JP:ja:en_GB:en
LOGNAME=root
_=/usr/bin/env
----- Output from logging program -----
The above program is just an example.
You can just kill the process using the above program if you wish.
If I got remote IP address from hijacked server process, I can ban that IP
address.
Executing other program that is not asked for is just a trigger.
You can use the trigger for either no-operation or defense against attackers.
> > 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?
Because the administrator can see the source code of program.
If the server process needs to run a shell script,
the administrator will give execute permission of /bin/sh
and this execute-something-else feature won't be triggered.
The administrator can't use this execute-something-else feature
if the process runs arbitrary command.
> 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.
I tested that I can stop CPU consumption caused by Samba's trans2open exploit.
If I utilize the trigger (i.e. execute something other than /bin/true ),
I can do more defense action.
This is an advantage that can't be obtained by just killing the 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
