[apparmor] [opensuse-factory] 12.1 is around the corner, and I must make my concerns known.

[Christian Boltz]

Hello,

on Mittwoch, 17. August 2011, John Johansen wrote:
> On 08/17/2011 01:21 AM, Sascha Peilicke wrote:
>> Christian Boltz wrote:
> >> My policy is that (at least) everything that listens on a network
> >> port should have a profile - yes, that means (and is) server
> >> usage mostly. I also have some profiles on my workstations for
> >> various daemons, and even have profiles for some small
> >> applications (and even scripts) to prevent that I shoot myself in
> >> the foot ;-) Needless to say that the foot-protecting profiles
> >> are very special for my usecase and nothing that can or should be
> >> packaged.
> > 
> > Sounds very reasonable, how about submitting those profiles? 

John and the other AppArmor developers can tell you that I _did_ submit 
my profiles upstream. Some of them are already in bzr, some others are 
still pending for review [1].

As I said, my "foot-protecting" profiles that I use for some very 
special cases are an exception - those profiles would be useless or even 
counter-productive for other people ;-)

> > Still this somehow supports my argument that it is very useful on
> > servers, less so on end-user machines.

"less useful" != "useless". On end-user machines, at least some daemons 
that run by default (nscd, klogd, syslog*, ahavi-daemon) and some small 
binaries (for example ping and traceroute) are protected by default. I 
wouldn't call that useless ;-)

But yes, on a server there are more applications that you can protect 
quite easy (compared to protecting firefox, which is difficult for the 
reasons I explained yesterday).

> >> The best example is downloading files - if you want to make
> >> Firefox really secure, you can limit write access (which includes
> >> downloads) to /home/*/downloads/**. However I'm quite sure that
> >> you'll then get lots of complaints because of "I can't download
> >> files to ~/coolstuff/" ;-)
> >> 
> >> The alternative that will avoid this complaints is basically this 
rule:
> >>     /** rw,
> >> 
> >> but this isn't really more secure than not having a profile at
> >> all. (In fact, someone already posted a modified firefox profile
> >> with such a rule in bugzilla - but I'm quite sure this will be
> >> rejected upstream.
> >> 
> >> Instead of /**, you could of course use /home/**, /tmp/**,
> >> /var/tmp/** as possible download locations - but that's already
> >> what the filesystem permissions make from the /** rule, so it
> >> isn't more secure. (A normal user doesn't have write permissions
> >> at other places, and if someone runs Firefox as root, well - I
> >> don't even want to think about that...)
> 
> owner @{HOME}/** rw,
> 
> would be even better

Yes, of course - but in practise it doesn't change too much. A normal 
user (hopefully) doesn't have write permissions in another user's home.
And if you don't include /tmp/**, people will probably complain that 
they can't download a file to /tmp (which might be a valid location for 
"download, unpack and delete the zip/tarball" downloads).

I know about owner restrictions etc. - but my point is that a firefox 
profile that makes everybody happy (by allowing storing downloads 
anywhere) does not really help security-wise.
And a "secure" firefox profile (restricted to ~/downloads) will cause 
lots of complaints ;-)

> >>> Everyone that would complain about such a move is invited to fix
> >>> the profiles we have or even create  _and maintain_ new ones.
> >> 
> >> Sounds like I should blog more instead of silently doing the work
> >> ;-)
> > 
> > That's the spirit, seems like I reached the correct guy here.

;-)

> >> That said: The best person to maintain a profile is a person who
> >> actually uses the profiled application. The reason for this is
> >> that nearly every application that does more than printing "hello
> >> world" has several config options that might influence which
> >> files are accessed. (I know AppArmor very well, but if you tell
> >> me "create a profile for $application" it will lack lots of rules
> >> if I'm not familiar with $application.)
> 
> its not just familiarity but because it doesn't fit your usage model.
> This really cries out for crowd sourcing, 

Exactly!

> >>> Otherwise I proposing a grace period for people to step up and
> >>> get rid of this for 12.1.
> >> 
> >> Does the above text count? ;-)
> > 
> > You don't demand that from our regular users? I mean I only got
> > some insights into writing profiles recently, as I'm forced to do
> > it (you know, policy @work). Still I'm having a hard time
> > confining a daemon running in a Java servlet container (no, not
> > tomcat) with many plugins, auto-update and that polls stuff in the
> > interwebs. 

Sounds interesting, but not impossible.
For comparison: I have a working profile for Apache with lots of vHosts, 
which includes Typo3 and many more "big" applications that are quite 
funny to profile.

You won't get a complete profile for such a setup in an hour (because 
you'll always miss something). The solution is: switch the profile to 
complain mode for some days, run logprof from time to time and finally 
switch the profile to enforce mode.

> > The only thing I learned so far that this isn't
> > childsplay :-)

IMHO using aa-genprof or aa-logprof isn't really hard. The only 
precondition is that you know what the permission flags mean. Some of 
them are obvious (like r and w), and you can learn the other ones in 30 
minutes. Yes, I'm sure about the 30 minutes because I did a talk about 
AppArmor at LinuxTag 2009 which took less than 30 minutes ;-)

If I find some free time at the conference (might be difficult because I 
probably can only come on sunday), I can provide you (and of course 
everybody else who is interested) with a short AppArmor workshop.

> nope, though feel free to ask for help on the apparmor ml or irc
> (#apparmor at irc.oftc.net).

> >> But the most important point is: it would be a loss for openSUSE
> >> if AppArmor would be disabled by default.
> > 
> > It's merely about opt-in or opt-out and thus, which is more
> > reasonable. Given the current state of our AppArmor integration
> > and the huge community demand, I doubt that. But that's what this
> > thread should be about.

The question is what is worse:
a) hindering a user by a too strict AppArmor profile (which is a rare 
   event IMHO)
b) an exploit in one of the confined daemons (nscd, syslog* etc.), while 
   AppArmor would have prevented the exploit. That's hopefully also a 
   rare event, but if it happens, it can have big consequences.

Call me paranoid, but I clearly prefer being hindered by a too strict 
profile ;-)


BTW: AFAIK there will be an AppArmor 2.7 beta release soon (mostly 
bugfixes compared to 2.6.x) - most probably early enough for inclusion 
in 12.1.


Regards,

Christian Boltz

[1] for those who aren't involved with upstream AppArmor:
    There is a policy that all changes have to be reviewed (by sending
    a patch) before they are allowed to be commited to bzr.
-- 
> [wikibot] jfyi: we have an internal ruby script that works with
> iChain. we used it for the SDB migration (did you really expect
> we uploaded 2000pages manually?;)
Considering you have nothing else to do, yes. ;-)
[Marcus Rueckert and houghi in opensuse-wiki]