[pkg-apparmor] AppArmor BoF at Debconf - report

Fri Jul 8 18:40:20 UTC 2016

Hello,

I'm happy to see that you are using DebConf to work on AppArmor :-)

Some notes and comments:

Am Donnerstag, 7. Juli 2016, 18:41:00 CEST schrieb u:
> Attendees: u, Ximin, Guido, Alan, mesutcang, nicoo, jerith
> 
> Status, updates and plans
> =========================

> kernel
> ------
> 
> AppArmor support in the kernel: Generally, we rely on mainline
> Debian's kernel and upstream who works in the canonical Linux kernel.
> This means we lack some support:
> * dbus calls mediation
> * mount rules / containers

Debian probably also lacks support for signal, ptrace, pivot_root and 
unix rules - basically all the "new" rule types.

I'm not sure about network rules, but IIRC the patch for them is not in 
the upstream kernel yet (however openSUSE includes it since years, so it 
should be safe to take it).

> policy
> ------
> 
> Policy done in Debian.
> Some is on the apparmor-profiles-extra package.
> Other profiles shipped in the respective packages.

For comparison: in openSUSE, I ship most profiles in the apparmor-profiles 
package. There's also a small number of packages that include their own 
profiles.

> Cross-distro
> ------------
> 
> Git repository layout which is still in the notes of intrigeri from
> Debconf15.
> Upstream just converted their repository to Git.
> 
> TODO
> ----

May I add an item here?

* push all profiles shipped in Debian into the upstream apparmor-profiles 
  repo - that would make it much easier for other distibutions to 
  steal ;-) them.
  Ideally this would include the metadata (as discussed at DebConf15), 
  but the most important thing is to have all profiles in the repo.

> * does it make sense to ship profiles in the package only if upstream
> ships it or if it does not then we ship it in the upstream repo.

See (non-random) sig ;-)

I really love it when upstream cares about AppArmor, but I'm afraid 
that's the exception, so don't count on it.

> Testing:
> * how do we test? do we have scripts?

The upstream tarball comes with some tests (for parser, utils and 
libapparmor) - you can run them when building the AppArmor package.

There is also
bzr+ssh://bazaar.launchpad.net/+branch/qa-regression-testing/
which contains lots of runtime tests that are done for Ubuntu QA.
(These tests add users etc., so you should run them in a clean VM.)

I played with the AppArmor part of these tests some months ago. 
Results:
- most of them also run on openSUSE, so I'd expect them to also work on 
  Debian
- the pam_apparmor tests need some modifications (because "useradd  foo" 
  will not add a group "foo" for that user on openSUSE, but it does on 
  Ubuntu)
- the tests for dbus, ptrace, signal etc. obviously fail because the 
  kernel support isn't upstream yet.

Upstream mentioned some interest in moving those tests into the AppArmor 
tarball (so that they are available to other distibutions), so if 
someone is bored... ;-)

> * proposal: check if aa is enabled and then try to fetch violations?

-v please ;-)

> * idea of bugscript: we ship the script inside of the apparmor
> package. maintainers can add if $script exists, source $script. maybe
> this could add a usertag too? nicoo would like to look into it. =>
> todo create bugreport with nicoo in cc.
> 
> Icedove: better ship this before the freeze.
>
> Debugging:
> * Add things to "man apparmor" and AppArmor upstream wiki from John
> Johansen https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826218 :u:
> * Click on an URL in the aa-notify window for maintainers and/or
> non-technical users to debug?

Sounds like a nice idea.

Note that aa-notify needs a rewrite (it's the only remaining perl tool), 
but that shouldn't stop you from improving the message. Ideally the link 
should be a config option, so that we can take the main patch upstream 
and Debian only has to ship a different notify.conf.

> Tasks for starters:
> *
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=new-profile&user=p
> kg-apparmor-team%40lists.alioth.debian.org

Nice list :-)

For "less" - does Debian use a $LESSOPEN script? If yes, profiling that 
is probably more important than profiling less itsself. Feel free to 
steal the openSUSE profile for that ;-)

I'm slightly surprised that less needs abstractions/user-write (which 
effectively allows write access to the homedir) - what's the reason for 
this?

BTW: Did you ever press   v   in less with this profile active? *eg*

> Next big(ger) goals
> ===================

> Blockers for getting aa enabled by default
> ------------------------------------------

> * what about having a package with working profiles and
> half buggy profiles (in complain mode) instead of the current
> apparmor-profiles some of which don't work

Define "don't work" please ;-)  and also specify which profiles you are 
talking about.

My personal opinion is not to ship a profile in complain mode (so either 
enforce mode or not in /etc/apparmor.d/) to avoid giving users a false 
sense of security, but opinions on this probably differ ;-)

>  - some of those half working should move to
> /usr/share/doc/apparmor/examples :intrigeri:

Note that aa-genprof will pick up profiles from
    /usr/share/apparmor/extra-profiles/
so using a different path doesn't sound like the best idea.

This path is configurable in logprof.conf inactive_profiledir, but having 
the same on all distributions would be better IMHO.

> * start a discussion to enable it by default right after stretch is
> released.
> 
> * don't forget the server usecase

Actually that's quite easy because daemons don't have a "File - Save 
as..." dialog ;-)

You might want to steal something from openSUSE here:
- the dovecot profiles (from the upstream tarball) are well-tested, users 
  only need to adjust tunables/dovecot for their mail storage location
- for Samba, openSUSE has a script that updates a profile sniplet with
  the path of all Samba shares, which resulted in nearly-zero bugreports
  for the Samba profile. If you are interested, I can dig out that script
  for you.

Hmm, we really need the profile repo so that we have an overview who 
ships which profiles ;-)

> * don't forget libvirt
> 
> * RC Scripts could be made much simpler - help is welcome.
> 
> * encode in policy how to use dh-apparmor :intrigeri:
> * hardening: lintian warning if setuid=1 or if you ship a service
> file. e.g. "you seem to xyz, but there is no apparmor profile
> enabled" - maybe use the bugscript to do this. :nicoo:

Nice idea.
When this is finished, I'd be interested in porting it to rpmlint.

> AppStores/DMGs
> --------------
> Flatpack/Redhat/SELinux, UbuntuSnap/AppArmor (sandboxing), this makes
> it less obvious to make a choice for Debian.
> Shipping aa by default, people who will want to use flatpack, will not
> be able to do it.

Indeed, that's a very interesting can of worms :-/

That all said - enjoy the last days of DebConf!

Regards,

Christian Boltz

PS: non-random sig, as indicated above
-- 
> > Ideally, upstream projects would care for AppArmor profiles
> > (as much as they would care for SELinux),
> Oh, upstream projects really care for SELinux? ;-)
At least as much as they do for AppArmor ;-)
[> Christian Boltz and Sascha Peilicke in opensuse-factory]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-apparmor-team/attachments/20160708/cad21547/attachment.sig>