[apparmor] [patch 3/3] profiles: apache2 — allow HANDLING_UNTRUSTED_INPUT access to abstractions/base

[Christian Boltz]

Hello,

Am Freitag, 20. Juni 2014 schrieb Kees Cook:
> On Wed, Jun 18, 2014 at 11:29:31PM -0700, Seth Arnold wrote:
> > HANDLING_UNTRUSTED_INPUT has always had some unexpected
> > consequences; I love the idea but it just might not work with
> > Apache's reality. 

Oh yes, there are some funny[tm] things happening in 
HANDLING_UNTRUSTED_INPUT.

> [...] However, this probably doesn't
> matter much because the current default for HANDLING_UNTRUSTED_INPUT
> is:
> 
>      / rw,
>      /** mrwlkix,
> 
> Which is totally crazy if the goal is tight isolation (which I totally
> agree with and mentioned in the bug).
>
> I ran out of time trying to further analyze the needs of
> HANDLING_UNTRUSTED_INPUT, but it seems that any access needed during
> location resolution is needed (e.g. authentication modules), so it may
> make sense to extend this with a "local" include. In my case I had to
> explicitly allow "/run/saslauthd/mux rw," in apache2-common.

Interesting... - and yes, this sounds like a local/ include would make 
sense.

Here's what I'm using in my /usr/sbin/httpd2-prefork profile on 
openSUSE:

  ^HANDLING_UNTRUSTED_INPUT flags=(complain) {
    #include <abstractions/nameservice>


    /**.htaccess r,  # hmm, I should change that to /**/.htaccess
    audit /home/www/*/statistics/logs/access_log w,
    audit /home/www/*/statistics/logs/error_log w,
    /home/www/all/global/htaccess-realurl-staticfilecache r,  # (1)
    /home/www/example.com/httpdocs/images/thumbs/various_images.jpg r,
    /proc/*/attr/current w,
    /var/log/apache2/access_log w,
    /var/log/apache2/error_log w,
    /var/log/apache2/error_log-20[01][0-9][01][0-9][0-3][0-9] w,
    /var/log/apache2/ssl_request_log w,

  }

To sum it up:
- abstractions/nameservice (sorry, I don't remember the details what 
  exactly is needed)
- .htaccess files
  Note: "(1)" is used as .htaccess via symlink
- /proc/*/attr/current w, to change to other hats
- write access to the global apache logs (including files that were 
  renamed by logrotate while apache was not restarted yet)
- spurious write access to a random vhost's logs
- spurious read access to random vhost's files
  Note: from what I've seen, this happens only for static content 
  (pictures, CSS, HTML, JS etc.). On the positive side, I've never seen 
  HANDLING_UNTRUSTED_INPUT reading PHP files.
  Using "EnableSendfile Off" helped to let this happen "only" rarely,
  but it still happens.

The interesting task is hunting down why the "spurious" things happen. 
Steve already did some debugging with me, but we didn't find an 
explanation yet. I'm sure Steve will pay you a drink when you find the 
reason why these spurious access to vhost's logs and static files happen 
in HANDLING_UNTRUSTED_INPUT.

BTW: IIRC sometimes I have 3 or 5 HANDLING_UNTRUSTED_INPUT events in the 
log within a second, and then nothing in the next hour. (I can check 
fresh logs if you think this detail could be relevant.)

Anyway, even while allowing the spurious things, we could reduce
  /** mrwlkix,
to something like
  /** r,
  /**log* rw,

> Anyway, I guess my point is, at a minimum, the signal handlers need to
> be added, but given the existing totally open permissions, it doesn't
> currently hurt to add base.

Hmm, abstractions/base in bzr doesn't seem to contain any signal rule 
(only usr.sbin.apache2 and abstractions/apache2-common contain signal 
rules).

Is this an Ubuntu patch that was not commited to bzr yet?


Regards,

Christian Boltz
-- 
<dragotin> where is that lazy chicken btw?
<suseROCKs> Ouch!
<dragotin> oh - code of conduct violated?
<dragotin> "It is not allowed to call henne a lazy chicken!"
<suseROCKs> revised last week:  It is required to call him that
[from #opensuse-project]