[apparmor] Fun with mod_apparmor / HANDLING_UNTRUSTED_INPUT

Sun Mar 18 08:28:36 UTC 2012

On 03/18/2012 12:59 AM, Seth Arnold wrote:
> Another possibility is that the APR "flush" operation isn't blocking before returning to the main loop -- it could be that the flush operation in the mod_apparmor doesn't suffice to truly flush all io operations that had been logically initiated from within a hat.
> 
Possibly, though this would mean that apache is storing up the operation and
then issuing to the kernel at a later point.  I haven't looked into the
apache api or mod_apparmor at that level.  For a read operation that would
probably mean we are usually filling the buffer in the vhost_ hat but
sometimes there is a case where it needs to be read more after changing back

> Incidentally, is this another case where a "core" option could be useful to force a core dump that can provide a backtrace?

Yes it might, though I am not sure Christian would want his server to just
stop.  Perhaps if gdb or what ever is watching would catch the signal and
record state, and then continue the process right away.

> -----Original Message-----
> From: John Johansen <john.johansen at canonical.com>
> Sender: apparmor-bounces at lists.ubuntu.com
> Date: Sun, 18 Mar 2012 00:53:37 
> To: Christian Boltz<apparmor at cboltz.de>
> Cc: <apparmor at lists.ubuntu.com>
> Subject: Re: [apparmor] Fun with mod_apparmor / HANDLING_UNTRUSTED_INPUT
> 
> 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
> 
> 