AppArmor in Debian BoF (was: Let's enable AppArmor by default (why not?))
Hi,
A year ago, intrigeri proposed an experiment: let's enable AppArmor by
default in testing/sid.
Here is an extract from the proposal (you can find the full proposal and
the thread at [0]):
> tl;dr: I hereby propose we enable AppArmor by default in testing/sid,
> and decide one year later if we want to keep it this way in the
> Buster release.
>
> My goals when initiating this discussion are:
>
> - Get a rough idea of what amount of effort the Debian project is
> happy (and able) to invest into such proactive security measures.
>
> - Learn about any relevant social & technical concerns I am not
> aware of.
>
> I don't expect we'll make a decision based on this very proposal:
> I expect the proposal will need to be refined, or abandoned, to take
> into account what we will learn during this preliminary discussion.
>
> Why do we need AppArmor?
> ========================
>
> AppArmor is a Mandatory Access Control framework implemented as
> a Linux Security Module (LSM), user space utilities, and a quite
> simple language to define policy.
>
> AppArmor confines programs according to a set of rules that specify
> what operations a given program can access, e.g. it can prevent
> exploited server software from accessing data it does not own and
> executing arbitrary code. This proactive approach helps protect the
> system against some known and unknown vulnerabilities.
>
> Various actors are actively exploiting software. Random users are
> victimized every day, and specific populations are specifically
> targeted, e.g. government opponents, human rights defenders, system
> administrators, software developers and distributors, as revealed by
> the Snowden leaks.
>
> Every month we learn about many new attack vectors made possible by
> programming errors. We fix them after the fact, which is great but
> a bit too late: users may already have been exploited. Most operating
> systems have adopted proactive approaches to mitigate the impact of
> such problems.
>
> In Debian, great efforts are in progress: hardening binaries makes it
> harder to write successful exploits, and making our packages build
> reproducibly will make it harder to introduce vulnerabilities at the
> binary level.
>
> Still, Debian is far from being best in class on this front: we have
> no widespread mechanism for sandboxing desktop applications. We can
> surely do better. The great news is that there is one low-hanging
> fruit waiting to be picked, and it's what this proposal is about :)
>
> A proposal
> ==========
>
> 1. Enable AppArmor by default in testing/sid as soon as feasible in
> the Buster cycle.
>
> I can think of several possible ways to do it but for now I'd
> rather focus on the "do we want to do it at all" conversation.
>
> If curious some options are listed on the wiki:
> https://wiki.debian.org/AppArmor/Progress#Enabling_AppArmor_by_default.3F
> Feel free to discuss them on <pkg-apparmor-team@lists.alioth.debian.org>.
>
> And anyway, you can already opt-in for AppArmor on your system today:
> https://wiki.debian.org/AppArmor/HowToUse :)
>
>
> 2. During a year, watch out for AppArmor related issues and address
> them in a prompt manner.
>
> Note that the best way to address them quickly enough is sometimes
> to simply disable the problematic AppArmor profile: it's cheap,
> doesn't require advanced AppArmor skills, and IMO a smaller
> AppArmor policy enabled by default is more useful than a broader
> but less robust one that only a couple thousand users benefit from.
>
> 3. A year after AppArmor was enabled by default: evaluate how it went
> and decide if Buster should be shipped with AppArmor enabled by
> default or not.
>
> I commit to do an analysis using BTS data to help make this
> decision. If we need formal success criteria and a clearly defined
> team who'll make the call, I'm happy to think about it. But here
> again I'd rather focus on the general idea than on implementation
> details at this point.
So, this is just a heads up for people attending Debconf18 in Hsinchu:
there is a BoF this afternoon [1] were we would like *you* to share your
feelings about it, be they positive or negative, and share skills, tips
and tricks.
Please, come and join us in room Xueshan (雪山) at 16:00 if you're
interested: we're very excited about it!
[0] https://lists.debian.org/debian-devel/2017/08/msg00090.html
[1]
https://debconf18.debconf.org/talks/32-apparmor-in-debian-lets-share-feelings-technical-feedback-and-skills/
Cheers,
--
nodens
Reply to: