[apparmor] [Patch] mod_apparmor: try uri hat after AADefaultHatName, not before

[Steve Beattie]

On Thu, Jun 12, 2014 at 05:46:44PM -0700, Seth Arnold wrote:
> On Thu, Jun 12, 2014 at 02:23:46PM -0700, Steve Beattie wrote:
> > Bug: https://bugs.launchpad.net/bugs/1322778
> > 
> > In trunk revno 2335, a bug was fixed in mod_apparmor that corrected
> > the storage location for AADefaultHatName.  The incorrect storage
> > caused the hat specified by the AADefaultHatName keyword to be the
> > default value for AAHatName, and meant that if both an AAHatName and
> > an AADefaultHatName entry were given in a vhost, mod_apparmor would
> > not fall back to trying AADefaultHatName if the hat specified in
> > AAHatName did not exist in the apache apparmor profile.
> > 
> > However, because the value specified in AADefaultHatName was the
> > default, if no AAHatName was specified, it would be attempted first,
> > before a hat based on the passed URI, rather than after as the
> > documentation stated and the code intended. By fixing the storage bug,
> > the attempted hat ordering now matched the documentation. But a number
> > of users came to rely on AADefaultHatName being attempted before
> > the URI. For trunk, this issue is less severe because mod_apparmor
> > passes a vector of hats to aa_change_hatv(), and thus missing URI
> > hats are not logged by the kernel apparmor bits. It still represents
> > a behavioral change to users, though.
> > 
> > This patch re-adjusts the ordering so that the URI-based hat is
> > attempted after the hat specified by AADefaultHatName is attempted,
> > thus maintaining the actual behavior before the bug addressed in
> > revno 2335 was fixed.
> > 
> > (Apologies that the manpage changes are represented as larger than the
> > actual changes made; I reflowed the paragraphs, which caused gratuitous
> > changes.)
> > 
> 
> I don't like this much; if I've understood it correctly, this patch makes
> it impossible to have most URIs in an application use one hat and
> special-case a few URIs with another hat. AADefaultHatName and AAHatName
> are more or less identical, right?

No. AADefaultHatName is for the entire vhost. AAHatName applies to
everything within a Directory, Location, or the corresponding
{Location,Directory}Match directive. Now, an AAHatName within a
Directory directive that specifies the toplevel of the vhost *is*
equivalent to setting an AADefaultHatName for the vhost.

But you can do things like:

  <VirtualHost mylinkedbook.nsa.gov>
    AADefaultHatName innocent-website-no-really
      DocumentRoot /some/path/

      <Directory /some/path/secrets>
        AAHatName nothing-to-see-here-go-away
      </Directory>

      <Directory /cgi-bin>
        AAHatName security-bugs-rico-millions-of-em
      </Directory>

      <Directory /cgi-bin/cpanel>
        AAHatName are-you-serious
      </Directory>

   </VirtualHost>

Given this (assuming all specified hats exit), the following requests
would use the listed hat:

  Request URI (mylinkedbook.nsa.gov stripped off)	HAT
  -------------						-----
  / 							innocent-website-no-really
  /top_level.html 					innocent-website-no-really
  /img/we_are_friendly.png				innocent-website-no-really
  /secrets/						nothing-to-see-here-go-away
  /secrets/sauce.html					nothing-to-see-here-go-away
  /secrets/images/angry_cat.png				nothing-to-see-here-go-away
  /cgi-bin/						security-bugs-rico-millions-of-em
  /cgi-bin/foia_request.php				security-bugs-rico-millions-of-em
  /cgi-bin/cpanel/					are-you-serious
  /cgi-bin/cpanel/admin.php				are-you-serious
  /cgi-bin/horde3/					security-bugs-rico-millions-of-em

You can play similar games with the Location directive, if you want
to manage the URI space directly. For more information on the way to
use the different containers, apache has pretty good documention[0].

The downside to using the raw URI as a hat name is that they aren't
individualized on a per-vhost basis, so if we share a vhost, my
/cgi-bin/dumb_thing.php script and your /cgi-bin/dumb_thing.php
script would end up with the same hat. (I'm not sure from the hooks
we use that I would get the mapping to the filesystem, but there's
also synthetically generated URIs that have no direct mapping to a
filesystem path to consider as well.)

I do have a followup patch that prepends the AADefaultHatName
to the URI — and remember, the enhancement request in
https://bugs.launchpad.net/apparmor/+bug/1207424 has landed on trunk,
so it would default to the ServerName if AADefaultHatName has been
specified — which would address the overlapping URI across vhosts
issue. But it means more work occurs in the mod_apparmor hook, so
I'm not entirely sold on it.

Now, looking at the apache documentation, it might also be useful
to support AAHatName within the Files and FilesMatch directives[1]
as well, if you wanted individual control over specific files or
file patterns, which can be nested within Directory directives, to
only apply to a portion of the filesystem. But I haven't looked at
how hard that would be to implement.

In an event, I think the flexibility to do what you want will still
be there even after this change. I do need to document this stuff on
the wiki better, as I'd like to see more people take advantage of it.

[0] http://httpd.apache.org/docs/current/sections.html#file-and-web
[1] http://httpd.apache.org/docs/current/mod/core.html#files

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20140612/352823ba/attachment-0001.pgp>