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-t...@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
