I get "denied untrusted exec" in learning mode

[xor]

Hi all

I have a web application with apache2, perl scripts and own database in a protected path, which is the root for a chrooted mini-linux-system (containing all required libraries, binaries, startscripts etc.).

There are four processes relevant to the web app that get started from within the chroot: apache2, mysqld, cron an syslog.

Access to the chroot (/var/approot) is granted only if a special admin RBAC role is assumed by the user logged in, else it is hidden. So the start procedure is login -> sudo su - -> gradm -a admin -> chroot /var/approot bash -> /etc/init.d/servicename start

In the "master" system, I have enabled learning for all required roles by adding "l" to their role modes:
role admin sATl
role mysql uGTl
role httpd uGTl
role default GTl

and started RBAC with gradm -L /root/learn.log -E

The user accounts are synchronized between the "master" and the chrooted system, i.e. both have the same users, groups etc in /etc/passwd.

Now most of the startup does succeed, but the web application server (/var/approot)/usr/sbin/apache2 (running as user httpd) is denied execution of its own binaries contained in the chroot (/var/approot)/app/bin with the denied untrusted exec message by grsec.

The enabled chroot protections are:
kernel.grsecurity.chroot_deny_sysctl = 1
kernel.grsecurity.chroot_caps = 1
kernel.grsecurity.chroot_restrict_nice = 1
kernel.grsecurity.chroot_deny_mknod = 1
kernel.grsecurity.chroot_deny_chmod = 1
kernel.grsecurity.chroot_enforce_chdir = 1
kernel.grsecurity.chroot_deny_pivot = 1
kernel.grsecurity.chroot_deny_chroot = 1
kernel.grsecurity.chroot_deny_fchdir = 1
kernel.grsecurity.chroot_deny_mount = 1
kernel.grsecurity.chroot_deny_unix = 1
kernel.grsecurity.chroot_deny_shmat = 1

I was of the opinion that with learning enabled on a role the ruleset pertaining to that role is not enforced, but obviously I'm missing something. Could somebody share a hint, pointer with a clueless soul

thx /markus

[PaX Team]

I was of the opinion that with learning enabled on a role the ruleset pertaining to that role is not enforced, but obviously I'm missing something. Could somebody share a hint, pointer with a clueless soul

the denied exec message comes from TPE which bases its decision on both your ACLs and the normal file system access rights. for the gory details see grsecurity/grsec_tpe.c:gr_tpe_allow() and grsecurity/gracl.c:gr_acl_tpe_check().

[xor]

Yes, this is what I thought, too. If I have all subjects in learning mode (the policy file actually only has those 4 lines), and the application runs smoothly with RBAC disabled, I didn't expect to see any difference when enabling it.
But yet, TPE does block execution, and I can't seem to find out why

Could the fact that the application is running within a chroot confuse TPE?

[spender]

You should remove the TPE flag (T) from the roles being learned, since the TPE algorithm won't be changed by the learning process and will continue to be enforced as usual.

-Brad