[apparmor] [patch] split off apache permissions to abstractions/apache2-common
Steve Beattie
steve at nxnw.org
Thu Jan 5 21:24:50 UTC 2012
Hi Christian,
On Thu, Jan 05, 2012 at 09:02:22PM +0100, Christian Boltz wrote:
> 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)
I really did understand that you were proposing to drop access to both
case [1] and case [2]. Case [2] seems to be an unintended oversight
and I'd really like to fix it.
I do grant that preventing access to /.htaccess and having the server
break because of it is less than ideal. But if you've configured
your server such that it uses /.htaccess, you'll need to adjust your
profile either when upgrading to the 2.8[0] release or possibly in 2.7.1,
depending on what we choose here.
I'll also point out that apache allows one to use a different name
for the .htaccess files with the Accessfilename directive (see
http://httpd.apache.org/docs/2.2/mod/core.html#accessfilename ).
So I suppose it's possible that someone choose an alternate name that
happened to match the pattern (e.g. some.htaccess), which would then
break with this bugfix.
That said, it seems unlikely that people configure apache in either
way. (Where performance is a concern, upstream recommends not using
.htaccess at all, but instead adjusting the apache configuration
directly.)
> 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?
Of these two choices, I'd personally prefer (b). We should probably
highlight this in the release notes as well.
> > >
> > > # 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,
I'm okay with having it in apache2-common to make it explicit. It was
more an expression of surprise that it showed up (I was more fearful
of it being the result of another logprof/genprof bug).
> > 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.
Yes, I saw that as well on openSUSE 10.3 I think. I could never get it
to occur frequently enough to debug it.
> 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 ;-)
No, there's not been any changes in mod_apparmor that would affect
this. That said, I've not seen this occur on Ubuntu with newer
versions of apache, so it's possible there was something fixed within
apache that affected this behavior. If you do see it, I'd appreciate
a bug report, as I'd really like to track down what's going on.
[0] Or whatever version we end up calling the next non-2.7.x release.
--
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: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20120105/b679bae8/attachment.pgp>
More information about the AppArmor
mailing list