[pkg-apparmor] Planning AppArmor work at DebCamp17 [Was: Share your plans for DebCamp17]

[Christian Boltz]

Hello,

Am Samstag, 22. Juli 2017, 08:27:12 CEST schrieb intrigeri:
>  * Draft a plan to propose enabling AppArmor by default in Buster,
>    including:
> 
>    - write pros/cons for Debian users, e.g.:
>      · security: examples of security issues that AppArmor has
>        mitigated

See below ;-)

>      · impact on boot time

Maybe one second if you enable profile caching (other things can still 
run in parallel), so I wouldn't call this a noticable impact.

>      · breakage of functionality: analyse how much breakage AppArmor
>        has caused in the past, and how quickly it's been resolved
> 
>    - analyse cost for maintainers of affected packages (starting with
>      data about how often profiles had to be updated during the
>      Stretch development cycles)

That obviously depends on which profiles you ship, so it might make
sense to split this analysis by package or at least groups of packages 
(like "daemons", "browser", "other GUI applications", ...)

[...]
>  * Propose maintainers to include profiles currently shipped in
>    aa-p-extra in their own package (not all of them are ready for
>    prime-time, but some are).

I'm looking forward for patches to make these profiles ready for 
prime-time ;-)

> Questions
> =========
> 
>  * Comments, suggestions about the above plan?
> 
>  * Do you want to participate in any of this, either face-to-face
>    or remotely?

Please ask again when you know the exact date/time. If it matches my 
schedule, I'll be on IRC in #apparmor.

>  * @non-Debian people (e.g. Ubuntu and OpenSuSE): would you be ready
>    to chime to support the "enable AppArmor by default in Debian"
>    proposal, e.g. with data, or less formal testimonies, coming from
>    your experience working on a distro that has AppArmor enabled
>    by default?

openSUSE has AppArmor enabled by default. We don't ship too many profiles 
in /etc/apparmor.d/ (those from the upstream tarball, and some packages 
also come with profiles). My goal is to only ship profiles that don't 
cause trouble, so if in doubt, I tend not to ship a profile in 
/etc/apparmor.d/

To get an overview what we ship, get the profile collector package from
http://download.opensuse.org/repositories/security:/apparmor:/profile-collector/ 
(I didn't check for a while, so maybe the collection misses one or two 
packages that include profiles now.)

BTW: a similar package or repo with all profiles shipped by Debian would
be nice, not even to mention a profile repo ;-)


A special case is samba. openSUSE has a script to update the profile 
based on the configured shares, and this reduced the bugreports about the 
profile to zero :-)  (feel free to steal this script from the samba 
package)

The samba profile is also a special case for another reason - it helped
to prevent "SambaCry" getting exploited:
https://lists.opensuse.org/opensuse-security-announce/2017-05/msg00067.html


Regards,

Christian Boltz
-- 
> I also prefer realnames. But if people want to use a _spellable_
> alias, it's ok for me too.
> However, I hate aliases like "fE3,x7~5X" ;-)
Noone should use his/her password as a mail name ;-)
[> Christian Boltz and meister(at)netz00.com in opensuse]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-apparmor-team/attachments/20170722/08bd2211/attachment.sig>