grsecurity forums

Dear Forum,

I am using plesk and a gresecurity patched kernel on my root. Everythings seems to work fine, beside the fact that I got an looping process which can´t be termed or killed. The Parallels isn´t able to help and seems pretty arrogant at some point. I really hope you guys can help my finding out which grsecurty feature is causing this problem and how can I manage this a possible maximum of security.

System: Debian 64bit
Looping process: sw-engine-cgi (child process of cp-sw-serverd)
Log-entry which might correspond: Can only kill processes with the same parent as mine (cp-sw-serverd error log)

I need a lot more information -- what's the application that can't be killed? What's an strace of the application look like prior to this point? What version of grsecurity? What version of Linux?

-Brad

Hi Brad,

first of all thanks for your reply. I corrected my post a bit to spend a bit more information at the thread start. So its a 64-bit Debian system with static grsecurity kernel. I am running a full set root server with PLESK Control Panel. The process cp-sw-serverd is the deamon which runs as the user cp-sw-serverd. The server load problem is caused by a child process called sw-engine-cgi which runs as user psaadm. So the thread tree look like this:

sw-engine-cgi
user: psaadm

cp-sw-serverd
user: cp-sw-serverd

-cp-sw-serverd
|-sw-engine-cgi
||-sw-engine-cgi
||-sw-engine-cgi
|-sw-engine-cgi
||-sw-engine-cgi
||-sw-engine-cgi

Furthermore I have to say, I am getting nearly no help from Parallels, so I am speculating somewhat now:

sad, but the only error log I got from PLESK is: "Can only kill processes with the same parent as mine" in the error.log of cp-sw-serverd. So it seems that gresecurity kernel is preventing any process from being managed by a other to prevent this process overload. I am not sure which process is managing sw-engine-cgi, its just speculation.

http://kb.parallels.com/en/112543

At a certain point of time sw-cp-engine loses control over sw-engine-cgi processes and it does not kill them when it stops.
After a restart sw-cp-server raises a new bunch of sw-engine-cgi processes and all engine processes keep running.

Hi,

I now disabled all PAX-Feaures via paxctl for all 3 bins sw-engine-cgi, sw-cp-serverd, and sw-engine. Maybe it some of PAX features and not grsecurty itself which prevent the other process to kill the other process.

HiddenUser wrote:I now disabled all PAX-Feaures via paxctl for all 3 bins sw-engine-cgi, sw-cp-serverd, and sw-engine.

and does that allow plesk to work properly?

Maybe it some of PAX features and not grsecurty itself which prevent the other process to kill the other process.

PaX doesn't play with signals/processes, so i highly doubt that's the real reason . as spender said, looking at the strace for the looping process (and/or some information via gdb) would be a much better first step than random guessing.

Hi,

the disabling of the pax feature didn´t help, the unneeded process are still left. Sorry but how do I use strace correct, I just getting a bunch information only for the moment I excute strace, and should I run in in the hardened kernel or a vanilla ones ? I furthermore found this: https://www.atomicorp.com/wiki/index.ph ... _ptrace_of

I currently recompiling the kernel to use sysctl so I can easyly test different features.

HiddenUser wrote:Sorry but how do I use strace correct, I just getting a bunch information only for the moment I excute strace,

strace -f -ff -o <logfile> -p <pid> will log into <logfile>.<pid>. you can also try attaching with gdb and issue the following commands there: bt, x/8i $pc, info reg.

and should I run in in the hardened kernel or a vanilla ones ?

wherever you can reproduce the problem .

OK. I logged it for the while the only entry, which reoccur is:

fcntl(0, F_GETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0, pid=3906}) = 0
wait4(-1, 0x3ffffffc34c, WNOHANG, NULL) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, = 0
nanosleep({1, 0}, 0x3ffffffbfa0) = 0

So after I started sw-engine-cgi there are 4 processes as child of sw-cp-serverd:

-sw-cp-serverd
|- sw-engine-cgi
||-sw-engine-cgi
||-sw-engine-cgi
||-sw-engine-cgi

after a period of time, when the PLESK pannel idles those processes should be terminated, as they do on the vanilla kernel. But on the gresecurity ehanced kernel I got a new unit spawned:

-sw-cp-serverd
|- sw-engine-cgi
||-sw-engine-cgi
||-sw-engine-cgi
||-sw-engine-cgi
|- sw-engine-cgi
||-sw-engine-cgi
||-sw-engine-cgi
||-sw-engine-cgi

So for me it seems that as an result of that the first block couldn´t be terminated

Can you disable CONFIG_GRKERNSEC_HARDEN_PTRACE? Or just disable the option via sysctl? Last time I checked, sw-engine-cgi needed a binary patch to remove its useless anti-debugging feature for it to work properly.

-Brad

Hi Brad,

I just checked it, and ptrace is not enabled. But I compiled the kernel without sysctl, so I don´t have the ability to enabled or disable it. So this feature can´t be the problem. I tried to compile a new one with sysctl but this compiling stops at fs/proc/base.c: In function proc_pid_readdir. I didn´t had the mental power to open a new workplace at this point, especially because I am so angry on parallels. I mean I am asking for a debug mode for the processes and the only answer I get was where I can find the log files of plesk. Thats a joke.

I also monitored sw-cp-serverd and I had this entry there, so the parent is at least starting the process:

execve("/usr/bin/sw-engine-cgi", ["/usr/bin/sw-engine-cgi", "-c", "/opt/psa/admin/conf/php.ini", "-d", "auto_prepend_file=auth.php3", "-u", "psaadm"], [/* 3 vars */]) = 0

Is the process that is supposed to do the killing inside a chroot perhaps? Try disabling CONFIG_GRKERNSEC_CHROOT_FINDTASK.

-Brad

Hi,

maybe you can help me with a problem I got when compiling the new kernel. I know that I fixed that 2 years ago, but I can´t remember how:

Code: Select all

  CC      fs/proc/base.o
fs/proc/base.c: In function ‘proc_pid_readdir’:
fs/proc/base.c:2958: error: ‘__filldir’ undeclared (first use in this function)
fs/proc/base.c:2958: error: (Each undeclared identifier is reported only once
fs/proc/base.c:2958: error: for each function it appears in.)
make[3]: *** [fs/proc/base.o] Error 1
make[2]: *** [fs/proc] Error 2
make[1]: *** [fs] Error 2
make[1]: Leaving directory `/usr/src/linux-source-2.6.x'

Which grsecurity patch is this?

-Brad

Yes, this happens when trying to compile the kernel. Its the debian internal ones, because I am using the debian sources also: grsecurity-2.1.14-2.6.32.13-201005151340.patch. I know that it is normally suggested to use the vanilla kernel sources.

That's an incredibly old patch. We only support the latest versions, as your problem is likely already resolved (certainly that compile error is).

-Brad