[grsec] Problem in linux-2.4.31-grsec

[Heiko Hund]

Hi,

I was playing with the current grsec for 2.4 kernels and I think I found 
a bug in the patched bad_signal() function in kernel/signal.c. It's the 
second hunk of the signal.c patch. 

There, an additional call to gr_handle_signal() is added. In 
gr_handle_signal the function gr_pid_is_chrooted() is called in the 
'else if' branch. AFAIK gr_pid_is_chrooted checks if a process from 
within a chroot tries to send a signal to another process not in the 
same chroot. EPERM is returned if this is the case.

There is a problem in this codepath. If a process (P) from outside a 
chroot calls sleep(3), P is scheduled away and a SIGALRM is sent to P 
by the kernel after the timeout occured. If the timer softirq 
interrupts a process from within the chroot, the signal is not sent and 
the process sleeping will never wake up. This is done because then 
proc_is_chrooted(current) == 1 and have_same_root(current, P) == 0.

I was experiencing the strange behaviour when using iostat(1) and dug 
until this point. My custom debug messages I put into gr_pid_is_chrooted 
shows the problem:

iostat[1486]: 
  signal: 14 
  grsec_enable_chroot_findtask: 1, 
  in_softirq(): 1,
  current: 0xf7538000, 
  current->fs: 0xc1c11be0, 
  proc_is_chrooted(current): 1, 
  p: 0xf6586000, 
  p->state: 1, 
  p->fs: 0xf6cafa60, 
  have_same_root(current, p): 0, 
    current->fs->root->d_inode->i_dev: 18439, 
    p->fs->root->d_inode->i_dev: 18433, 
    current->fs->root->d_inode->i_ino: 2, 
    p->fs->root->d_inode->i_ino: 2

Have I overseen something obvious? If not I'd suggest a SI_FROMUSER 
check or similar somewhere in gr_handle_signal(). Let me know what you 
think.

Regards
Heiko
-- 
Master of Science (CS)   Unix Systementwicklung
fon +49 721 91374 636    Schlund + Partner AG
fax +49 721 91374 219    Brauerstraße 48
http://learn.to/quote    76135 Karlsruhe

Rennende Zombies!? Was soll das denn?  [George A. Romero]