Let's enable AppArmor by default (why not?)
196 views
Skip to first unread message
intrigeri
Aug 4, 2017, 7:40:05 PM8/4/17
to
Hi!
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-appa...@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.
Questions and Answers
=====================
Table of contents:
- What's the benefit, exactly?
- What do other distributions do?
- What's the history of AppArmor in Debian?
- How popular is AppArmor in Debian?
- What's the cost for Debian users?
- What's the cost for package maintainers?
- Is the Debian AppArmor team strong enough to support this change?
- Why AppArmor and not SELinux?
- Why AppArmor and not sandboxing based on XYZ?
- Will this prevent users from using another Linux Security Module?
- What does upstream look like?
- How much will we depend on Canonical's business priorities?
- No thanks: I've tried AppArmor and it broke stuff too often
- Doesn't AppArmor need out-of-tree kernel patches?
- How can I help?
- Credits
What's the benefit, exactly?
----------------------------
Before we even bother looking at the cost of enabling AppArmor by
default, let's look closer at the expected benefit. In other words:
what kind of attacks does AppArmor really mitigate or prevent in the
real world?
tl;dr: big benefit for server software, and for desktop applications
limited to less sophisticated, non-targeted attacks (but it'll get
better).
AppArmor is well suited to protect against remote exploitation of
security issues in server software and non-GUI programs often run with
elevated privileges (think of dhclient, ping, tcpdump). I'm sure one
could identify a few serious issues that would have been mitigated or
prevented by our current AppArmor policy, by looking at a list of
DSA/CVE. Also, one gets interesting security properties when software
is tuned for AppArmor: e.g. a given libvirt/QEMU virtual machine can
only access its assigned storage volumes, and not other VMs'; this is
useful against QEMU security issues that allow guests to escape the
virtualization layer.
On the desktop, to be honest things look pretty bad *currently*:
AppArmor is not enough, and we need new concepts and technologies to
fix serious limitations on the desktop sandboxing front.
Thankfully this is being actively worked on and the future of desktop
sandboxing on GNU/Linux looks bright and shiny! Some of the future
options rely on AppArmor, some others don't. See the "Why AppArmor and
not sandboxing based on XYZ?" section below.
Still, confining desktop apps with AppArmor has benefit against
scripted or non-targeted attacks: it will mitigate some attacks and
others will get through. So while it's probably not worth starting to
write lots of new policy for GUI applications now, I think that
leveraging the existing one will already serve our users.
What do other distributions do?
-------------------------------
AppArmor has been enabled by default in several other GNU/Linux
distributions and Debian derivatives for a while:
* in openSUSE + SLES since 2006
* in Ubuntu since 2008, with a growing policy:
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/AppArmorProfiles
* in Tails, since 2014 for a few important services (CUPS, Tor) and
a few desktop applications (e.g. Totem, Evince, Pidgin, Tor
Browser, Thunderbird)
* in a few other Debian derivatives (Whonix, Subgraph OS) for at
least a couple years.
What's the history of AppArmor in Debian?
-----------------------------------------
AppArmor has been available (opt-in) in Debian since 2011. In 2014
a Debian AppArmor packaging team was created, that has been taking
care of the AppArmor packages and policy since then.
In the last 3 years the AppArmor policy shipped in Debian was extended
substantially and its coverage is now on par with Ubuntu's. It's still
rather small due to the strategy we chose: we wanted to avoid
traumatizing early adopters and to avoid creating a culture of
"AppArmor always breaks stuff, let's get used to disabling it".
So like Ubuntu and openSUSE, we're shipping a rather small and mature
AppArmor policy. I believe this strategy has been successful so far,
and even some non-trivial pieces of software like Thunderbird now ship
an AppArmor policy; but of course it has one drawback: most software,
including web browsers, is not confined with AppArmor whatsoever.
Surely with more people contributing to our AppArmor policy we could
have it cover other important pieces of software; time will tell.
A number of maintainers accepted shipping AppArmor policy in their own
package. If you're one of them, please consider providing feedback
about how it went for you.
How popular is AppArmor in Debian?
----------------------------------
tl;dr: AppArmor has steadily become more and more popular in Debian in
the last few years. I think the user base has reached a critical mass
that proves it works OK.
Here's what popcon says ("Vote" count) for the apparmor binary
package, that's needed to use AppArmor:
* 2015-01: ~400
* 2016-01: ~700 (+75% in a year)
* 2017-01: ~1300 (+85% in a year)
* today: 1870 (+44% in 7 months)
But we have no way to tell whether a user who has AppArmor packages
installed actually enabled the AppArmor LSM, so the data for
apparmor-profiles-extra might be more useful here: I expect that only
users who really want to use AppArmor with an extended policy would
bother installing it. This one has 435 registered installations
("Vote" has always been 0 for some reason that I did not investigate);
it was introduced in October 2014, and since then its popcon stats
have been steadily increasing.
What's the cost for Debian users?
---------------------------------
AppArmor unavoidably breaks functionality from time to time: e.g.
new versions of software we package (or of their dependencies)
regularly start needing access to new file locations.
And then users see broken applications from time to time, after
upgrading their testing/sid system. This is to be taken seriously, but
not a big concern IMO:
- Apparently Ubuntu users have been coping with AppArmor enforced
by default for 9 years. I see no reason why Debian users would not.
- I've counted 14 bugs bugs reported in the Debian BTS during the
Stretch development cycle against our supported AppArmor policy.
Among those, 11 were closed (106 days after being reported on
average); all the important ones were closed within 2 months;
larger delays were due to users developing fixes and/or upstream
taking some time to review merge requests. About the 3 bugs still
open: one is waiting for input from other package maintainers since
2 years, another one had a patch waiting to be applied, and the
last one needs to be fixed in libvirt upstream.
- Serious breakage is less likely to happen once AppArmor is enabled
by default, as there are greater chances that the maintainer would
have noticed it before uploading.
- Workarounds are regularly suggested to the bug reporter on the BTS,
and in many cases the bug reporter documents in the bug report the
workaround they have *already* applied.
Implementing a suggested workarounds requires being able to edit
a text file and running one command as root, which should be doable
by the vast majority of testing/sid users.
What's the cost for package maintainers?
----------------------------------------
For most of them: none at all. As said earlier, our AppArmor policy
does not cover that much software yet.
But maintainers of software confined by AppArmor will have to deal
with a new kind of bug reports, whose number is likely to grow
significantly once AppArmor is enabled by default. This means they
have to:
1. identify if a bug report can possibly be related to AppArmor;
2. either learn how to debug AppArmor issues themselves, or ask the
pkg-apparmor team for help (thanks to usertags:
https://wiki.debian.org/AppArmor/Reportbug#Usertags).
I expect that initially pkg-apparmor will need to provide help in many
cases, but over time the affected maintainers will slowly learn just
enough about AppArmor to handle at least the simplest cases
themselves, just like it happened in Ubuntu years ago.
Is the Debian AppArmor team strong enough to support this change?
-----------------------------------------------------------------
This is a valid concern, as I have been doing the greatest part of the
work on this team.
So far I've found my AppArmor-related workload totally sustainable:
it took me just a few hours here and there, and I would be doing this
work for Tails anyway, so better do it directly in Debian. Still,
primarily relying on one single person is concerning.
Thankfully, a number of other people have been contributing in various
ways. A few Debian users and contributors got used to reporting bugs
and contribute improvements to our AppArmor policy upstream.
Another team member uploaded src:apparmor once. Ulrike Uhlig wrote
documentation about AppArmor for Debian users and
contributors during an Outreachy project whose outcome was posted to
debian-devel-announce in March, 2015.
Also, just like any such distro-wide change, I expect the amount of
work required to support the broader project:
- will be large initially; I'm confident that the current state of
our team is good enough to support the project during the first
stage of the transition;
- will only decrease over time, as Debian people get used to it and
learn the small bits they need to know about the new technology,
and eventually the cases when our AppArmor team has to give a hand
will become rare;
- will be done by AppArmor people from other distributions as well:
a few of them actively participate on the pkg-apparmor mailing list
and help on issues reported in the Debian BTS.
So I think it's totally reasonable to give it a try.
Why AppArmor and not SELinux?
-----------------------------
SELinux is another LSM that tackles similar problems.
Disclaimer: I've picked AppArmor years ago and didn't look much at
SELinux recently, so some of what follows may be totally wrong or
outdated. Sorry! Debian SELinux people, if you don't mind please help
me get the basic facts right :)
Pros:
* Allows mediating more kernel objects / interfaces than AppArmor, so
policy can be made stricter and safer given sufficient expertise
and available time for maintenance.
* Enabled by default in RHEL so in theory a great number of sysadmins
are at ease with it (see below why reality may not match this).
* A quick look at popcon suggests that SELinux might be more popular
in Debian than AppArmor, but I'm not sure I am interpreting the
numbers right (and I suspect that just like AppArmor, the popcon
won't tell us if users who have installed the relevant support
packages actually run their system with the corresponding LSM
enabled & enforced).
Cons:
* Writing, maintaining, auditing and debugging SELinux policy
requires grasping a complex conceptual model; I am told this is not
as easy as doing the same with AppArmor.
* As far as I could understand when chatting with sysadmins of Red
Hat systems, this has resulted in a culture where many users got
used to disable SELinux entirely on their systems, instead of
trying to fix the buggy policy. I've seen the opposite happen with
AppArmor, which is good: for example, pretty often bug reporters to
the Debian BTS document themselves how they could workaround the
problem locally *without* turning AppArmor off. Looking at open
bugs in the BTS against src:refpolicy, this seems to happen very
rarely for SELinux, so I wonder if it would be realistic to ship
Debian with SELinux enforced by default and have our community
support it.
* https://wiki.debian.org/SELinux/Issues says "Graphical/Desktop
installs of Debian are not heavily tested with selinux, so you
might run into quite some issues".
* I'm not aware of any Debian derivative shipping with SELinux
enabled by default. If that's correct, then it means that we would
have to deal with quite some policy compatibility issues ourselves.
To me, the complexity of SELinux is a deal breaker: it seems that we
would need to get lots more expertise and energy to enforce SELinux by
default than doing the same with AppArmor.
Now, if for some reason the project prefers to ship with SELinux
enforced instead of AppArmor, fine by me: I would strongly prefer this
option to nothing at all.
Why AppArmor and not sandboxing based on XYZ?
---------------------------------------------
(Replace "XYZ" with Flatpak, Ubuntu's Snappy, Subgraph OS' oz,
Firejail, Subuser, or you preferred other promising option.)
We need both!
AppArmor covers server software well, and on the desktop it currently
protects against not-too-sophisticated, non-targeted attacks.
In a nutshell, the GNU/Linux desktop really wasn't designed for
applications to be siloed. To fix that we need new concepts and
technologies, such as Wayland, portals, and fine-grained D-Bus
mediation. Next generation desktop sandboxing technologies will fix
this and improve UX at the same time, and it will be amazing. But they
are not ready for prime-time yet. A Debian user cannot benefit from
them *today* much; this might change in time for Buster, but really
we're comparing a well-established, polished solution with a bunch of
other ones whose integration with Debian is being brainstormed.
Anyway, this is not an either/or situation: even though there are
currently compatibility issues, one can perfectly well develop/adapt
such tools in a way that makes them work fine with AppArmor enabled.
Let's enable AppArmor so we cover at least the server use case and the
low-hanging fruits of the desktop one, and figure out later where we
should put our efforts for securing the desktop, once the dust has
settled and next generation solutions have matured and been integrated
in Debian.
Will this prevent users from using another Linux Security Module?
-----------------------------------------------------------------
Some "minor" Linux Security Modules, such as Yama, live perfectly well
with others.
But currently it is not possible to enable several of the major
security modules. There's been (slow) work in progress to fix this for
a while, but it has picked up recently and there is a lot of interest
to have, say, AppArmor and SELinux stackable:
https://lwn.net/Articles/719731/
Now, every user will still be able to opt-out from AppArmor and
instead enable their preferred LSM.
What does upstream look like?
-----------------------------
The upstream project is almost 20 years old, very mature and
cooperative with Debian. E.g. the upstream release schedule has been
adjusted both for Jessie and Stretch to accommodate Debian's
schedule nicely.
Regarding who does the work:
- Canonical employees do most of the kernel work. They also maintain
the library and other C code, e.g. the policy parser.
- The Python utilities are primarily maintained by openSUSE's
Christian Boltz.
- Maintaining AppArmor policy is a cross-distro team effort, mostly
done by Debian, Ubuntu and openSUSE people.
How much will we depend on Canonical's business priorities?
-----------------------------------------------------------
Given Canonical employees do the greatest part of the work upstream:
indeed, we will. I see two main concerns about this:
Long-term reliability: this funding could run out some day.
I personally am not overly concerned, as Canonical has been investing
a lot into products (Snappy, LXC/LXD) that strongly depend on AppArmor
in the last few years.
Power imbalance: the company that does so much of the work has great
power over the priorities of the upstream project. This is the case
for a large amount of critical software we ship, so like it or not, it
is something we are living with already. AppArmor developers employed
by Canonical have shown great willingness in cooperating with Debian
in the last few years, so I'm confident that our contributions will be
welcome for the foreseeable future, whenever we need to adapt the
software to our needs. But of course management/business decisions can
change this at any time.
No thanks: I've tried AppArmor and it broke stuff too often
-----------------------------------------------------------
Sorry about that. I think this has had three main causes so far, that
all share one single root cause i.e. "AppArmor is not enabled by
default" (chicken'n'egg!):
1. Most package maintainers don't test packages with AppArmor before
uploading, so users notice breakage that could easily be avoided.
2. The huge majority of our users are not affected by breakage caused
by AppArmor, so we handle such breakage in a way that saves
maintainers' time: e.g. in many cases I've personally preferred to
wait for my fixes to AppArmor profiles to be approved and merged
upstream before applying them in Debian.
Once AppArmor is enabled by default, as far as I'm concerned
I don't plan to wait for upstream review before fixing regressions
in testing/sid.
3. The huge majority of our users are not affected by breakage caused
by AppArmor, so such breakage was kinda acceptable and thus we
*sometimes* preferred to give a specific AppArmor profile more
exposure to testers, even if it had a couple known issues, in order
to identify problems and help stabilize it (e.g. Tor, libvirt).
I think we will need to be more conservative once AppArmor is
enabled by default, i.e. profiles that break functionality too much
or too often should not be enabled by default.
Doesn't AppArmor need out-of-tree kernel patches?
-------------------------------------------------
Yes and no.
Historically, the mainline Linux kernel has supported a rather small
subset of the AppArmor mediation made possible by the out-of-tree
kernel patch. This made the value of enabling AppArmor smaller than it
could be (e.g. LXC is not well confined in Debian: #750106), and
smaller than it is in distros that apply the out-of-tree kernel patch
(such as Ubuntu).
Still, even with the set of features available in mainline Linux
*today*, IMO enabling AppArmor already has a good cost/benefit ratio
for Debian and our users. I'm not proposing we apply out-of-tree
AppArmor kernel patches.
Thankfully, the AppArmor kernel developers recently changed how they
proceed: new features are now added to Linux mainline before they
reach Ubuntu, so I'm confident that this situation will get better and
better in the future, and Buster's kernel will support tons of new
AppArmor mediation types compared to Stretch.
How can I help?
---------------
* Enable AppArmor on your Debian systems:
https://wiki.debian.org/AppArmor/HowToUse
* If you maintain a package for which we ship AppArmor policy in
Debian: test it with AppArmor enabled before uploading.
Ask for help if needed:
https://wiki.debian.org/AppArmor/Reportbug#Usertags
* Join the team:
https://wiki.debian.org/AppArmor/Contribute
* Talk to us:
<pkg-appa...@lists.alioth.debian.org>
Credits
-------
A huge thank you to the people who reviewed this text, provided
valuable input that I took into account & integrated, and helped me
change my mind here and there: Christian Boltz, gregoa, Guido Günther,
Jamie Strandboge, John Johansen, Sebastien Delafond, Simon McVittie
and Solveig! Sorry to those I forgot. I shamelessly stole bits of text
they wrote. I absolutely do *not* imply they endorse this proposal.
Thanks a lot to my pkg-apparmor team-mates, to Kees Cook who
introduced AppArmor in Debian in the first place, and to all AppArmor
contributors upstream and in other distros :)
Cheers,
--
intrigeri
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-appa...@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.
Questions and Answers
=====================
Table of contents:
- What's the benefit, exactly?
- What do other distributions do?
- What's the history of AppArmor in Debian?
- How popular is AppArmor in Debian?
- What's the cost for Debian users?
- What's the cost for package maintainers?
- Is the Debian AppArmor team strong enough to support this change?
- Why AppArmor and not SELinux?
- Why AppArmor and not sandboxing based on XYZ?
- Will this prevent users from using another Linux Security Module?
- What does upstream look like?
- How much will we depend on Canonical's business priorities?
- No thanks: I've tried AppArmor and it broke stuff too often
- Doesn't AppArmor need out-of-tree kernel patches?
- How can I help?
- Credits
What's the benefit, exactly?
----------------------------
Before we even bother looking at the cost of enabling AppArmor by
default, let's look closer at the expected benefit. In other words:
what kind of attacks does AppArmor really mitigate or prevent in the
real world?
tl;dr: big benefit for server software, and for desktop applications
limited to less sophisticated, non-targeted attacks (but it'll get
better).
AppArmor is well suited to protect against remote exploitation of
security issues in server software and non-GUI programs often run with
elevated privileges (think of dhclient, ping, tcpdump). I'm sure one
could identify a few serious issues that would have been mitigated or
prevented by our current AppArmor policy, by looking at a list of
DSA/CVE. Also, one gets interesting security properties when software
is tuned for AppArmor: e.g. a given libvirt/QEMU virtual machine can
only access its assigned storage volumes, and not other VMs'; this is
useful against QEMU security issues that allow guests to escape the
virtualization layer.
On the desktop, to be honest things look pretty bad *currently*:
AppArmor is not enough, and we need new concepts and technologies to
fix serious limitations on the desktop sandboxing front.
Thankfully this is being actively worked on and the future of desktop
sandboxing on GNU/Linux looks bright and shiny! Some of the future
options rely on AppArmor, some others don't. See the "Why AppArmor and
not sandboxing based on XYZ?" section below.
Still, confining desktop apps with AppArmor has benefit against
scripted or non-targeted attacks: it will mitigate some attacks and
others will get through. So while it's probably not worth starting to
write lots of new policy for GUI applications now, I think that
leveraging the existing one will already serve our users.
What do other distributions do?
-------------------------------
AppArmor has been enabled by default in several other GNU/Linux
distributions and Debian derivatives for a while:
* in openSUSE + SLES since 2006
* in Ubuntu since 2008, with a growing policy:
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/AppArmorProfiles
* in Tails, since 2014 for a few important services (CUPS, Tor) and
a few desktop applications (e.g. Totem, Evince, Pidgin, Tor
Browser, Thunderbird)
* in a few other Debian derivatives (Whonix, Subgraph OS) for at
least a couple years.
What's the history of AppArmor in Debian?
-----------------------------------------
AppArmor has been available (opt-in) in Debian since 2011. In 2014
a Debian AppArmor packaging team was created, that has been taking
care of the AppArmor packages and policy since then.
In the last 3 years the AppArmor policy shipped in Debian was extended
substantially and its coverage is now on par with Ubuntu's. It's still
rather small due to the strategy we chose: we wanted to avoid
traumatizing early adopters and to avoid creating a culture of
"AppArmor always breaks stuff, let's get used to disabling it".
So like Ubuntu and openSUSE, we're shipping a rather small and mature
AppArmor policy. I believe this strategy has been successful so far,
and even some non-trivial pieces of software like Thunderbird now ship
an AppArmor policy; but of course it has one drawback: most software,
including web browsers, is not confined with AppArmor whatsoever.
Surely with more people contributing to our AppArmor policy we could
have it cover other important pieces of software; time will tell.
A number of maintainers accepted shipping AppArmor policy in their own
package. If you're one of them, please consider providing feedback
about how it went for you.
How popular is AppArmor in Debian?
----------------------------------
tl;dr: AppArmor has steadily become more and more popular in Debian in
the last few years. I think the user base has reached a critical mass
that proves it works OK.
Here's what popcon says ("Vote" count) for the apparmor binary
package, that's needed to use AppArmor:
* 2015-01: ~400
* 2016-01: ~700 (+75% in a year)
* 2017-01: ~1300 (+85% in a year)
* today: 1870 (+44% in 7 months)
But we have no way to tell whether a user who has AppArmor packages
installed actually enabled the AppArmor LSM, so the data for
apparmor-profiles-extra might be more useful here: I expect that only
users who really want to use AppArmor with an extended policy would
bother installing it. This one has 435 registered installations
("Vote" has always been 0 for some reason that I did not investigate);
it was introduced in October 2014, and since then its popcon stats
have been steadily increasing.
What's the cost for Debian users?
---------------------------------
AppArmor unavoidably breaks functionality from time to time: e.g.
new versions of software we package (or of their dependencies)
regularly start needing access to new file locations.
And then users see broken applications from time to time, after
upgrading their testing/sid system. This is to be taken seriously, but
not a big concern IMO:
- Apparently Ubuntu users have been coping with AppArmor enforced
by default for 9 years. I see no reason why Debian users would not.
- I've counted 14 bugs bugs reported in the Debian BTS during the
Stretch development cycle against our supported AppArmor policy.
Among those, 11 were closed (106 days after being reported on
average); all the important ones were closed within 2 months;
larger delays were due to users developing fixes and/or upstream
taking some time to review merge requests. About the 3 bugs still
open: one is waiting for input from other package maintainers since
2 years, another one had a patch waiting to be applied, and the
last one needs to be fixed in libvirt upstream.
- Serious breakage is less likely to happen once AppArmor is enabled
by default, as there are greater chances that the maintainer would
have noticed it before uploading.
- Workarounds are regularly suggested to the bug reporter on the BTS,
and in many cases the bug reporter documents in the bug report the
workaround they have *already* applied.
Implementing a suggested workarounds requires being able to edit
a text file and running one command as root, which should be doable
by the vast majority of testing/sid users.
What's the cost for package maintainers?
----------------------------------------
For most of them: none at all. As said earlier, our AppArmor policy
does not cover that much software yet.
But maintainers of software confined by AppArmor will have to deal
with a new kind of bug reports, whose number is likely to grow
significantly once AppArmor is enabled by default. This means they
have to:
1. identify if a bug report can possibly be related to AppArmor;
2. either learn how to debug AppArmor issues themselves, or ask the
pkg-apparmor team for help (thanks to usertags:
https://wiki.debian.org/AppArmor/Reportbug#Usertags).
I expect that initially pkg-apparmor will need to provide help in many
cases, but over time the affected maintainers will slowly learn just
enough about AppArmor to handle at least the simplest cases
themselves, just like it happened in Ubuntu years ago.
Is the Debian AppArmor team strong enough to support this change?
-----------------------------------------------------------------
This is a valid concern, as I have been doing the greatest part of the
work on this team.
So far I've found my AppArmor-related workload totally sustainable:
it took me just a few hours here and there, and I would be doing this
work for Tails anyway, so better do it directly in Debian. Still,
primarily relying on one single person is concerning.
Thankfully, a number of other people have been contributing in various
ways. A few Debian users and contributors got used to reporting bugs
and contribute improvements to our AppArmor policy upstream.
Another team member uploaded src:apparmor once. Ulrike Uhlig wrote
documentation about AppArmor for Debian users and
contributors during an Outreachy project whose outcome was posted to
debian-devel-announce in March, 2015.
Also, just like any such distro-wide change, I expect the amount of
work required to support the broader project:
- will be large initially; I'm confident that the current state of
our team is good enough to support the project during the first
stage of the transition;
- will only decrease over time, as Debian people get used to it and
learn the small bits they need to know about the new technology,
and eventually the cases when our AppArmor team has to give a hand
will become rare;
- will be done by AppArmor people from other distributions as well:
a few of them actively participate on the pkg-apparmor mailing list
and help on issues reported in the Debian BTS.
So I think it's totally reasonable to give it a try.
Why AppArmor and not SELinux?
-----------------------------
SELinux is another LSM that tackles similar problems.
Disclaimer: I've picked AppArmor years ago and didn't look much at
SELinux recently, so some of what follows may be totally wrong or
outdated. Sorry! Debian SELinux people, if you don't mind please help
me get the basic facts right :)
Pros:
* Allows mediating more kernel objects / interfaces than AppArmor, so
policy can be made stricter and safer given sufficient expertise
and available time for maintenance.
* Enabled by default in RHEL so in theory a great number of sysadmins
are at ease with it (see below why reality may not match this).
* A quick look at popcon suggests that SELinux might be more popular
in Debian than AppArmor, but I'm not sure I am interpreting the
numbers right (and I suspect that just like AppArmor, the popcon
won't tell us if users who have installed the relevant support
packages actually run their system with the corresponding LSM
enabled & enforced).
Cons:
* Writing, maintaining, auditing and debugging SELinux policy
requires grasping a complex conceptual model; I am told this is not
as easy as doing the same with AppArmor.
* As far as I could understand when chatting with sysadmins of Red
Hat systems, this has resulted in a culture where many users got
used to disable SELinux entirely on their systems, instead of
trying to fix the buggy policy. I've seen the opposite happen with
AppArmor, which is good: for example, pretty often bug reporters to
the Debian BTS document themselves how they could workaround the
problem locally *without* turning AppArmor off. Looking at open
bugs in the BTS against src:refpolicy, this seems to happen very
rarely for SELinux, so I wonder if it would be realistic to ship
Debian with SELinux enforced by default and have our community
support it.
* https://wiki.debian.org/SELinux/Issues says "Graphical/Desktop
installs of Debian are not heavily tested with selinux, so you
might run into quite some issues".
* I'm not aware of any Debian derivative shipping with SELinux
enabled by default. If that's correct, then it means that we would
have to deal with quite some policy compatibility issues ourselves.
To me, the complexity of SELinux is a deal breaker: it seems that we
would need to get lots more expertise and energy to enforce SELinux by
default than doing the same with AppArmor.
Now, if for some reason the project prefers to ship with SELinux
enforced instead of AppArmor, fine by me: I would strongly prefer this
option to nothing at all.
Why AppArmor and not sandboxing based on XYZ?
---------------------------------------------
(Replace "XYZ" with Flatpak, Ubuntu's Snappy, Subgraph OS' oz,
Firejail, Subuser, or you preferred other promising option.)
We need both!
AppArmor covers server software well, and on the desktop it currently
protects against not-too-sophisticated, non-targeted attacks.
In a nutshell, the GNU/Linux desktop really wasn't designed for
applications to be siloed. To fix that we need new concepts and
technologies, such as Wayland, portals, and fine-grained D-Bus
mediation. Next generation desktop sandboxing technologies will fix
this and improve UX at the same time, and it will be amazing. But they
are not ready for prime-time yet. A Debian user cannot benefit from
them *today* much; this might change in time for Buster, but really
we're comparing a well-established, polished solution with a bunch of
other ones whose integration with Debian is being brainstormed.
Anyway, this is not an either/or situation: even though there are
currently compatibility issues, one can perfectly well develop/adapt
such tools in a way that makes them work fine with AppArmor enabled.
Let's enable AppArmor so we cover at least the server use case and the
low-hanging fruits of the desktop one, and figure out later where we
should put our efforts for securing the desktop, once the dust has
settled and next generation solutions have matured and been integrated
in Debian.
Will this prevent users from using another Linux Security Module?
-----------------------------------------------------------------
Some "minor" Linux Security Modules, such as Yama, live perfectly well
with others.
But currently it is not possible to enable several of the major
security modules. There's been (slow) work in progress to fix this for
a while, but it has picked up recently and there is a lot of interest
to have, say, AppArmor and SELinux stackable:
https://lwn.net/Articles/719731/
Now, every user will still be able to opt-out from AppArmor and
instead enable their preferred LSM.
What does upstream look like?
-----------------------------
The upstream project is almost 20 years old, very mature and
cooperative with Debian. E.g. the upstream release schedule has been
adjusted both for Jessie and Stretch to accommodate Debian's
schedule nicely.
Regarding who does the work:
- Canonical employees do most of the kernel work. They also maintain
the library and other C code, e.g. the policy parser.
- The Python utilities are primarily maintained by openSUSE's
Christian Boltz.
- Maintaining AppArmor policy is a cross-distro team effort, mostly
done by Debian, Ubuntu and openSUSE people.
How much will we depend on Canonical's business priorities?
-----------------------------------------------------------
Given Canonical employees do the greatest part of the work upstream:
indeed, we will. I see two main concerns about this:
Long-term reliability: this funding could run out some day.
I personally am not overly concerned, as Canonical has been investing
a lot into products (Snappy, LXC/LXD) that strongly depend on AppArmor
in the last few years.
Power imbalance: the company that does so much of the work has great
power over the priorities of the upstream project. This is the case
for a large amount of critical software we ship, so like it or not, it
is something we are living with already. AppArmor developers employed
by Canonical have shown great willingness in cooperating with Debian
in the last few years, so I'm confident that our contributions will be
welcome for the foreseeable future, whenever we need to adapt the
software to our needs. But of course management/business decisions can
change this at any time.
No thanks: I've tried AppArmor and it broke stuff too often
-----------------------------------------------------------
Sorry about that. I think this has had three main causes so far, that
all share one single root cause i.e. "AppArmor is not enabled by
default" (chicken'n'egg!):
1. Most package maintainers don't test packages with AppArmor before
uploading, so users notice breakage that could easily be avoided.
2. The huge majority of our users are not affected by breakage caused
by AppArmor, so we handle such breakage in a way that saves
maintainers' time: e.g. in many cases I've personally preferred to
wait for my fixes to AppArmor profiles to be approved and merged
upstream before applying them in Debian.
Once AppArmor is enabled by default, as far as I'm concerned
I don't plan to wait for upstream review before fixing regressions
in testing/sid.
3. The huge majority of our users are not affected by breakage caused
by AppArmor, so such breakage was kinda acceptable and thus we
*sometimes* preferred to give a specific AppArmor profile more
exposure to testers, even if it had a couple known issues, in order
to identify problems and help stabilize it (e.g. Tor, libvirt).
I think we will need to be more conservative once AppArmor is
enabled by default, i.e. profiles that break functionality too much
or too often should not be enabled by default.
Doesn't AppArmor need out-of-tree kernel patches?
-------------------------------------------------
Yes and no.
Historically, the mainline Linux kernel has supported a rather small
subset of the AppArmor mediation made possible by the out-of-tree
kernel patch. This made the value of enabling AppArmor smaller than it
could be (e.g. LXC is not well confined in Debian: #750106), and
smaller than it is in distros that apply the out-of-tree kernel patch
(such as Ubuntu).
Still, even with the set of features available in mainline Linux
*today*, IMO enabling AppArmor already has a good cost/benefit ratio
for Debian and our users. I'm not proposing we apply out-of-tree
AppArmor kernel patches.
Thankfully, the AppArmor kernel developers recently changed how they
proceed: new features are now added to Linux mainline before they
reach Ubuntu, so I'm confident that this situation will get better and
better in the future, and Buster's kernel will support tons of new
AppArmor mediation types compared to Stretch.
How can I help?
---------------
* Enable AppArmor on your Debian systems:
https://wiki.debian.org/AppArmor/HowToUse
* If you maintain a package for which we ship AppArmor policy in
Debian: test it with AppArmor enabled before uploading.
Ask for help if needed:
https://wiki.debian.org/AppArmor/Reportbug#Usertags
* Join the team:
https://wiki.debian.org/AppArmor/Contribute
* Talk to us:
<pkg-appa...@lists.alioth.debian.org>
Credits
-------
A huge thank you to the people who reviewed this text, provided
valuable input that I took into account & integrated, and helped me
change my mind here and there: Christian Boltz, gregoa, Guido Günther,
Jamie Strandboge, John Johansen, Sebastien Delafond, Simon McVittie
and Solveig! Sorry to those I forgot. I shamelessly stole bits of text
they wrote. I absolutely do *not* imply they endorse this proposal.
Thanks a lot to my pkg-apparmor team-mates, to Kees Cook who
introduced AppArmor in Debian in the first place, and to all AppArmor
contributors upstream and in other distros :)
Cheers,
--
intrigeri
Niels Thykier
Aug 5, 2017, 3:00:02 AM8/5/17
to
intrigeri:
Hi,
Overall, this sounds like an interesting proposal and personally, I
agree that I think the Debian Linux ports would be better off with an
LSM enabled by default.
> What's the cost for Debian users?
> ---------------------------------
>
> AppArmor unavoidably breaks functionality from time to time: e.g.
> new versions of software we package (or of their dependencies)
> regularly start needing access to new file locations.
s/AppArmor/Any LSM/
Can we integrate these LSM policies into our testing frameworks (e.g.
autopkgtests), so we can start having automated tests of even basic
functionality. Or will that happen "out of the box" if we enable it by
default (and, possibly, enable it on our test hosts)?
Thanks,
~Niels
Hi,
Overall, this sounds like an interesting proposal and personally, I
agree that I think the Debian Linux ports would be better off with an
LSM enabled by default.
> What's the cost for Debian users?
> ---------------------------------
>
> AppArmor unavoidably breaks functionality from time to time: e.g.
> new versions of software we package (or of their dependencies)
> regularly start needing access to new file locations.
Can we integrate these LSM policies into our testing frameworks (e.g.
autopkgtests), so we can start having automated tests of even basic
functionality. Or will that happen "out of the box" if we enable it by
default (and, possibly, enable it on our test hosts)?
Thanks,
~Niels
Simon McVittie
Aug 5, 2017, 6:40:03 AM8/5/17
to
On Sat, 05 Aug 2017 at 06:50:00 +0000, Niels Thykier wrote:
> Can we integrate these LSM policies into our testing frameworks (e.g.
> autopkgtests), so we can start having automated tests of even basic
> functionality. Or will that happen "out of the box" if we enable it by
> default (and, possibly, enable it on our test hosts)?
In practice probably only if our test hosts change from being lxc
> Can we integrate these LSM policies into our testing frameworks (e.g.
> autopkgtests), so we can start having automated tests of even basic
> functionality. Or will that happen "out of the box" if we enable it by
> default (and, possibly, enable it on our test hosts)?
containers to being full virtual machines, which would be good for
other aspects of test coverage too (flatpak/bubblewrap currently skip
many of their autopkgtests, and so does debootstrap).
AppArmor has some amount of support for being used inside a privileged
lxc container, but it's very new and I'm not sure it's going to be a
particularly accurate representation of what would happen on real
hardware. (One of my colleagues looked at lxc + apparmor recently and
was able to make it work, but not trivially.)
S
Antonio Terceiro
Aug 5, 2017, 12:10:02 PM8/5/17
to
On Sat, Aug 05, 2017 at 11:30:30AM +0100, Simon McVittie wrote:
> On Sat, 05 Aug 2017 at 06:50:00 +0000, Niels Thykier wrote:
> > Can we integrate these LSM policies into our testing frameworks (e.g.
> > autopkgtests), so we can start having automated tests of even basic
> > functionality. Or will that happen "out of the box" if we enable it by
> > default (and, possibly, enable it on our test hosts)?
>
> In practice probably only if our test hosts change from being lxc
> containers to being full virtual machines, which would be good for
> other aspects of test coverage too (flatpak/bubblewrap currently skip
> many of their autopkgtests, and so does debootstrap).
FWIW, my last upload of debci has a prototype qemu backend. I want to
> On Sat, 05 Aug 2017 at 06:50:00 +0000, Niels Thykier wrote:
> > Can we integrate these LSM policies into our testing frameworks (e.g.
> > autopkgtests), so we can start having automated tests of even basic
> > functionality. Or will that happen "out of the box" if we enable it by
> > default (and, possibly, enable it on our test hosts)?
>
> In practice probably only if our test hosts change from being lxc
> containers to being full virtual machines, which would be good for
> other aspects of test coverage too (flatpak/bubblewrap currently skip
> many of their autopkgtests, and so does debootstrap).
switch to that sooner rather than later.
Christoph Biedl
Aug 5, 2017, 12:30:04 PM8/5/17
to
intrigeri wrote...
> 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.
I really appreciate your approach of trying this out while being
prepared this might turn out to be a bad idea. Or: Promoting an idea
without being pushy about it.
So while adding another security layer is certainly something to
consider, I'm as well interested in whether this is feasible for a
generic-purpose distribution like Debian. The worst thing that could
happen was people will have to do the counterpart of chmod 777. Then it
was a bad idea, but we (as in Debian) have substantiation for such a
claim.
Christoph
> 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.
prepared this might turn out to be a bad idea. Or: Promoting an idea
without being pushy about it.
So while adding another security layer is certainly something to
consider, I'm as well interested in whether this is feasible for a
generic-purpose distribution like Debian. The worst thing that could
happen was people will have to do the counterpart of chmod 777. Then it
was a bad idea, but we (as in Debian) have substantiation for such a
claim.
Christoph
Holger Levsen
Aug 5, 2017, 1:10:02 PM8/5/17
to
On Fri, Aug 04, 2017 at 07:31:36PM -0400, intrigeri wrote:
> 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.
loving it, please go ahead! ;-)
> 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.
--
cheers,
Holger
Dr. Bas Wijnen
Aug 6, 2017, 3:30:02 AM8/6/17
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, Aug 05, 2017 at 06:28:20PM +0200, Christoph Biedl wrote:
> intrigeri wrote...
>
> > 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.
>
> [...] while adding another security layer is certainly something to
it makes a lot of sense to enable something like this by default, and in fact I
can't think of a situation where you would not want it, but indeed users should
be able to set their system up without it if they so wish.
> The worst thing that could happen was people will have to do the counterpart
> of chmod 777. Then it was a bad idea, but we (as in Debian) have
> substantiation for such a claim.
Yes, we should certainly avoid that; if it looks like that is happening, we
should abort the operation. But from the well written plan, it sounds to me
like this is unlikely to be the case.
So just to be clear: Yes, please enable AppArmor by default.
Thanks,
Bas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJZhsUHAAoJEJzRfVgHwHE6/WoP/3NHlHKzWd/DPjBV41Tq6WHT
JwRXT7zqbsLa1UlxeRTBhbH82EAFYpn59s7d882/JQ+0MBvp0bcn9t85i2IYBS7K
LruV569kM0jYYGk4MY9BLmo5WlYlmrE7+B/8wc86oLsvi676SJ33dzQUNczt/fJF
SrXUWix2phMjLtHp9v6+OSdxCDnkMLGQX7VYuv7Zz1n0XenbXeQWBVK/8kJdsuPx
+WsojZ5u72n6IhpRQv4tiP0P28G4Bdi1JN4AwQNSqd44bV1bFl+2Em1DJquly/LO
hCVty9BJVuO/s0KdWeXC7raa4vsaiswKohA0GYkDqT8vBrTZ2chBbJNkQrByR7BF
iXp3o/irlpZIp7A7EUBLPfKKTAVk40gLrw/WYraGJ9zH9y/eNly6y7BcjNbzikMe
euOH+GPr6zvLng+KHC8w0qk3/m8FEWkamAmwPDqZVxuubvid00ECRv4WU9X4bvaf
coLYOumS+T0qmlHrLgUlTq8RtRHg6Nqok3DULQpofTWvtCrNDcWXI21YjDp+kNmW
JzlQ3Ja7baZFDHygmWAvG1fXWCIC3Bl3sLxqy9h5+1m0W8PxqPii/BIZjCSbVMu+
P3VRmryhxdLLL/nzt2zX09VtAJwNAKL42UYfh3nlJN5/4LnT2JpCILvktTtNJoym
V8yP+AuLbIo+TcDrqPLn
=fVTR
-----END PGP SIGNATURE-----
Hash: SHA1
On Sat, Aug 05, 2017 at 06:28:20PM +0200, Christoph Biedl wrote:
> intrigeri wrote...
>
> > 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.
>
> consider, I'm as well interested in whether this is feasible for a
> generic-purpose distribution like Debian.
Enabling it by default doesn't mean it can't be switched off, right? I think
> generic-purpose distribution like Debian.
it makes a lot of sense to enable something like this by default, and in fact I
can't think of a situation where you would not want it, but indeed users should
be able to set their system up without it if they so wish.
> The worst thing that could happen was people will have to do the counterpart
> of chmod 777. Then it was a bad idea, but we (as in Debian) have
> substantiation for such a claim.
should abort the operation. But from the well written plan, it sounds to me
like this is unlikely to be the case.
So just to be clear: Yes, please enable AppArmor by default.
Thanks,
Bas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJZhsUHAAoJEJzRfVgHwHE6/WoP/3NHlHKzWd/DPjBV41Tq6WHT
JwRXT7zqbsLa1UlxeRTBhbH82EAFYpn59s7d882/JQ+0MBvp0bcn9t85i2IYBS7K
LruV569kM0jYYGk4MY9BLmo5WlYlmrE7+B/8wc86oLsvi676SJ33dzQUNczt/fJF
SrXUWix2phMjLtHp9v6+OSdxCDnkMLGQX7VYuv7Zz1n0XenbXeQWBVK/8kJdsuPx
+WsojZ5u72n6IhpRQv4tiP0P28G4Bdi1JN4AwQNSqd44bV1bFl+2Em1DJquly/LO
hCVty9BJVuO/s0KdWeXC7raa4vsaiswKohA0GYkDqT8vBrTZ2chBbJNkQrByR7BF
iXp3o/irlpZIp7A7EUBLPfKKTAVk40gLrw/WYraGJ9zH9y/eNly6y7BcjNbzikMe
euOH+GPr6zvLng+KHC8w0qk3/m8FEWkamAmwPDqZVxuubvid00ECRv4WU9X4bvaf
coLYOumS+T0qmlHrLgUlTq8RtRHg6Nqok3DULQpofTWvtCrNDcWXI21YjDp+kNmW
JzlQ3Ja7baZFDHygmWAvG1fXWCIC3Bl3sLxqy9h5+1m0W8PxqPii/BIZjCSbVMu+
P3VRmryhxdLLL/nzt2zX09VtAJwNAKL42UYfh3nlJN5/4LnT2JpCILvktTtNJoym
V8yP+AuLbIo+TcDrqPLn
=fVTR
-----END PGP SIGNATURE-----
Andrey Rahmatullin
Aug 6, 2017, 4:30:02 AM8/6/17
to
On Sun, Aug 06, 2017 at 07:28:08AM +0000, Dr. Bas Wijnen wrote:
> I can't think of a situation where you would not want it
The "I don't want yet another thing that can cause subtle breakages and
> I can't think of a situation where you would not want it
doesn't give me anything" situation (see disabling selinux after install
on RH systems).
--
WBR, wRAR
Moritz Mühlenhoff
Aug 6, 2017, 5:00:04 AM8/6/17
to
intrigeri <intr...@debian.org> schrieb:
coming from Ubuntu or OpenSUSE. If one of those profiles relies
on features which are not upstreamed on the kernel end, how's
that handled?
Cheers,
Moritz
> Still, even with the set of features available in mainline Linux
> *today*, IMO enabling AppArmor already has a good cost/benefit ratio
> for Debian and our users. I'm not proposing we apply out-of-tree
> AppArmor kernel patches.
I'd expect that a lot of the AppArmor profiles currently in use are
> *today*, IMO enabling AppArmor already has a good cost/benefit ratio
> for Debian and our users. I'm not proposing we apply out-of-tree
> AppArmor kernel patches.
coming from Ubuntu or OpenSUSE. If one of those profiles relies
on features which are not upstreamed on the kernel end, how's
that handled?
Cheers,
Moritz
intrigeri
Aug 6, 2017, 11:20:03 AM8/6/17
to
Dr. Bas Wijnen:
Cheers,
--
intrigeri
> Enabling it by default doesn't mean it can't be switched off, right?
Yes, passing apparmor=0 on the kernel command line will turn it off.
Cheers,
--
intrigeri
intrigeri
Aug 6, 2017, 11:40:03 AM8/6/17
to
Hi,
Moritz Mühlenhoff:
collaborative effort that a few Debian people participate in).
> If one of those profiles relies on features which are not upstreamed
> on the kernel end, how's that handled?
Rules that are not supported by the running kernel are silently
ignored, i.e. the operation is allowed.
For example, the profile for ping(8) specifies:
network inet raw,
network inet6 raw,
In Ubuntu, and in Debian once network socket mediation support lands
in Linux mainline, this means "no socket(2) based operation is allowed
except inet and inet6 raw sockets". In current Debian, no network
mediation by AppArmor is available so all socket(2) based operations
are allowed.
This way:
* the same profile can be shared between distros, regardless of
whether they apply not-upstreamed-yet AppArmor kernel patches;
* once new AppArmor features land in Linux mainline, we automatically
benefit from stronger confinement that's already implemented in our
AppArmor policy.
Cheers,
--
intrigeri
Moritz Mühlenhoff:
> I'd expect that a lot of the AppArmor profiles currently in use are
> coming from Ubuntu or OpenSUSE.
Yes, historically (most of them are now maintained via a cross-distro
> coming from Ubuntu or OpenSUSE.
collaborative effort that a few Debian people participate in).
> If one of those profiles relies on features which are not upstreamed
> on the kernel end, how's that handled?
ignored, i.e. the operation is allowed.
For example, the profile for ping(8) specifies:
network inet raw,
network inet6 raw,
In Ubuntu, and in Debian once network socket mediation support lands
in Linux mainline, this means "no socket(2) based operation is allowed
except inet and inet6 raw sockets". In current Debian, no network
mediation by AppArmor is available so all socket(2) based operations
are allowed.
This way:
* the same profile can be shared between distros, regardless of
whether they apply not-upstreamed-yet AppArmor kernel patches;
* once new AppArmor features land in Linux mainline, we automatically
benefit from stronger confinement that's already implemented in our
AppArmor policy.
Cheers,
--
intrigeri
Christian Seiler
Aug 6, 2017, 12:00:03 PM8/6/17
to
On 08/06/2017 05:32 PM, intrigeri wrote:
> Moritz Mühlenhoff:
local sysadmin that creates an own profile for a specific service they
run - and assume that AppArmor will confine it. But because the
kernel doesn't support a specific thing yet the confinement will be
incomplete. Which is probably better than not having AppArmor, and is
probably also OK for profiles shipped with the distribution and / or
upstream software - but not necessarily a good idea for something an
admin touches themselves.
Or, conversely, is there a possibility to add a flag to the AppArmor
profile to say "fail to load it if something is not understood"? In
that case all profiles shipped by Debian would not include that (for
interoperability reasons) but it could be documented that as a best
practice for admins they should use that flag so that they can be
sure that all protections they specified are actually affected.
Another thing to consider: if a profile is too restrictive, but the
part that is too restrictive isn't in the upstream kernel yet, then
things could break if you upgrade the kernel to a newer version from
e.g. backports later on. How would you deal with that kind of
breakage during the lifetime of a stable release?
Regards,
Christian
> Moritz Mühlenhoff:
>> If one of those profiles relies on features which are not upstreamed
>> on the kernel end, how's that handled?
>
> Rules that are not supported by the running kernel are silently
> ignored, i.e. the operation is allowed.
Is there at least a warning during the load of the profile? Consider a
>> on the kernel end, how's that handled?
>
> Rules that are not supported by the running kernel are silently
> ignored, i.e. the operation is allowed.
local sysadmin that creates an own profile for a specific service they
run - and assume that AppArmor will confine it. But because the
kernel doesn't support a specific thing yet the confinement will be
incomplete. Which is probably better than not having AppArmor, and is
probably also OK for profiles shipped with the distribution and / or
upstream software - but not necessarily a good idea for something an
admin touches themselves.
Or, conversely, is there a possibility to add a flag to the AppArmor
profile to say "fail to load it if something is not understood"? In
that case all profiles shipped by Debian would not include that (for
interoperability reasons) but it could be documented that as a best
practice for admins they should use that flag so that they can be
sure that all protections they specified are actually affected.
Another thing to consider: if a profile is too restrictive, but the
part that is too restrictive isn't in the upstream kernel yet, then
things could break if you upgrade the kernel to a newer version from
e.g. backports later on. How would you deal with that kind of
breakage during the lifetime of a stable release?
Regards,
Christian
Clint Byrum
Aug 6, 2017, 12:50:03 PM8/6/17
to
Excerpts from intrigeri's message of 2017-08-04 19:31:36 -0400:
Debian because they have an AppArmor profile that hasn't yet been
incorporated into Debian. That's a profile that is already tested and
used by many Ubuntu users, and should work well with a Debian system.
I found your proposal thorough and reasonable. I hope it happens.
> - Apparently Ubuntu users have been coping with AppArmor enforced
> by default for 9 years. I see no reason why Debian users would not.
>
This is really important. A few packages in Ubuntu largely differ from
> by default for 9 years. I see no reason why Debian users would not.
>
Debian because they have an AppArmor profile that hasn't yet been
incorporated into Debian. That's a profile that is already tested and
used by many Ubuntu users, and should work well with a Debian system.
I found your proposal thorough and reasonable. I hope it happens.
Moritz Mühlenhoff
Aug 7, 2017, 6:00:03 AM8/7/17
to
Christian Seiler <chri...@iwakd.de> schrieb:
used would also be controlled by the apparmor userspace side.
Also, I'm wondering about the status of kernel support which is
currently not upstreamed: intrigeri mention that new features are
now added to Linux mainline. Was there ever an attempt to upstream
those existing patches (e.g. for network socket mediation); was it
NACKed by upstream for conceptual problems or was it simply never
attempted due to time/resource constraints?
Cheers,
Moritz
> Another thing to consider: if a profile is too restrictive, but the
> part that is too restrictive isn't in the upstream kernel yet, then
> things could break if you upgrade the kernel to a newer version from
> e.g. backports later on. How would you deal with that kind of
> breakage during the lifetime of a stable release?
Agreed, that was pretty much my concern. Ideally the feature set
> part that is too restrictive isn't in the upstream kernel yet, then
> things could break if you upgrade the kernel to a newer version from
> e.g. backports later on. How would you deal with that kind of
> breakage during the lifetime of a stable release?
used would also be controlled by the apparmor userspace side.
Also, I'm wondering about the status of kernel support which is
currently not upstreamed: intrigeri mention that new features are
now added to Linux mainline. Was there ever an attempt to upstream
those existing patches (e.g. for network socket mediation); was it
NACKed by upstream for conceptual problems or was it simply never
attempted due to time/resource constraints?
Cheers,
Moritz
Ritesh Raj Sarraf
Aug 7, 2017, 8:30:04 AM8/7/17
to
On Fri, 2017-08-04 at 19:31 -0400, intrigeri wrote:
> 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.
On most systems, people tend to disable LSM first. Because many a times
> 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.
an inadequate policy hinders the use of the tool. And on the desktop
machine this becomes more common an issue.
On the SELinux side, there used to be a nice reporting tool for the
desktop, setroubleshoot. It used to alert (graphical and console) any
policy violations.
A DE agnostic alert tool would be necessary for wide adoption of any
LSM implementation.
In my opinion, we should start with an alert tool (to report policy
violations), and a handful of server packages.
--
Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response
Jeremy Bicha
Aug 7, 2017, 8:50:03 AM8/7/17
to
On Mon, Aug 7, 2017 at 8:28 AM, Ritesh Raj Sarraf <r...@debian.org> wrote:
> On most systems, people tend to disable LSM first. Because many a times
> an inadequate policy hinders the use of the tool. And on the desktop
> machine this becomes more common an issue.
While there are plenty of people who recommend disabling SELinux by
> On most systems, people tend to disable LSM first. Because many a times
> an inadequate policy hinders the use of the tool. And on the desktop
> machine this becomes more common an issue.
default on Fedora/RHEL (at least in the past), it's far, far less
common to hear about anyone recommending disabling AppArmor. And
that's one reason AppArmor is being proposed here and not SELinux.
Thanks,
Jeremy Bicha
Ritesh Raj Sarraf
Aug 7, 2017, 9:10:03 AM8/7/17
to
Hello Jeremy,
On Mon, 2017-08-07 at 08:47 -0400, Jeremy Bicha wrote:
> While there are plenty of people who recommend disabling SELinux by
> default on Fedora/RHEL (at least in the past), it's far, far less
> common to hear about anyone recommending disabling AppArmor. And
> that's one reason AppArmor is being proposed here and not SELinux.
They both serve the same purpose; to confine a running process, by the
mandated policy. The core problem is the policy, which may/will not fit
all users irrespective of the LSM implementation they use.
The previous adopters were all targeted distributions and it still took
some time for users to get accustomed to it.
RHEL confined most server packages. For the rest of the system, I
believe it ran unconfined. And they used to have a decent reporting
tool for policy violations.
SUSE used to have a robust LSM integration into YaST.
For a general purpose distribution like Debian, intri's proposal on the
server side is good. We could definitely leverage the policy files from
Ubuntu and SUSE.
But for desktop users, I worry this would cause more pain.
But I see there's an apparmor-notify package. Maybe that is the answer.
I'll check that out some time soon.
Thanks,
Ritesh
--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
On Mon, 2017-08-07 at 08:47 -0400, Jeremy Bicha wrote:
> While there are plenty of people who recommend disabling SELinux by
> default on Fedora/RHEL (at least in the past), it's far, far less
> common to hear about anyone recommending disabling AppArmor. And
> that's one reason AppArmor is being proposed here and not SELinux.
mandated policy. The core problem is the policy, which may/will not fit
all users irrespective of the LSM implementation they use.
The previous adopters were all targeted distributions and it still took
some time for users to get accustomed to it.
RHEL confined most server packages. For the rest of the system, I
believe it ran unconfined. And they used to have a decent reporting
tool for policy violations.
SUSE used to have a robust LSM integration into YaST.
For a general purpose distribution like Debian, intri's proposal on the
server side is good. We could definitely leverage the policy files from
Ubuntu and SUSE.
But for desktop users, I worry this would cause more pain.
But I see there's an apparmor-notify package. Maybe that is the answer.
I'll check that out some time soon.
Thanks,
Ritesh
--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
Jeremy Bicha
Aug 7, 2017, 9:20:02 AM8/7/17
to
On Mon, Aug 7, 2017 at 9:08 AM, Ritesh Raj Sarraf <r...@debian.org> wrote:
> But for desktop users, I worry this would cause more pain.
My point is that it hasn't so far and Ubuntu and SUSE has had millions
> But for desktop users, I worry this would cause more pain.
of people using it for a decade, more or less.
Thanks,
Jeremy Bicha
Garrett R.
Aug 7, 2017, 9:30:03 AM8/7/17
to
I have Ubuntu running on another box. I haven't had any trouble (to my knowledge) that has been caused from apparmor. Ubuntu being perceived as an entry OS for linux, I would think Canonical wouldn't have included it if it would introduce pain to desktop users. What sort of "pain" might apparmor cause?
I assumed apparmor was also on debian. If it isn't, doesn't this make Ubuntu significantly more secure than a debian installation?
I assumed apparmor was also on debian. If it isn't, doesn't this make Ubuntu significantly more secure than a debian installation?
Chris Lamb
Aug 9, 2017, 9:20:02 AM8/9/17
to
Hi intrigeri,
> 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.
Thanks for such a comprehensive and compelling write-up :)
$ sudo aa-status | head -n2
apparmor module is loaded.
49 profiles are loaded.
(Well, I should take more risks, right…?)
> * If you maintain a package for which we ship AppArmor policy in
> Debian: test it with AppArmor enabled before uploading.
Related to this, most of my packages are 'server'-ish and it feels
like some of the hardening features are also/already covered by my
systemd .service files.
Should/could I be also reimplementing these in AppArmor for defense
in depth or any comments in this general area?
Best wishes,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
> 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.
$ sudo aa-status | head -n2
apparmor module is loaded.
49 profiles are loaded.
(Well, I should take more risks, right…?)
> * If you maintain a package for which we ship AppArmor policy in
> Debian: test it with AppArmor enabled before uploading.
like some of the hardening features are also/already covered by my
systemd .service files.
Should/could I be also reimplementing these in AppArmor for defense
in depth or any comments in this general area?
Best wishes,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
intrigeri
Aug 9, 2017, 4:00:04 PM8/9/17
to
Hi,
Chris Lamb:
> Should/could I be also reimplementing these in AppArmor for defense
> in depth or any comments in this general area?
You surely could, but reimplementing exactly the same protections is
probably not the best use of your time.
Now, each of systemd and AppArmor can do hardening stuff that the
other doesn't support (at all or nicely), so sometimes it's good to do
a little bit of both.
What I would do these days:
1. Use the simplest of systemd's hardening features (e.g.
Protect{Home,System}=, Private{Devices,Tmp,Network}=,
CapabilityBoundingSet=) to their full extend.
Not many unit files we ship do that yet. Generally these
improvements can be implemented upstream and benefit users of
systemd on other distros :)
2. For finer-grained mediation of filesystem access, I will use
AppArmor that I find much nicer to implement, use and debug:
* To limit write access, with systemd one must set
ReadOnlyDirectories=/ and then a bunch of ReadWriteDirectories=
directives. It works fine once you're done, but I found it hard
to implement and debug this setup: with AppArmor I have clear
logs about what access the service was denied, and with systemd
I have no such thing. This probably explains why only one
systemd unit installed on my system bothers doing so.
* To limit read access, AFAIK with systemd one can only list
forbidden places and everything else is allowed by default.
No wonder InaccessiblePaths= is not used by any unit installed
on my system.
Cheers,
--
intrigeri
Chris Lamb:
> Related to this, most of my packages are 'server'-ish and it feels
> like some of the hardening features are also/already covered by my
> systemd .service files.
Quite possibly :)
> like some of the hardening features are also/already covered by my
> systemd .service files.
> Should/could I be also reimplementing these in AppArmor for defense
> in depth or any comments in this general area?
probably not the best use of your time.
Now, each of systemd and AppArmor can do hardening stuff that the
other doesn't support (at all or nicely), so sometimes it's good to do
a little bit of both.
What I would do these days:
1. Use the simplest of systemd's hardening features (e.g.
Protect{Home,System}=, Private{Devices,Tmp,Network}=,
CapabilityBoundingSet=) to their full extend.
Not many unit files we ship do that yet. Generally these
improvements can be implemented upstream and benefit users of
systemd on other distros :)
2. For finer-grained mediation of filesystem access, I will use
AppArmor that I find much nicer to implement, use and debug:
* To limit write access, with systemd one must set
ReadOnlyDirectories=/ and then a bunch of ReadWriteDirectories=
directives. It works fine once you're done, but I found it hard
to implement and debug this setup: with AppArmor I have clear
logs about what access the service was denied, and with systemd
I have no such thing. This probably explains why only one
systemd unit installed on my system bothers doing so.
* To limit read access, AFAIK with systemd one can only list
forbidden places and everything else is allowed by default.
No wonder InaccessiblePaths= is not used by any unit installed
on my system.
Cheers,
--
intrigeri
Russ Allbery
Aug 9, 2017, 4:20:02 PM8/9/17
to
intrigeri <intr...@debian.org> writes:
> You surely could, but reimplementing exactly the same protections is
> probably not the best use of your time.
> Now, each of systemd and AppArmor can do hardening stuff that the
> other doesn't support (at all or nicely), so sometimes it's good to do
> a little bit of both.
> What I would do these days:
> 1. Use the simplest of systemd's hardening features (e.g.
> Protect{Home,System}=, Private{Devices,Tmp,Network}=,
> CapabilityBoundingSet=) to their full extend.
> Not many unit files we ship do that yet. Generally these
> improvements can be implemented upstream and benefit users of
> systemd on other distros :)
To this, I would add SystemCallFilters, which is immensely powerful and
> You surely could, but reimplementing exactly the same protections is
> probably not the best use of your time.
> Now, each of systemd and AppArmor can do hardening stuff that the
> other doesn't support (at all or nicely), so sometimes it's good to do
> a little bit of both.
> What I would do these days:
> 1. Use the simplest of systemd's hardening features (e.g.
> Protect{Home,System}=, Private{Devices,Tmp,Network}=,
> CapabilityBoundingSet=) to their full extend.
> Not many unit files we ship do that yet. Generally these
> improvements can be implemented upstream and benefit users of
> systemd on other distros :)
much easier to use now than it was originally. I think a lot of the
benefit of hardening for a lot of network daemons would come from tested
use of SystemCallFilters (probably only using the @group syntax). This
blocks so many local privilege escalation bugs in random Linux syscalls,
making an RCE in a daemon running as a non-root user much less scary.
(For those not familiar, this is seccomp filtering, except about as easy
to use as seccomp can be. It's not as good as a carefully crafted full
seccomp policy, but you can get quite a bit of mileage out of some fairly
simple rules.)
Note that SystemCallFilters was very difficult to use in jessie since the
syscall groups weren't implemented yet. I would not recommend trying to
use it if targeting anything older than stretch.
> 2. For finer-grained mediation of filesystem access, I will use
> AppArmor that I find much nicer to implement, use and debug:
system access in a way that's quite a bit easier to configure.
ProtectSystem is great, but the bits that list specific files or paths are
somewhat harder to use and less useful.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
intrigeri
Aug 9, 2017, 4:20:03 PM8/9/17
to
Hi,
Ritesh Raj Sarraf:
Root cause of the problem:
https://bugs.launchpad.net/apparmor/+bug/1597671
Short term workaround: https://bugs.debian.org/759604
> Maybe that is the answer.
I suspect the expected benefits are not worth the effort. I'd rather
see us put efforts in automated testing (to identify & fix bugs before
they affect less tech-savvy users) and in fixing actual UX
stumbling blocks.
(apparmor-notify is merely a glorified log reader displaying low-level
technical details in a GUI. So the info it gives people who are not
tech-savvy is essentially "the problem I'm experiencing might have
something to do with AppArmor". I suspect they will have a harder time
interacting with our BTS than copy'n'pasting the corresponding
AppArmor logs, and apparmor-notify won't change that.)
Cheers,
--
intrigeri
Ritesh Raj Sarraf:
> But I see there's an apparmor-notify package.
Sadly it's not well integrated in Debian currently.
Root cause of the problem:
https://bugs.launchpad.net/apparmor/+bug/1597671
Short term workaround: https://bugs.debian.org/759604
> Maybe that is the answer.
see us put efforts in automated testing (to identify & fix bugs before
they affect less tech-savvy users) and in fixing actual UX
stumbling blocks.
(apparmor-notify is merely a glorified log reader displaying low-level
technical details in a GUI. So the info it gives people who are not
tech-savvy is essentially "the problem I'm experiencing might have
something to do with AppArmor". I suspect they will have a harder time
interacting with our BTS than copy'n'pasting the corresponding
AppArmor logs, and apparmor-notify won't change that.)
Cheers,
--
intrigeri
intrigeri
Aug 9, 2017, 4:50:06 PM8/9/17
to
Christian Seiler:
Debian: users were wondering if *any* of the AppArmor profile that
caused warning was applied at all. So in Jessie we decided to hide
these warnings.
> Or, conversely, is there a possibility to add a flag to the AppArmor
> profile to say "fail to load it if something is not understood"? In
> that case all profiles shipped by Debian would not include that (for
> interoperability reasons) but it could be documented that as a best
> practice for admins they should use that flag so that they can be
> sure that all protections they specified are actually affected.
If we're fine with relying purely on documentation to address this
problem for sysadmins writing their own profiles, then we can suggest
they use the existing apparmor_parser options about this:
alias apparmor_parser='apparmor_parser --warn=rules-not-enforced --warn=rule-downgraded'
… and then no new code needs to be written :)
Would that be good enough in your opinion?
Thanks for all this useful input!
Cheers,
--
intrigeri
> On 08/06/2017 05:32 PM, intrigeri wrote:
>> Rules that are not supported by the running kernel are silently
>> ignored, i.e. the operation is allowed.
> Is there at least a warning during the load of the profile?
There used to be a warning, but it was causing lots of confusion in
>> Rules that are not supported by the running kernel are silently
>> ignored, i.e. the operation is allowed.
> Is there at least a warning during the load of the profile?
Debian: users were wondering if *any* of the AppArmor profile that
caused warning was applied at all. So in Jessie we decided to hide
these warnings.
> Or, conversely, is there a possibility to add a flag to the AppArmor
> profile to say "fail to load it if something is not understood"? In
> that case all profiles shipped by Debian would not include that (for
> interoperability reasons) but it could be documented that as a best
> practice for admins they should use that flag so that they can be
> sure that all protections they specified are actually affected.
problem for sysadmins writing their own profiles, then we can suggest
they use the existing apparmor_parser options about this:
alias apparmor_parser='apparmor_parser --warn=rules-not-enforced --warn=rule-downgraded'
… and then no new code needs to be written :)
Would that be good enough in your opinion?
Thanks for all this useful input!
Cheers,
--
intrigeri
Christian Seiler
Aug 9, 2017, 5:10:02 PM8/9/17
to
On 08/09/2017 10:33 PM, intrigeri wrote:
> Christian Seiler:
>> On 08/06/2017 05:32 PM, intrigeri wrote:
>>> Rules that are not supported by the running kernel are silently
>>> ignored, i.e. the operation is allowed.
>
>> Is there at least a warning during the load of the profile?
>
> There used to be a warning, but it was causing lots of confusion in
> Debian: users were wondering if *any* of the AppArmor profile that
> caused warning was applied at all. So in Jessie we decided to hide
> these warnings.
Good to know. And since this kind of warning is more likely to lead
> Christian Seiler:
>> On 08/06/2017 05:32 PM, intrigeri wrote:
>>> Rules that are not supported by the running kernel are silently
>>> ignored, i.e. the operation is allowed.
>
>> Is there at least a warning during the load of the profile?
>
> There used to be a warning, but it was causing lots of confusion in
> Debian: users were wondering if *any* of the AppArmor profile that
> caused warning was applied at all. So in Jessie we decided to hide
> these warnings.
people to disable AppArmor altogether because they want to get rid
of the message and are scared by it, you're probably right in
removing that warning, because limited AppArmor protections are
probably still better as a defense-in-depth strategy than none at
all.
>> Or, conversely, is there a possibility to add a flag to the AppArmor
>> profile to say "fail to load it if something is not understood"? In
>> that case all profiles shipped by Debian would not include that (for
>> interoperability reasons) but it could be documented that as a best
>> practice for admins they should use that flag so that they can be
>> sure that all protections they specified are actually affected.
>
> If we're fine with relying purely on documentation to address this
> problem for sysadmins writing their own profiles, then we can suggest
> they use the existing apparmor_parser options about this:
>
> alias apparmor_parser='apparmor_parser --warn=rules-not-enforced --warn=rule-downgraded'
>
> … and then no new code needs to be written :)
>
> Would that be good enough in your opinion?
Speaking of: are there any good introductions for AppArmor? Not
necessarily for me personally (I've had some experience with
SELinux, so I recon I'll figure AppArmor out easily enough), but
for beginners? Something I can point friends of mine to? Ideally
something that doesn't just describe the syntax, but also best
practices? When I first ran into SELinux I found a couple of
tutorials which did things where I thought, well this doesn't
seem quite well enough thought out, I can think of a couple of
corner cases where this would fainot do what it was advertising,
only to later find that my impression was true and people with
even more knowledge of SELinux talked about not doing the things
I had seen in these tutorials, and suggesting more sensible
things as best practices. Unfortunately the writings by the real
experts were not in tutorial form. For buster, if AppArmor is
enabled by default (which btw. I'm in favor of, in case that was
not clear), I think we should take care to nudge people towards
the resources that describe best practices.
Regards,
Christian
intrigeri
Aug 9, 2017, 5:40:02 PM8/9/17
to
Hi,
[John, there's a question for you at the bottom, but you probably have
useful input about the first part of the discussion below too.]
Moritz Mühlenhoff:
A simple, but not entirely satisfying answer is:
1. Gather info about how real this problem has been in practice for
Ubuntu: they frequently update their kernel for various already
released distros with the latest AppArmor bits. I think they
occasionally have to update other packages accordingly to adjust
AppArmor policy. I don't know how often this happens. I'll ask them
to compile a list of such stable updates.
2. Evaluate for a year how it goes for Stretch + Linux from backports.
Desktop: I'm in a good place to provide data points, as Tails
generally ships this combination and we exercise the vast majority
of the desktop AppArmor stuff that's in Debian.
Server: sorry, I use the stable kernel except on bare-metal
virtualization hosts. But I think (1) will give us enough data on
this front.
3. Depending on what (1) and (2) tell us, decide whether "we might
have to update AppArmor policy from time to time in stable
point-releases or backports" is good enough… keeping in mind that
other distros are already dealing with the exact same problem, so
we won't have to do this alone. And if it's not good enough:
> Ideally the feature set used would also be controlled by the
> apparmor userspace side.
If we need to go this far: apparmor_parser has a --features-file
option that we could leverage to tie the feature set being used to
something else than the version of the running kernel, e.g.
with a file shipped in a new package built from src:linux with
appropriate versioned dependencies.
> Also, I'm wondering about the status of kernel support which is
> currently not upstreamed: intrigeri mention that new features are
> now added to Linux mainline. Was there ever an attempt to upstream
> those existing patches (e.g. for network socket mediation); was it
> NACKed by upstream for conceptual problems or was it simply never
> attempted due to time/resource constraints?
I'm not sure, so I'll let the main AppArmor kernel developer (John,
Cc'ed) answer this.
Cheers,
--
intrigeri
[John, there's a question for you at the bottom, but you probably have
useful input about the first part of the discussion below too.]
Moritz Mühlenhoff:
> Christian Seiler <chri...@iwakd.de> schrieb:
>> Another thing to consider: if a profile is too restrictive, but the
>> part that is too restrictive isn't in the upstream kernel yet, then
>> things could break if you upgrade the kernel to a newer version from
>> e.g. backports later on. How would you deal with that kind of
>> breakage during the lifetime of a stable release?
> Agreed, that was pretty much my concern.
Thank you so much for highlighting problems I had missed! :)
>> Another thing to consider: if a profile is too restrictive, but the
>> part that is too restrictive isn't in the upstream kernel yet, then
>> things could break if you upgrade the kernel to a newer version from
>> e.g. backports later on. How would you deal with that kind of
>> breakage during the lifetime of a stable release?
> Agreed, that was pretty much my concern.
A simple, but not entirely satisfying answer is:
1. Gather info about how real this problem has been in practice for
Ubuntu: they frequently update their kernel for various already
released distros with the latest AppArmor bits. I think they
occasionally have to update other packages accordingly to adjust
AppArmor policy. I don't know how often this happens. I'll ask them
to compile a list of such stable updates.
2. Evaluate for a year how it goes for Stretch + Linux from backports.
Desktop: I'm in a good place to provide data points, as Tails
generally ships this combination and we exercise the vast majority
of the desktop AppArmor stuff that's in Debian.
Server: sorry, I use the stable kernel except on bare-metal
virtualization hosts. But I think (1) will give us enough data on
this front.
3. Depending on what (1) and (2) tell us, decide whether "we might
have to update AppArmor policy from time to time in stable
point-releases or backports" is good enough… keeping in mind that
other distros are already dealing with the exact same problem, so
we won't have to do this alone. And if it's not good enough:
> Ideally the feature set used would also be controlled by the
> apparmor userspace side.
option that we could leverage to tie the feature set being used to
something else than the version of the running kernel, e.g.
with a file shipped in a new package built from src:linux with
appropriate versioned dependencies.
> Also, I'm wondering about the status of kernel support which is
> currently not upstreamed: intrigeri mention that new features are
> now added to Linux mainline. Was there ever an attempt to upstream
> those existing patches (e.g. for network socket mediation); was it
> NACKed by upstream for conceptual problems or was it simply never
> attempted due to time/resource constraints?
Cc'ed) answer this.
Cheers,
--
intrigeri
John Johansen
Aug 9, 2017, 8:40:02 PM8/9/17
to
support. There are basically 3 different potentially moving components
to consider
kernel - changes may result in a change in the supported feature
set.
policy - a package may backport/drop in policy that was developed on
a different feature set.
user space - changes/updates may be required to support new features
in a kernel or policy.
The question specifically asks about, an updated kernel with a policy
that was developed under a different feature set, suddenly breaking
when a new kernel is run on an older system.
The kernel portion is designed to support multiple versions of
userspace policy abis, and while we have dropped some of the older
abis, it is done slowly. The current kernel code supports the abi from
2009. So newer kernels will support older policy and userspaces.
Similarly the userspace is designed to support multiple kernel
versions and abis, so a newer userspace (if it is SRUed for some
reason) can support older kernels.
This leaves us dealing with policy. As long as the policy has not been
changed, it is possible to force userspace to build policy for a
certain kernel feature set by specifying the feature file.
This can be done in the apparmor/subdomain.conf file
with this specified, policy should remain to be compiled as for the
older kernel, and the new kernel should support and enforce it under
that abi.
There is however a caveat that sometimes the kernel changes abi
behavior in ways that apparmor can not adapt to without policy
modification.
An example of this would be
commit 9f834ec18defc369d73ccf9e87a2790bfa05bf46
binfmt_elf: switch to new creds when switching to new mm
which resulted in a change of which cred the PROT_EXEC request was
made against. With the way the lsm hook is designed only the single
cred is available so it is not even possible for apparmor to emulate
the old behavior.
In this case older policy needed to be patched to support the newer
behavior if it was to be used on a newer kernel, and a flag was
added to the apparmor kernel features interface making it possible
for userspace to detect that the kernel contained the change.
Thankfully this type of change is has not been very common.
>> Ideally the feature set used would also be controlled by the
>> apparmor userspace side.
>
> If we need to go this far: apparmor_parser has a --features-file
> option that we could leverage to tie the feature set being used to
> something else than the version of the running kernel, e.g.
> with a file shipped in a new package built from src:linux with
> appropriate versioned dependencies.
>
--feature-file, but from a support pov I think specifying it in the
config file
apparmor/subdomain.conf
would be better as then you don't have to mess with initscripts, unit
files, etc.
>> Also, I'm wondering about the status of kernel support which is
>> currently not upstreamed: intrigeri mention that new features are
>> now added to Linux mainline. Was there ever an attempt to upstream
>> those existing patches (e.g. for network socket mediation); was it
>> NACKed by upstream for conceptual problems or was it simply never
>> attempted due to time/resource constraints?
>
> I'm not sure, so I'll let the main AppArmor kernel developer (John,
> Cc'ed) answer this.
>
4.13 - has most everything. It has the virtualized apparmorfs and
namespacing interfaces, the core rework, stacking, etc. It is
missing some key features, specifically signals, mount and
network mediation
4.14 - isn't fully decided yet, but it should pickup everything except
maybe the extended unix socket mediation
As for why upstreaming has taken so long, there have been several
reasons.
Time constraints have been the major issue. Certain new feature
development was certainly prioritized over getting existing out of
tree features upstream. There is recognition that this was the wrong
approach and there is now an upstream first policy.
In addition some of the delay has also been just a matter of letting
code bake and shaking out bugs. Some of the code has had several
revisions before we were happy with it and thought it ready to be
upstreamed.
Eg. the extension to securityfs to allow apparmor to virtualize its
policy dir has seen several revisions. And even changed approach
before the final version which was upstreamed in 4.13. It just took
some time for the code to bake and for the correct approach to settle
out. Ubuntu was willing to carry the dev code to get certain features
early, at an increased cost in support.
The dbus code went through several revisions as well. While the dbus
code doesn't require a lot from the kernel, it did have some influence
on the kernel support interfaces.
Another reason many of these features were delayed in their
upstreaming, is the apparmor core was being rewritten during their
development, which unfortunately resulted in there not being a clean
separation between the different parts of development. So while some
features could have been upstreamed sooner they had to wait for the
core changes to bake, or be rewritten to work with the existing
upstream code (time and resources weren't available for the rewrite).
None of the current development has been NAKed upstream. At times in
the past certain approaches have been NAKed, and required reworking.
This was largely around how apparmor interacted with the system and
modifications to the LSM hooks. That is not to say that some of the
existing out of tree features might not get naked or need some
reworking before they land upstream.
We have been trying to drive the diff down to 0, and we are now close.
Raphael Hertzog
Aug 10, 2017, 6:30:02 AM8/10/17
to
Hi,
On Wed, 09 Aug 2017, Christian Seiler wrote:
> Speaking of: are there any good introductions for AppArmor? Not
> necessarily for me personally (I've had some experience with
> SELinux, so I recon I'll figure AppArmor out easily enough), but
> for beginners? Something I can point friends of mine to? Ideally
> something that doesn't just describe the syntax, but also best
> practices? When I first ran into SELinux I found a couple of
https://debian-handbook.info/browse/stable/sect.apparmor.html
Feedback welcome as bug reports against the debian-handbook package.
Note that this (still) describes the status of the package
in jessie, I have not yet finished to update the book for stretch.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
On Wed, 09 Aug 2017, Christian Seiler wrote:
> Speaking of: are there any good introductions for AppArmor? Not
> necessarily for me personally (I've had some experience with
> SELinux, so I recon I'll figure AppArmor out easily enough), but
> for beginners? Something I can point friends of mine to? Ideally
> something that doesn't just describe the syntax, but also best
> practices? When I first ran into SELinux I found a couple of
Feedback welcome as bug reports against the debian-handbook package.
Note that this (still) describes the status of the package
in jessie, I have not yet finished to update the book for stretch.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
Simon McVittie
Aug 10, 2017, 2:40:03 PM8/10/17