[apparmor] Fun with mod_apparmor / HANDLING_UNTRUSTED_INPUT

John Johansen john.johansen at canonical.com
Sun Mar 18 07:53:37 UTC 2012


On 03/17/2012 01:36 PM, Christian Boltz wrote:
> Hello,
> 
> I reported this some time ago with old versions, but now I've seen it on 
> a server with openSUSE 12.1 and AppArmor 2.7.2 again:
> 
> The HANDLING_UNTRUSTED_INPUT hat randomly accesses files which should 
> only be accessed using the vhost's hat (vhost_something). This happens 
> rarely, IIRC it's the first time on this server (I installed the server 
> only some weeks ago, which means it is still quite bored and doesn't have
> many vhosts).
> 
> The log messages I see are:
> 
> type=AVC msg=audit(1331887298.588:2807): apparmor="ALLOWED" operation="file_perm" parent=6465 profile="/usr/sbin/httpd2-prefork//HANDLING_UNTRUSTED_INPUT" name="/home/www/example.com/httpdocs/joomla_neu/templates/system/css/system.css" pid=26820 comm="httpd2-prefork" requested_mask="r" denied_mask="r" fsuid=30 ouid=20008
> type=AVC msg=audit(1331887298.588:2808): apparmor="ALLOWED" operation="file_perm" parent=6465 profile="/usr/sbin/httpd2-prefork//HANDLING_UNTRUSTED_INPUT" name="/home/www/example.com/httpdocs/joomla_neu/templates/system/css/system.css" pid=26820 comm="httpd2-prefork" requested_mask="r" denied_mask="r" fsuid=30 ouid=20008
> type=AVC msg=audit(1331887299.888:2809): apparmor="ALLOWED" operation="file_perm" parent=6465 profile="/usr/sbin/httpd2-prefork//HANDLING_UNTRUSTED_INPUT" name="/home/www/example.com/httpdocs/joomla_neu/css/style.css" pid=31748 comm="httpd2-prefork" requested_mask="r" denied_mask="r" fsuid=30 ouid=20008
> type=AVC msg=audit(1331887299.888:2810): apparmor="ALLOWED" operation="file_perm" parent=6465 profile="/usr/sbin/httpd2-prefork//HANDLING_UNTRUSTED_INPUT" name="/home/www/example.com/httpdocs/joomla_neu/css/style.css" pid=31748 comm="httpd2-prefork" requested_mask="r" denied_mask="r" fsuid=30 ouid=20008
> 
> Looks like apache somehow failed to change to the requested hat, however
> I don't see any error message reporting something like that.
> 
> The apache profile and all its hats are in complain mode.
> 
> I use one hat per vhost, my apache config is:
> 
> <VirtualHost *:80>
>     AADefaultHatName vhost_something
>     [...]
> </VirtualHost>
> 
> Same question as last time: Do you have any idea what could cause this
> and how it can be fixed?
> 
Well I don't know what is going on but I can come up with a few different
scenarios and we can start hunting this problem down.

Scenario 1:
  For some reason change_hat is failing and we aren't getting any logging out.
  There are two places it could fail, within the kernel or in the user space.

  To debug this we would need to augment the logging.  A modified libapparmor
  with some special debug information should be able to confirm or deny this
  scenario.

Scenario 2:
  Something is broken in the kernels logging and its reporting the wrong profile.
  Maybe due to cache files.  I find this unlikely as this behavior was seen
  before cache files existed but it is worth investigation more.

Scenario 3:
  Apache isn't calling mod_apparmor for some reason.  To track this down we
  will need some debugging in mod apparmor.

Scenario 4:
  For some reason apache is trying to reuse a file that was opened in a vhost
  but wasn't closed.  We could check this case with a combination of enhanced
  logging from above as well as extending the kernel logging to report the
  cached label on the file.

  Knowing the messages are coming from file_perm I can already tell you the
  label does not match the tasks profile so the question becomes why, and
  was is it labeled with?  The label not matching is not the bug but it may
  help point us in the right direction.

The biggest problem we have is getting enough debug info to track this down. I
have never seen this, but then I don't do a lot with apache, I know steve has
seen it in the past but never managed to get info information to track it down

Christian are you will to run some libraries, modules, kernel with additional
logging so that we can track this down.

> 
> Regards,
> 
> Christian Boltz




More information about the AppArmor mailing list