[apparmor] [patch] split off apache permissions to abstractions/apache2-common

[Christian Boltz]

Hello,

Am Mittwoch, 4. Januar 2012 schrieb Steve Beattie:
> On Thu, Dec 22, 2011 at 01:17:57AM +0100, Christian Boltz wrote:

> > I'm also nominating this patch for the 2.7 branch (maybe except
> > disallowing /.htaccess for ^HANDLING_UNTRUSTED_INPUT  if you are
> > afraid it breaks some setups)
> 
> I have no issue dropping to /**/.htaccess for 2.7 or trunk.

Looks like you slightly misunderstand this change.
The current profile has  /**.htaccess 

My patch changes this to /**/.htaccess, which means:

                       current profile    with my patch
/.htaccess               allowed [1]         denied
/some/.htaccess          allowed             allowed
/some/where/.htaccess    allowed             allowed
/foo/some.htaccess       allowed [2]         denied

In other words: 
[1] a .htaccess in / is no longer allowed
[2] the (IMHO accidential) permissions for files named *.htaccess are 
    also dropped.

Even if it is unlikely that someone needs /.htaccess or *.htaccess, 
I'm afraid there will be at least one person who relies on one of them. 
To make it even worse, if a /.htaccess exists and access is denied, it 
will break the whole server :-/ (see my reply to John for details)

IMHO there are two options:

a) keep /**.htaccess for 2.7 and add a deprecation warning to it. So for 
   2.7, the patch would contain:

+ # Warning: This rule accidently allows access to *.htaccess files.
+ #          Future versions will no longer allow this, and also 
+ #          won't allow a .htaccess file directly in /
   /**.htaccess r,

b) drop only [2] (it looks like a bug that this was allowed, and denying 
   it at least can't break the whole server). The patch would then be:

- /**.htaccess r,
+ /.htaccess r, # warning: .htaccess directly in / will be disallowed 
+               # in future versions (.htaccess in subdirectories is
+               # and will stay allowed by abstractions/apache2-common)

Which solution do you like more?

> Acked-By: Steve Beattie <sbeattie at ubuntu.com>
> 
> ... with some inline comments.

I'll commit if you don't reply within 24 hours *eg*

> > === modified file
> > 'profiles/apparmor.d/abstractions/apache2-common'
> > --- profiles/apparmor.d/abstractions/apache2-common	2010-01-03
> > 21:16:38 +0000 +++
> > profiles/apparmor.d/abstractions/apache2-common	2011-12-21
> > 23:57:10 +0000 @@ -1,9 +1,20 @@
> > 
> >  # vim:syntax=apparmor
> > 
> > +# This file contains basic permissions for Apache and every vHost
> > +
> > +  #include <abstractions/nameservice>
> > +
> > 
> >    # Apache
> >    network inet stream,
> > 
> > +  network inet6 stream,
> 
> I'm actually surprised this is needed given the inclusion of
> abstractions/nameservice

That's the result of using vi to merge the profiles (did I already 
mention that a merge tool would be helpful? ;-)

That said: you are right, but we should then decide if we
a) also want to drop "network inet stream" which is also in 
   abstractions/nameservice
b) have both in apache2-common to make it clear that apache uses the
   network (even if everybody should know it for obvious reasons)

Speaking in patch format:

a) -  network inet stream,
   (and not adding "network inet6 stream")

b)    network inet stream,
   +  network inet6 stream,

> The HANDLING_UNTRUSTED_INPUT hat is
> intended to be a minimal set of privileges needed while parsing an
> http request. Once it's been parsed, then mod_apparmor is supposed
> to switch to the appropriate hat for the request which may have wider
> privileges (but still a subset of the whole).

"supposed to" describes it very well ;-)
At least on an "old" server with openSUSE 11.1 / AppArmor 2.3 
HANDLING_UNTRUSTED_INPUT seems to fail to switch to the correct hat in 
some cases. Not often, but on a busy server, it sums up to some requests 
per day.
In the meantime HANDLING_UNTRUSTED_INPUT asked for write permissions on 
many (all?) vhosts' access and error logs and also some pictures from 
random vhosts.

I know 2.3 is quite old, therefore I'm only asking if there were some 
fixes in this area since then instead of opening a bugreport.

Be warned that I'll setup a new webserver with openSUSE 12.1 in the next 
days - if I see similar behaviour there, I _will_ file a bugreport ;-)


Regards,

Christian Boltz
-- 
Ich rede davon, daß eine defekte Schrift an freetype übergeben wird (Daß
sie defekt ist, kann ich ja nicht prüfen), woraufhin freetype irgendeine
(defekte) Anweisung im Fontcode ohne Prüfung ausführt und erstmal
getreulich versucht, sagenwirmal 5 Okobyte RAM von der Adresse $IRSINN
nach $WAHNSINN zu verschieben. [Ratti in suse-programming]