[DSE-Dev] Fwd: Updated plans for AppArmor support [Was: Enhancements/enabled hardening flags in Wheezy pkgs/release.]

[Andreas Kuckartz]

An interesting mail regarding the state of AppArmor (in case someone
here has not yet seen it).

Cheers,
Andreas

-------- Original Message --------
From: intrigeri <intrigeri at debian.org>
To: debian-security at lists.debian.org
Cc: apparmor at packages.debian.org, apparmor at lists.ubuntu.com, Jacob
Appelbaum <jacob at appelbaum.net>, tails-dev at boum.org
Subject: Updated plans for AppArmor support [Was: Enhancements/enabled
hardening flags in Wheezy pkgs/release.]

Hi all,

I'm taking this opportunity to share a bit about my experience and
plans for improving AppArmor support in Debian => cc'ing the
potentially interested parties: AppArmor maintainer in Debian,
upstream mailing-list, Tails developers and Jake. If I've forgotten
someone, I'm sorry, please forward as you see fit.

Daniel Curtis wrote (02 Jan 2014 23:36:04 GMT) :
> Anyway, it could be very nice if *Debian* would start to
> implement *AppArmor* for serious

AppArmor is already usable on Wheezy:

    https://wiki.debian.org/AppArmor

Daniel, I can understand that you don't see this as "serious". In the
last two years, I've been conducting this merely as a side project,
and did not put much energy into bootstrapping an organized team
around it. Feel free to join me and make it more serious :)
I personally expect to be able to allocate substantially more
resources to this project in 2014Q3 and Q4 than what I've done in the
past (hint: the roadmap for the Tails 2.0 milestone includes AppArmor
confinement for a few apps). It will probably be too late for having
something really big in Jessie (*if* I do it alone), but I am
confident that we will ship many more confinement profiles in Jessie
than in Wheezy.

Flashback, my focus in the last two years was: testing, improving and
maintaining profiles; slowly being done in collaboration with the very
kind upstream and Ubuntu folks. I think I've now been doing this for
long enough to be able to make a realistic evaluation of the effort it
takes to maintain a set of profiles I find relevant for testing/sid
=> does not seem crazy, time to go public.

Next step: I plan to create a apparmor-profiles-extra package with
most of the profiles that Ubuntu spreads over individual packages;
keeping it all in one place, maintained by those who are interested.
Stefano Zacchiroli easily convinced me that it would better match the
current state of AppArmor adoption and expertise among Debian
maintainers than the Ubuntu model, where:

  * AppArmor is enabled by default, so expertise in this area is more
    widespread among many kinds of contributors;
  * it is my understanding that AppArmor profiles are mostly
    maintained by a relatively small set of people, who are experts in
    this area;
  * the AppArmor experts can easily update profiles by pushing changes
    to any package's VCS repository, thanks to the "no strong
    ownership of packages" model.

If this works out well, then enabling AppArmor + installing
this -extra package on Jessie should give you roughly the same level
of AppArmor support as provided by Ubuntu 13.$something. Note that we
will probably always lag a bit behind: at the time a new Ubuntu
release is put out, it often ships a lot of AppArmor features, patches
and improvements that have not made their way in any upstream AppArmor
or Linux release yet; I don't think we would easily gather within
Debian the resources needed to do the same amount of
{back,forward}porting, integration and QA work. And even if we did,
our "upstream first" culture would probably make us *not* want to do
this. That's not a competition anyway, and I'm confident we manage to
collaborate between different projects, despite our different agenda
(especially regarding the "app store" use case and MAC isolation for
lightweight containers hardening, that are currently leading the
efforts Ubuntu puts into AppArmor front as I understand it).

Let's bootstrap something useful and then we'll see if the project
wants it enabled by default; then only, it will be worth reconsidering
to spread AppArmor profiles over individual packages, and possibly to
either give a dedicated team a NMU wildcard for liberal NMUs that
touch only the AppArmor bits, and/or to move the responsibility to
maintain it over maintainers' shoulders if they wish. I have no idea
what Debian as a project may prefer in this area, and I think it's too
early to try guessing. Let's do some more homework first. The wiki
page does not reflect this strategical move of mine yet, sorry.

Feedback and help are warmly welcome :)

(Oh, and Michael Stapelberg was kind enough to provide me, in a matter
of minutes, with a draft patch that adds explicit AppArmor profile
loading support to systemd, for the rare cases that need this kind of
things, such as the Tor package. I've been meaning since DebConf13 to
trace it and debug why the first iteration of this patch does not work
for me. My current Tor unit file uses aa-exec, and it works fine for
me, so I've had no strong incentive to work on the nicer way to do
it... yet.)

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
To UNSUBSCRIBE, email to debian-security-REQUEST at lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster at lists.debian.org
Archive: http://lists.debian.org/85ob3tpzy0.fsf@boum.org