weird ACL problem (grsec 1.9.11)

[joschi]

hello,

i've got (among others) the following ACL in use:
(debian stable/unstable mix, 2.4.21, grsec 1.9.11)

/usr/lib/Antivir/antivir o {
/usr/lib/Antivir rwx
/
/dev
/dev/random r
/dev/urandom r
/dev/input rw
/dev/psaux rw
/dev/tty0 rw
/dev/tty1 rw
/dev/tty2 rw
/dev/tty3 rw
/dev/tty4 rw
/dev/tty5 rw
/dev/tty6 rw
/dev/tty7 rw
/dev/tty8 rw
/dev/tty9 rw
/dev/null rw
/dev/pts rw
/dev/ptmx rw
/dev/tty rw
/dev/dsp rw
/dev/mixer rw
/dev/console rw
/dev/mem h
/dev/kmem h
/dev/port h
/dev/zero rw
/dev/log rw
/bin rx
/sbin rx
/lib rx
/usr rx
/etc rx
/etc/init.d h
/etc/shadow- h
/etc/shadow h
/proc rxw
/proc/sys r
/proc/kcore h
/tmp rw
/var rx
/var/cache rw
/var/spool rw
/var/run rw
/var/tmp rw
/var/log
/etc/grsec h
-CAP_ALL
+CAP_SYS_TTY_CONFIG
}

while calling "/usr/lib/Antivir/antivir", grsec still denies some operations which are explicitely permitted in above ACL:

denied connect to the unix domain socket /dev/log by (antivir:9167) UID(0) EUID(0), parent (bash:32520) UID(0) EUID(0)
use of CAP_SYS_TTY_CONFIG denied for (antivir:9167) UID(0) EUID(0), parent (bash:32520) UID(0) EUID(0)

these two operations are also denied in learning mode..

any ideas?

joschi

[patetobg]

post the /bin/bash acl...

[joschi]

(on this system /bin/sh == /bin/bash)

/bin/sh o {
/
/opt rx
/home rx
/mnt r
/dev
/dev/random r
/dev/urandom r
/dev/input rw
/dev/psaux rw
/dev/tty0 rw
/dev/tty1 rw
/dev/tty2 rw
/dev/tty3 rw
/dev/tty4 rw
/dev/tty5 rw
/dev/tty6 rw
/dev/tty7 rw
/dev/tty8 rw
/dev/tty9 rw
/dev/null rw
/dev/pts rw
/dev/ptmx rw
/dev/tty rw
/dev/dsp rw
/dev/mixer rw
/dev/console rw
/dev/mem h
/dev/kmem h
/dev/port h
/dev/zero rw
/bin rx
/sbin rx
/lib rx
/usr rx
/etc rx
/etc/postfix r
/etc/init.d h
/etc/shadow- h
/etc/shadow h
/proc rxw
/proc/sys r
/proc/kcore h
/root r
/tmp rw
/var rx
/var/cache rw
/var/spool rw
/var/spool/postfix/lib rx
/var/run rw
/var/tmp rw
/var/log
/boot r
/etc/grsec h
/bin/sh x
-CAP_ALL
+CAP_DAC_READ_SEARCH
}

[spender]

/usr/lib/Antivir/antivir must be a script that is not executed directly through execve() but as an argument to the shell, in which case your ACL is not being applied, but the ACL for /bin/bash is. Is this correct?

-Brad

[joschi]

argh!

well - at least i just found what was wrong.
it's quite surprising - if one spells a path correctly, more and more things suddenly start working as they are supposed to (/usr/lib/AntiVir).

(would it be possible to include the whole path - not just the name of the binary - in the grsec kernel log msgs?)

thx anyway

joschi

[spender]

1.9 does not do this, however, the newly released 2.0-rc3 does.

-Brad