AppArmor profile shows not confined

[Shaheena Kazi]

Hi,

I have created a profile for /usr/sbin/apache2(I am using multiple apache's).

Now, I have added a new script, which is getting blocked by apparmor profile and it gives apparmor denials. This is a expected behavior. And I understand the logic behind it.

The problem here is if I disable apparmor and then enable apparmor again. Everything start working fine.
- No denials, no issues.

When I run aa-unconfined, I see the below:
++++
5904 /usr/sbin/apache2 not confined
5908 /usr/sbin/apache2 not confined
5909 /usr/sbin/apache2 not confined
5910 /usr/sbin/apache2 not confined
5911 /usr/sbin/apache2 not confined
5912 /usr/sbin/apache2 not confined
6535 /usr/sbin/apache2 not confined
++++

If I check apparmor status, via aa-status... it shows running.
Also, cat /sys/kernel/security/apparmor/profiles | grep apache .... I can see apache enforced,
/usr/sbin/apache2 (enforce)

But I get /usr/sbin/apache2 is not confined, hence I get no denials.

If I restart apache service and then do a aa-unconfined, I see the below :
+++++
11021 /usr/sbin/apache2 confined by '/usr/sbin/apache2 (enforce)'
11026 /usr/sbin/apache2 confined by '/usr/sbin/apache2 (enforce)'
11027 /usr/sbin/apache2 confined by '/usr/sbin/apache2 (enforce)'
11028 /usr/sbin/apache2 confined by '/usr/sbin/apache2 (enforce)'
++++

Then I get the denials as expected.

Why is this behavior ? Why does the apache gets flushed(not confined) ?
Please help.

Regards,
Shaheena K

[Seth Arnold (seth-arnold)]

On Fri, Sep 04, 2020 at 05:20:13PM -0000, Shaheena Kazi wrote:
> The problem here is if I disable apparmor and then enable apparmor
> again. Everything start working fine. - No denials, no issues.
>
> When I run aa-unconfined, I see the below:
> ++++
> 5904 /usr/sbin/apache2 not confined

Probably "disable apparmor" is the cause: I'm guessing this means
unloading profiles, then loading profiles.

Processes that were already running aren't confined when profiles are
loaded. (They cannot be: without the full execution history of all
processes since boot we can't select the correct profile to apply to the
processes that remain.)

The usual way to perform profile development is to reload profiles after
modifying them. The aa-logprof and aa-genprof tools help this process, but
you could just as easily run
apparmor_parser --replace /etc/apparmor.d/usr.sbin.apache2
by hand when it is convenient.

I hope this helps.

Thanks

[Shaheena Kazi (shaheenakazi)]

Hi Arnold,

(They cannot be: without the full execution history of all
processes since boot we can't select the correct profile to apply to the
processes that remain.)
-- Can you elaborate more on this point.

Sorry and thanks for the help.

[Seth Arnold (seth-arnold)]

On Mon, Sep 07, 2020 at 07:27:38PM -0000, Shaheena Kazi wrote:
> (They cannot be: without the full execution history of all
> processes since boot we can't select the correct profile to apply to the
> processes that remain.)
> -- Can you elaborate more on this point.

Sure; lets consider an example like /bin/sed. You may have a dozen of them
running at any given time on your computer because it's a handfy little
utility. Some of the sed processes may be running as root, unconfined.
Others might be confined via child profiles stacked on parent profiles
stacked in a namespace etc. (This sounds a bit far-fetched, but sed is
used in the shell script that starts firefox. If someone writes a profile
for that shell script that places sed into a child profile and if the
user's X session is in its own apparmor namespace, it's pretty easy to
achieve.)

If AppArmor policy is loaded during bootup, those dozen sed processes
might all have different policies applied. If the policy isn't loaded,
then they are all equally unconfined, and the information needed to decide
which processes should use which profile is no longer available.

So, AppArmor doesn't try to confine existing processes when loading
policy.

I hope this helps.

Thanks