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

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

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

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,

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

Hi, A year ago, intrigeri proposed an experiment:  let's enable AppArmor by default in testing/sid. Here is an extract from the proposal (you can find the full proposal and the thread at [0]): > tl;dr: I hereby propose we enable AppArmor by default in testing/sid, > and decide one year later

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

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

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

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

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

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

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

[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

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

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

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

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

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

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

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

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

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

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

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

* 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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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 the

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

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

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

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

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

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

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

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.

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

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"

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

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

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

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 >

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

gt; 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 <r...@debian.org> wrote: > But for desktop users, I worry this would cause more pain. My point is that it

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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,

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

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

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

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