Re: recommends for apparmor in newest linux-image-4.13

[Wouter Verhelst]

On Sun, Dec 10, 2017 at 04:21:18PM -0500, Theodore Ts'o wrote:
> On Wed, Dec 06, 2017 at 11:24:45AM +0100, Laurent Bigonville wrote:
> > The SELinux policy could be altered to either run everything that we know is
> > not ready to be confined in an unconfined domain or put that domain in
> > permissive (which would result in a lot of denials being logged), so it's
> > possible to behave more or less the same way as AppArmor depending of how
> > the policy is designed.
> 
> It "could" be altered the same way that anyone "could" modify a
> sendmail.cf file.  Someone "could" create a program which plays the
> game of Go written raw assembly language.

I think Laurent was wearing his "contributor to the Debian SELinux
packages" hat in that that was one of the options if that's wanted,
rather than the more "theoretically this is possible" thing you seem to
be referring to.

> If it "could" be done, why hasn't been done in the past decade?

Because nobody ever thought it would be a good idea? But ideas and
thoughts can change.

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

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

Re: recommends for apparmor in newest linux-image-4.13

[Russell Coker]

One thing that would be good to have is a set of profiles for Puppet or 
something similar for installing a variety of common Debian configurations. 
This could be used for testing SE Linux as well as anything else one might want 
to test.

If we had automated tests for the most common webapps, mail server 
configurations, and all the other most common server packages (maybe based on 
popcon) it would significantly reduce the scope of problems users experience.

But as noted SE Linux in Debian is me and Laurent, more help would be 
appreciated.

Also I've seen AppArmor and Systemd both prevent reasonable configurations that 
aren't uncommon from working. I don't think that it's possible to provide 
useful security benefits without the risk of stopping operations you desire. 
This principle has a much wider scope than software, you can see it in all 
manner of physical security systems.
-- 
Sent from my Huawei Mate 9 with K-9 Mail.

Re: recommends for apparmor in newest linux-image-4.13

[Laurent Bigonville]

Le 10/12/17 à 22:21, Theodore Ts'o a écrit :

On Wed, Dec 06, 2017 at 11:24:45AM +0100, Laurent Bigonville wrote:

The SELinux policy could be altered to either run everything that we know is
not ready to be confined in an unconfined domain or put that domain in
permissive (which would result in a lot of denials being logged), so it's
possible to behave more or less the same way as AppArmor depending of how
the policy is designed.

It "could" be altered the same way that anyone "could" modify a
sendmail.cf file.  Someone "could" create a program which plays the
game of Go written raw assembly language.

If it "could" be done, why hasn't been done in the past decade?
Everything started by logged-in users is already running unconfined for 
years in most distributions (including debian).


For the daemons (httpd,...), the goal was always to have a policy 
working well enough so they could be confined, but this requires work to 
adjust the policy to work with debian paths and software versions (these 
are moving targets).


My idea at some point was to formalize (a subset of) use cases and test 
these well enough before enforcing the policy only for these. But I 
never had the time to formalize the use cases. Running SELinux all the 
domains in permissive doesn't make a lot of sense IMVHO.


It's a bit of chicken-egg problem here, either we confine everything, 
things break and we have a high risk of people disabling SELinux or we 
put everything in permissive and people doesn't even see that the policy 
is not correct. In both case we have no bug reports, well at least that 
what I was afraid of and that's and why I personally never proposed 
SELinux to be enabled by default.


Also, don't forget that the SELinux team in debian is made of 2 people, 
Russel for the policy and I'm taking care of the userspace.


TL;DR: Not enough time/testing/manpower

Re: recommends for apparmor in newest linux-image-4.13

[Theodore Ts'o]

On Wed, Dec 06, 2017 at 11:24:45AM +0100, Laurent Bigonville wrote:
> The SELinux policy could be altered to either run everything that we know is
> not ready to be confined in an unconfined domain or put that domain in
> permissive (which would result in a lot of denials being logged), so it's
> possible to behave more or less the same way as AppArmor depending of how
> the policy is designed.

It "could" be altered the same way that anyone "could" modify a
sendmail.cf file.  Someone "could" create a program which plays the
game of Go written raw assembly language.

If it "could" be done, why hasn't been done in the past decade?

- Ted

Re: recommends for apparmor in newest linux-image-4.13

[Vincas Dargis]

On 2017-12-06 12:24, Laurent Bigonville wrote:
I feel that having Apparmor running and not doing anything will give people a false sense of security, on my test 
machine almost nothing was confined


Yeah, we really need much more working profiles ready to be shipped...  Thoguh I believe our AppArmor maintainer stated 
opinion that we should fix what's already available, instead of rushing to write bunch of new profiles (please correct 
me if I mistaken, intrigeri :-) ).


As a hint, try running "sudo aa-enforce /etc/apparmor.d/*", it might enable some disabled-by-defaut profiles, as 
Thunderbird and Libreoffice ones.


TBH I'm a bit disappointed with upstream state of Apparmor (no D-Bus mediation,...) and other missing features that are 
still ubuntu only.


Yes I miss features too (not only mediation...). Though Signal and Mount mediation is available in 4.14 (not enabled in 
Debian AppArmor configuration _yet_, until it's tested enough), Network might come in 4.16.

Re: recommends for apparmor in newest linux-image-4.13

[intrigeri]

Hi Laurent,

Laurent Bigonville:
> The SELinux policy could be altered to either run everything that we know is 
> not
> ready to be confined in an unconfined domain or put that domain in permissive 
> (which
> would result in a lot of denials being logged), so it's possible to behave 
> more or
> less the same way as AppArmor depending of how the policy is designed.

Great!

Is there any plan to do this up to the point when it's realistic to
enable SELinux by default on Debian? Ideally this would be done early
enough so we can run the s/AppArmor/SELinux/ experiment during the
Buster cycle, and make a decision in time for Buster.

(I'm not counting on LSM stacking being finalized in time for Buster
so for now, if we want a LSM enabled by default, we need to choose
exactly one. I'd be fine with SELinux instead of AppArmor; what would
make me sad is if we remained in the "no LSM" situation much longer
only because we don't manage to pick one.)

> I feel that having Apparmor running and not doing anything will give people a 
> false
> sense of security,

That's definitely a risk. If AppArmor ends up being enabled by default
in Debian some day, I think we can easily mitigate this risk by
carefully wording our public communication about it.

> TBH I'm a bit disappointed with upstream state of Apparmor (no D-Bus 
> mediation,...)
> and other missing features that are still ubuntu only.

I can definitely relate to that feeling and have been frustrated about
this for years. Thankfully things have changed drastically recently:
quite a few features have been upstreamed to Linux mainline in 4.13
and 4.14, and more is upcoming, so I'm now hopeful :)

Cheers,
-- 
intrigeri

Re: Re: recommends for apparmor in newest linux-image-4.13

[Laurent Bigonville]

Theodore Ts'o wrote:

On Wed, Nov 29, 2017 at 11:51:55AM -0800, Russ Allbery wrote:


> Michael Stone  writes:
> > On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote:
> 
> >> Ubuntu has successfully shipped with AppArmor enabled.
> 
> > For all the packages in debian? Cool! That will save a lot of work.
> 
> Yes?  I mean, most of them don't have rules, so it doesn't do anything,

> but that's how we start.  But indeed, Ubuntu has already done a ton of
> work here, so it *does* save us quite a bit of work.

The fact that AppArmor doesn't do anything if it doesn't have any
rules is why we have a chance of enabling it by default.  The problem
with SELinux is that it's "secure" by the security-weenies' definition
of secure --- that is, if there isn't provision made for a particular
application, with SELinux that application is secure the way a
computer with thermite applied to the hard drive is secure --- it
simply doesn't work.


The SELinux policy could be altered to either run everything that we 
know is not ready to be confined in an unconfined domain or put that 
domain in permissive (which would result in a lot of denials being 
logged), so it's possible to behave more or less the same way as 
AppArmor depending of how the policy is designed.




Every few years, I've tried turning on SELinux on my development
laptop.  After it completely fails and trying to make it work just
work for the subset of application that I care about, I give up and
turn it off again.  Having some kind of LSM enabled is, as far as I am
concerned, better than nothing.


I feel that having Apparmor running and not doing anything will give 
people a false sense of security, on my test machine almost nothing was 
confined


TBH I'm a bit disappointed with upstream state of Apparmor (no D-Bus 
mediation,...) and other missing features that are still ubuntu only.

Re: recommends for apparmor in newest linux-image-4.13

[Theodore Ts'o]

On Mon, Dec 04, 2017 at 05:56:45PM +, Ian Jackson wrote:
> Theodore Ts'o writes ("Re: recommends for apparmor in newest 
> linux-image-4.13"):
> > [something about] security-weenies
> 
> IMO this language is completely inappropriate in any formal Debian
> context.

The second definition from http://whatis.techtarget.com/definition/weenie

2) In the context of program development and among the "hackerdom"
that Raymond chronicles, the term weenie can be ascribed
respectfully to someone who is highly knowledgeable, intensely
committed to, or even just employed on a particular endeavor or in
a particular operating system culture. For example, a "UNIX
weenie" may mean someone who is an expert at using or modifying
UNIX . But, depending on the context, it could also mean a "UNIX
bigot."

> (I have to disclose an interest: I have a PhD in computer security, so
> maybe I am one of these "weenies"?)

Given that I served on the Security Area Directorate of the IETF for
close to ten years, the term could also be used to describe me.  But
as I said, if it's too hard for *me* to figure out how to make SELinux
work on my development laptop, perhaps folks would insist that I turn
in my security weenie union card...

I don't consider it offensive, just I don't consider the term "hacker"
to be offensive.

- Ted

Re: recommends for apparmor in newest linux-image-4.13

[Ian Jackson]

Theodore Ts'o writes ("Re: recommends for apparmor in newest linux-image-4.13"):
> [something about] security-weenies

IMO this language is completely inappropriate in any formal Debian
context.

Furthermore, the targets of this insult don't deserve it, because
there are real scenarios where "fail closed, for unknown things" is
the right policy.  It's a matter of tradeoffs.

It is of course fine to say that the "fail closed, for unknown things"
is the wrong default policy for a mandatory access control system to
be enabled by default in Debian.  (I would agree.)

> security-weenies

Seriously, you're repating this offensive language ?

Ian.

(I have to disclose an interest: I have a PhD in computer security, so
maybe I am one of these "weenies"?)

Re: recommends for apparmor in newest linux-image-4.13

[Theodore Ts'o]

On Wed, Nov 29, 2017 at 11:51:55AM -0800, Russ Allbery wrote:
> Michael Stone  writes:
> > On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote:
> 
> >> Ubuntu has successfully shipped with AppArmor enabled.
> 
> > For all the packages in debian? Cool! That will save a lot of work.
> 
> Yes?  I mean, most of them don't have rules, so it doesn't do anything,
> but that's how we start.  But indeed, Ubuntu has already done a ton of
> work here, so it *does* save us quite a bit of work.

The fact that AppArmor doesn't do anything if it doesn't have any
rules is why we have a chance of enabling it by default.  The problem
with SELinux is that it's "secure" by the security-weenies' definition
of secure --- that is, if there isn't provision made for a particular
application, with SELinux that application is secure the way a
computer with thermite applied to the hard drive is secure --- it
simply doesn't work.

Every few years, I've tried turning on SELinux on my development
laptop.  After it completely fails and trying to make it work just
work for the subset of application that I care about, I give up and
turn it off again.  Having some kind of LSM enabled is, as far as I am
concerned, better than nothing.

(And I speak as someone who chaired the IP Security working group at
the IETF, and was the technical lead for the MIT Kerberos V5 effort.
If admitting that I'm too dumb or don't have enough patience to figure
out how to make SELinux work on my development laptop means that
someone is going to revoke my security-weenies' union card, I'm happy
to turn it in)

- Ted

Re: seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

[Colin Watson]

On Fri, Dec 01, 2017 at 12:05:20PM +0100, Andrew Shadura wrote:
> How about https://notabug.org/rain1/linux-seccomp-pledge/?

Promising enough idea, but it looks like the author gave up on it and
never finished the job.  This sort of thing is only really helpful if
it's maintained by somebody who's putting more work into keeping it
complete and current than I want to put into doing a small part of the
job. :-)

-- 
Colin Watson   [cjwat...@debian.org]

Re: seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

[Colin Watson]

On Thu, Nov 30, 2017 at 07:18:43PM -0800, Seth Arnold wrote:
> On Fri, Dec 01, 2017 at 01:29:44AM +, Colin Watson wrote:
> > but should be much easier to maintain, and would probably also make it
> > easier to switch to a syscall-set-confining library if such a thing
> > exists in the future.
> 
> Would a version of OpenBSD's pledge() system call have looked appealing to
> you, if it were implemented as a library interface around seccomp? There's
> already roughly two dozen categories, though not all may translate well to
> seccomp's abilities.
> 
> https://man.openbsd.org/pledge.2

Something like that, yes; maybe something like "stdio rpath flock proc
exec" in man-db's case, although I'm sure that would need some tweaking.

It's nice to be able to say "these sets, plus this handful of additional
syscalls", which pledge can't do.

Also, I'm very glad that seccomp persists across execve(2); I much
prefer this to the pledge model.

-- 
Colin Watson   [cjwat...@debian.org]

Re: seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

[Seth Arnold]

On Fri, Dec 01, 2017 at 01:29:44AM +, Colin Watson wrote:
> but should be much easier to maintain, and would probably also make it
> easier to switch to a syscall-set-confining library if such a thing
> exists in the future.

Would a version of OpenBSD's pledge() system call have looked appealing to
you, if it were implemented as a library interface around seccomp? There's
already roughly two dozen categories, though not all may translate well to
seccomp's abilities.

https://man.openbsd.org/pledge.2

Thanks


signature.asc
Description: PGP signature

Re: seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

[Colin Watson]

On Fri, Dec 01, 2017 at 12:35:06AM +, Colin Watson wrote:
> (Hmm, though maybe a reasonable stopgap would be to copy the relevant
> syscall lists from systemd's code.  That would leave me updating things
> manually from time to time, which isn't great, but it would probably
> still be better than maintaining my own list!  I think I'll do this.)

That was indeed a worthwhile exercise.  I'm now down to five sets taken
verbatim from systemd, which are long but I can just update them
wholesale from time to time; three sets from systemd from which I've
extracted subsets, e.g. a read-only subset of file system operations;
and nine additional syscalls, some of which I still need to review and
possibly either restrict by arguments or drop.  Those are much more
tolerable numbers than a monolithic block of over a hundred syscalls.

The exercise caused me to notice several syscalls I'd missed, and some
that I'd included inappropriately.  It's still a lot of lines of code,
but should be much easier to maintain, and would probably also make it
easier to switch to a syscall-set-confining library if such a thing
exists in the future.

(Side note: this strategy works partly because man-db is under a licence
that the relevant file in systemd can be converted to using LGPL2.1
section 3.  If that weren't the case then it would at the very least be
much less obvious that this is a permissible thing to do.)

-- 
Colin Watson   [cjwat...@debian.org]

Re: seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

[Colin Watson]

On Wed, Nov 29, 2017 at 05:36:30PM -0800, Russ Allbery wrote:
> Vincas Dargis  writes:
> > Since mentioned, I would like that these daemons would implement seccomp
> > filtering themselves, meaning like within application itself, using
> > libeseccomp. Thy can fine-grain what thread what syscalls can make.
[...]
> Does libeseccomp now have maintained system call classes similar to
> systemd?

(I think "libeseccomp" was a typo for "libseccomp".  I wouldn't normally
bother to point this out, but you reproduced it, and it caused me to
briefly get excited at the idea that maybe there was an "extended
seccomp" library or something.)

As far as I can tell, no.  I've been working on applying seccomp
confinement to parts of man-db recently (there are plenty of bits of its
code that could usefully be hardened against the admittedly small chance
of a compromise via crafted manual page text).  I have the self-imposed
spec of "should allow the process to do most reasonable things to
itself, to read and write data from and to already-open file
descriptors, to open files in read-only mode, and to fork new processes
with the same restrictions".  This results in a list of 116 syscalls at
last count, and it's hard to be certain that such a list is complete.
Since this is in application code rather than service code, systemd's
SystemCallFilter predefined sets aren't directly usable in this context;
I'd definitely like to use a library that provided something similar,
maybe a wrapper on top of libseccomp.

(Hmm, though maybe a reasonable stopgap would be to copy the relevant
syscall lists from systemd's code.  That would leave me updating things
manually from time to time, which isn't great, but it would probably
still be better than maintaining my own list!  I think I'll do this.)

-- 
Colin Watson   [cjwat...@debian.org]

seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

[Russ Allbery]

Vincas Dargis  writes:

> Since mentioned, I would like that these daemons would implement seccomp
> filtering themselves, meaning like within application itself, using
> libeseccomp. Thy can fine-grain what thread what syscalls can make.

Yes, this is potentially even better.  But there are cases where we can
apply filters that upstream may not be able to assume for various reasons,
and a lot of upstreams who won't be willing to take Linux-specific code
inside the daemon itself.

But this would be fantastic for things like ImageMagick, which are
otherwise a notorious source of RCEs.

Does libeseccomp now have maintained system call classes similar to
systemd?  If we could build a tool that could apply namespace and filter
rules using system call classes like that, it would make it easy to
support similar hardening in sysvinit as well.  Last time I looked at the
various stand-alone jailing utilities like firejail, they seemed to be
missing the nice system call groupings that let you not have to know
exactly what system calls result from standard IO operations, but
hopefully someone has since tackled this.

-- 
Russ Allbery (r...@debian.org)   

Re: recommends for apparmor in newest linux-image-4.13

[Tollef Fog Heen]

]] intrigeri 

> Regarding RC bugs: I don't think breakage that only happens with
> AppArmor enabled should be RC in the context of the experiment we're
> currently running: in the vast majority of cases, a local workaround
> is available (one can disable the faulty AppArmor profile with the
> aa-disable command).

I think they (in general) should be RC for whatever is shipping the
buggy apparmor profile.

Having packages that are broken out of the box is not the kind of distro
we should be shipping.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: recommends for apparmor in newest linux-image-4.13

[Russ Allbery]

Michael Stone  writes:
> On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote:

>> Ubuntu has successfully shipped with AppArmor enabled.

> For all the packages in debian? Cool! That will save a lot of work.

Yes?  I mean, most of them don't have rules, so it doesn't do anything,
but that's how we start.  But indeed, Ubuntu has already done a ton of
work here, so it *does* save us quite a bit of work.

-- 
Russ Allbery (r...@debian.org)   

Re: recommends for apparmor in newest linux-image-4.13

[Vincas Dargis]

On 2017-11-29 09:25, Jonathan Dowland wrote:

On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote:

My personal pet "I don't have time" project I'd love to see is extending
systemd units for as many services in Debian as possible to include
namespace restrictions and seccomp filter rules, which I think has good
parallel potential alongside an LSM for raising the default security
posture of Debian.  LSMs deal with per-file restrictions much more easily
than systemd's seccomp and namespace support, but the seccomp and
namespace support does a lot of other nice things that LSMs aren't as good
at.


Yes this would be excellent; a necessary prerequisite would be getting
more daemons (and cron-scheduled processes) shipping systemd units too.



Since mentioned, I would like that these daemons would implement seccomp filtering themselves, meaning like within 
application itself, using libeseccomp. Thy can fine-grain what thread what syscalls can make.


For example, some networking, parsing thread might not need execve() at all. Meanwhile, it might be needed for main or 
other thread to call some external application, but that can be later mediated with MAC, is it AppArmor, SELinux or 
whatever.

Re: recommends for apparmor in newest linux-image-4.13

[Thomas Goirand]

On 11/23/2017 03:01 PM, Christoph Hellwig wrote:
> ...  Looks like someone in
> Debian just decided to make apparmor the default, which is horrible
> news :(

This is actually a fantastic news. Hopefully, it will turn out to just
work without too much hassle.

Thanks Ben for doing this, and everyone else involved in apparmor.
Thanks to intri for pushing this too.

Cheers,

Thomas Goirand (zigo)

Re: recommends for apparmor in newest linux-image-4.13

[Philipp Kern]

On 11/29/2017 1:08 PM, Simon McVittie wrote:
> I don't see why it isn't a MAC implementation. However, the comment about
> not having a "real" security model seems valid. The way AppArmor is used
> in practice is often more like hardening than a coherent security model:
> when an app was not designed to be sandboxed, and an AppArmor profile
> was added later without modifying app code, the profile rules that are
> necessary to make it work are often loose enough to allow privilege
> escalation, particularly for desktop apps that are typically written to
> assume they have full desktop privileges.

Yup. That's a little frustrating. But I don't think people solved this
particular problem for SELinux either, did they? It's a question of
which transitions to allow and how the permission set changes then.

I will point out that seccomp filters have the same problem: You need to
know pretty much exactly what all of the libraries you include do. If
you then happen to be a daemon that loads, say, PAM modules (or other
kinds of modules) you suddenly end up with more calls that you need to
allow and stuff crashes. I think at least debugging might have been
facilitated recently rather than just killing off the program without an
indication of what's wrong. That doesn't preclude daemon maintainers
from writing such a policy but they have to be pretty careful not to
break stuff. People always rant at Chromium because it bundles
everything but such control also allows to write tight filters.

Kind regards
Philipp Kern

Re: recommends for apparmor in newest linux-image-4.13

[Holger Levsen]

On Wed, Nov 29, 2017 at 07:26:26AM -0500, Michael Stone wrote:
> Exactly the same argument can be made for selinux. But for some reason just
> turning on selinux by default to fix everything wasn't a good solution, but
> turning on apparmor for the same reason is. I'm trying to understand this
> logic.
 
oh, that is very simple to answer: noone has proposed doing this for
SELinux, while people have proposed this for AppArmor.

SELinux is *missing people* *activly advancing* it's usability in Debian.

(And as others have explained in this thread, technically AppArmor looks
promising too.)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: recommends for apparmor in newest linux-image-4.13

[intrigeri]

Hi,

Michael Stone:
> On Wed, Nov 29, 2017 at 01:17:26PM +0100, Emilio Pozuelo Monfort wrote:
>>Nobody said problems are going to magically go away by enabling apparmor. 
>>OTOH,
>>we won't know to what extent problems exists until it gets enabled everywhere.

> Exactly the same argument can be made for selinux.

In theory, sure. In practice, well, apparently nobody made that same
argument for SELinux; I suspect there's a reason for it.

One problem with the decision making process we've gone through is
that so far, we lack information about the current state of SELinux in
Debian to be able to do a fair comparison: as far as I can tell, most
of the SELinux info that was contributed to this discussion came from
a (very nice and informative) Fedora developer and was not applying
directly to Debian. So we discussed "what would it take to enable
AppArmor by default in Buster" instead of "which LSM can/should we
enable by default in Buster?".

I'm happy to participate in the latter discussion but I won't be the
one starting and facilitating it. I think basically all the info we
need wrt. AppArmor is already on the corresponding discussion thread
and the missing bits are being gathered with the current
experimentation; if something is missing, just ask; then someone
should sum this info somewhere (I can do this but perhaps someone less
biases than me would be better). We'll need similar information about
SELinux in Debian; and if the SELinux maintainers say it's OK to try
it, let's do the same experiment for SELinux (say in 3 months, we
switch the default, enforced by default LSM from AppArmor to SELinux).

> But for some reason just turning on selinux by default to fix
> everything wasn't a good solution, but turning on apparmor for the
> same reason is. I'm trying to understand this logic.

I was familiar enough with the state of AppArmor in Debian to be
confident we could turn it on without breaking lots of critical
functionality on the vast majority of Debian testing/sid systems (the
Ubuntu experience helps a lot). I think what happened in the last two
weeks proved this point.

I'm not familiar enough with the state of SELinux in Debian to know
precisely why the SELinux maintainers did not propose enabling it by
default (it might be due to the current state being far from good
enough, it might be due to lack of resources to handle bug reports, it
might be that I was too pushy with AppArmor so they did not dare,
really I don't know). I would be very interested to get data points
about this, either from the SELinux maintainers, or from enthusiastic
users willing to enforce SELinux today on their Debian testing/sid
desktop system and report how it goes.

Cheers,
-- 
intrigeri

Re: recommends for apparmor in newest linux-image-4.13

[Michael Stone]

On Wed, Nov 29, 2017 at 01:17:26PM +0100, Emilio Pozuelo Monfort wrote:

On 29/11/17 13:04, Michael Stone wrote:

On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote:

Maybe SELinux would be better, but various people have been trying to make
SELinux better-integrated with Debian for quite some time, and those
efforts don't seem to have been particularly successful.


Well, maybe it should just be turned on by default, then all the remaining
issues will magically go away just like they will for apparmor!


If there are issues, file bugs and mention them. So far your attitude is not
helpful at all.

Nobody said problems are going to magically go away by enabling apparmor. OTOH,
we won't know to what extent problems exists until it gets enabled everywhere.


Exactly the same argument can be made for selinux. But for some reason 
just turning on selinux by default to fix everything wasn't a good 
solution, but turning on apparmor for the same reason is. I'm trying to 
understand this logic.


Mike Stone

Re: recommends for apparmor in newest linux-image-4.13

[Emilio Pozuelo Monfort]

On 29/11/17 13:04, Michael Stone wrote:
> On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote:
>> Maybe SELinux would be better, but various people have been trying to make
>> SELinux better-integrated with Debian for quite some time, and those
>> efforts don't seem to have been particularly successful.
> 
> Well, maybe it should just be turned on by default, then all the remaining
> issues will magically go away just like they will for apparmor!

If there are issues, file bugs and mention them. So far your attitude is not
helpful at all.

Nobody said problems are going to magically go away by enabling apparmor. OTOH,
we won't know to what extent problems exists until it gets enabled everywhere.
It is one thing to enable something for your particular setup, and it's a very
different thing to have it enabled across all the distribution. So don't blame
the maintainers if it worked for them but doesn't work for you. Once we know
what specific problems exist, we can work on fixing those and/or we can revert
the situation, if that turns out to be the best option. In my experience, I have
only encountered one problem so far and it's already been worked on.

Emilio

Re: recommends for apparmor in newest linux-image-4.13

[Simon McVittie]

On Wed, 29 Nov 2017 at 22:10:03 +1100, Scott Leggett wrote:
> > It's just a bad idea of a security model that implements ad-hoc
> > and mostly path based restrictions instead of an actually verified
> > security model.  Using that by default makes it much harder to actually
> > use a real MAC based security model
> 
> I am not an expert, but I thought that AppArmor was also considered a
> MAC implementation.

I don't see why it isn't a MAC implementation. However, the comment about
not having a "real" security model seems valid. The way AppArmor is used
in practice is often more like hardening than a coherent security model:
when an app was not designed to be sandboxed, and an AppArmor profile
was added later without modifying app code, the profile rules that are
necessary to make it work are often loose enough to allow privilege
escalation, particularly for desktop apps that are typically written to
assume they have full desktop privileges.

One rebuttal to that is that hardening is better than nothing, and what
most Debian users have in this department at the moment is nothing.

One very likely route for privilege escalation is that when a desktop app
has been written with the expectation that it can run other programs as
subprocesses, if those programs have higher privilege than the desktop app
itself, the desktop app can probably subvert them - the security issues
around setuid are well-known, but switching to a more-privileged AppArmor
profile is basically a weaker form of setuid, and we can't really expect
the author of every program that might be used as a subprocess to write
in the same defensive/paranoid style that we expect for setuid programs.
I think we have to assume that if any descendant of an app (in terms of
the process tree) can do something, then so can that app.

Controlled privilege escalation without the pitfalls of executing a
subprocess is often done via D-Bus or similar. However, until the kernel
support necessary for finer-grained D-Bus AppArmor mediation lands
upstream (which it hopefully will soon), another route for privilege
escalation is that if you can get access to the session bus at all,
then you can interact with services that expect that everything on the
session bus is equally-privileged, and in particular ask dbus-daemon,
gnome-session, systemd --user, etc. to run arbitrary code on your behalf.
If you have a patched kernel that adds this feature (like Ubuntu has for
many years), Debian's dbus-daemon is already set up to make use of it.

Flatpak's "portals" concept is an attempt to avoid those privilege
escalation opportunities. In some ways, the portal work is more important
than Flatpak itself.

Outside desktops, in the more limited scope (but higher privilege level)
of system services, is probably where AppArmor is most useful in the
short term. In that space it overlaps fairly heavily with what you can
do with the various "hardening" options available in systemd units.

smcv

Re: recommends for apparmor in newest linux-image-4.13

[Michael Stone]

On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote:

Maybe SELinux would be better, but various people have been trying to make
SELinux better-integrated with Debian for quite some time, and those
efforts don't seem to have been particularly successful.


Well, maybe it should just be turned on by default, then all the 
remaining issues will magically go away just like they will for apparmor!



Ubuntu has
successfully shipped with AppArmor enabled.


For all the packages in debian? Cool! That will save a lot of work.

Mike Stone

Re: recommends for apparmor in newest linux-image-4.13

[Scott Leggett]

On 2017-11-28.19:54, Christoph Hellwig wrote:
> It's just a bad idea of a security model that implements ad-hoc
> and mostly path based restrictions instead of an actually verified
> security model.  Using that by default makes it much harder to actually
> use a real MAC based security model, which not only is required for
> various security sensitive deployments but also a good idea in general.

I am not an expert, but I thought that AppArmor was also considered a
MAC implementation.

Can you provide more information on the verification of SELinux?

-- 
Regards,
Scott.


signature.asc
Description: PGP signature

Re: recommends for apparmor in newest linux-image-4.13

[W. Martin Borgert]

On 2017-11-28 20:22, Russ Allbery wrote:
> My personal pet "I don't have time" project I'd love to see is extending
> systemd units for as many services in Debian as possible to include
> namespace restrictions and seccomp filter rules,

Hear, hear!

Re: recommends for apparmor in newest linux-image-4.13

[Jonathan Dowland]

On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote:

My personal pet "I don't have time" project I'd love to see is extending
systemd units for as many services in Debian as possible to include
namespace restrictions and seccomp filter rules, which I think has good
parallel potential alongside an LSM for raising the default security
posture of Debian.  LSMs deal with per-file restrictions much more easily
than systemd's seccomp and namespace support, but the seccomp and
namespace support does a lot of other nice things that LSMs aren't as good
at.


Yes this would be excellent; a necessary prerequisite would be getting
more daemons (and cron-scheduled processes) shipping systemd units too.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: recommends for apparmor in newest linux-image-4.13

[intrigeri]

Hi Michael,

Michael Stone:
> FWIW, I also think apparmor a bad idea,

For me it's good news: if you explain why (please?), it will furnish
nutrient to this discussion and we'll be in a better position to make
the best decision we can for our users and free software :)

> but it's somehow morphed from "can we make it possible to turn
> apparmor on" to "let's make RC bugs for stuff that doesn't work with
> apparmor" without much real buy-in AFAICT.

Regarding "can we make it possible to turn apparmor on": this has been
possible for years and was announced on d-d-a@ 2.5 years ago. This is
*not* what the proposal I've sent in August was about: that one was
explicitly about enabling AppArmor by default. If you're suggesting
there's been a decision making process mishap, then I'll need to be
explained why, because I don't get it.

Regarding "without much real buy-in": even though I believe we've
reached consensus on my proposal between August and October (as Ian
Jackson explained last week on this mailing list), I agree with you on
this one. This proposal did not trigger an overwhelming wave of
enthusiastic support. We don't make decisions by public acclamation
here but still, it's an important data point and IMO it implicitly
raises the bar wrt. how good our AppArmor support must be in order to
be acceptable by the project.

Regarding RC bugs: I don't think breakage that only happens with
AppArmor enabled should be RC in the context of the experiment we're
currently running: in the vast majority of cases, a local workaround
is available (one can disable the faulty AppArmor profile with the
aa-disable command). If we decide to leave AppArmor enabled by default
in Buster we should reconsider this though. Regardless of bug
severity, I want to keep fixing these bugs. If you need help with
AppArmor-related issues, you can ensure they're on pkg-apparmor-team's
radar this way:

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

Cheers,
-- 
intrigeri

Re: recommends for apparmor in newest linux-image-4.13

[Russ Allbery]

Michael Stone  writes:

> FWIW, I also think apparmor a bad idea, but it's somehow morphed from
> "can we make it possible to turn apparmor on" to "let's make RC bugs for
> stuff that doesn't work with apparmor" without much real buy-in AFAICT.

Well, it's been possible to turn AppArmor on for a long time.  The recent
debian-devel discussion was about making it the default, which I think
would have made it reasonably obvious that bugs with AppArmor enabled are
going to at least have a much higher severity.

The proponents were quite clear and unambiguous about what they were
trying to do, and there were almost no objections in debian-devel, so it
does seem quite reasonable for them to proceed.

I'm wholeheartedly in favor of trying to get Debian to integrate well with
*some* LSM.  I think it's more important to get one of them to work than
exactly which one; the security benefits of having *any* LSM in place with
halfway decent rule coverage are pretty substantial.  I have no particular
opinion about the relative merits of AppArmor, but it's being actively
developed and Ubuntu has already done a lot of the integration work, so it
makes sense for it to be a potential path of least resistance to having
some LSM available by default.

Maybe SELinux would be better, but various people have been trying to make
SELinux better-integrated with Debian for quite some time, and those
efforts don't seem to have been particularly successful.  Ubuntu has
successfully shipped with AppArmor enabled.

My personal pet "I don't have time" project I'd love to see is extending
systemd units for as many services in Debian as possible to include
namespace restrictions and seccomp filter rules, which I think has good
parallel potential alongside an LSM for raising the default security
posture of Debian.  LSMs deal with per-file restrictions much more easily
than systemd's seccomp and namespace support, but the seccomp and
namespace support does a lot of other nice things that LSMs aren't as good
at.

-- 
Russ Allbery (r...@debian.org)   

Re: recommends for apparmor in newest linux-image-4.13

[Michael Stone]

On Wed, Nov 29, 2017 at 12:03:08AM +0100, Marco d'Itri wrote:

On Nov 28, Christoph Hellwig  wrote:

It's just a bad idea of a security model that implements ad-hoc
and mostly path based restrictions instead of an actually verified
security model.  Using that by default makes it much harder to actually
use a real MAC based security model, which not only is required for
various security sensitive deployments but also a good idea in general.

This may be true, but OTOH nobody cared enough about SELinux to actually
make it work out of the box in Debian.


By that criteria, it doesn't seem like anyone cares about apparmor 
either... 


FWIW, I also think apparmor a bad idea, but it's somehow morphed
from "can we make it possible to turn apparmor on" to "let's make RC 
bugs for stuff that doesn't work with apparmor" without much real buy-in 
AFAICT.


Mike Stone

Re: recommends for apparmor in newest linux-image-4.13

[Marco d'Itri]

On Nov 28, Christoph Hellwig  wrote:

> It's just a bad idea of a security model that implements ad-hoc
> and mostly path based restrictions instead of an actually verified
> security model.  Using that by default makes it much harder to actually
> use a real MAC based security model, which not only is required for
> various security sensitive deployments but also a good idea in general.
This may be true, but OTOH nobody cared enough about SELinux to actually 
make it work out of the box in Debian.
So, for the time being I would gladly accept an inferior solution.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: recommends for apparmor in newest linux-image-4.13

[Christoph Hellwig]

On Thu, Nov 23, 2017 at 03:43:10PM +0100, Lars Wirzenius wrote:
> 
> do you think you could manage to either point the general -devel
> reading population to a discussion of why using AppArmor by default is
> horrible news, or write that yourself? That would seem to be more
> constructive than you just showing up after months of discussion
> saying it's horrible news.

It's just a bad idea of a security model that implements ad-hoc
and mostly path based restrictions instead of an actually verified
security model.  Using that by default makes it much harder to actually
use a real MAC based security model, which not only is required for
various security sensitive deployments but also a good idea in general.

Last but not least apparmor had various issues where certain distros
shipped non-upstream features that later turned out to be incompatible
with what went upstream.

Re: recommends for apparmor in newest linux-image-4.13

[Ian Jackson]

maximilian attems writes ("Re: recommends for apparmor in newest 
linux-image-4.13"):
> On Thu, Nov 23, 2017 at 03:00:49PM +0100, Wouter Verhelst wrote:
> > [1] https://lists.debian.org/debian-devel/2017/08/msg00090.html
> > [2] https://lists.debian.org/debian-devel/2017/10/threads.html#00086
> > [3] https://lists.debian.org/debian-devel/2017/11/threads.html#0
> 
> This doesn't strike me as a discussion, but looks more like a predetermined 
> setup.

The reason it doesn't look very discussion-ish is that no-one replied
to explain why the proposed approach was a bad idea.  So there was a
bit of discussion of details, but general agreement.  That's how
consensus works.

The tenor of the mails was very good and clearly invited discussion
and dissent.  Nevertheless, if you can explain now why it's a bad
idea, please do so.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These 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: recommends for apparmor in newest linux-image-4.13

[maximilian attems]

On Thu, Nov 23, 2017 at 03:00:49PM +0100, Wouter Verhelst wrote:
> On Thu, Nov 23, 2017 at 02:18:46PM +0100, Christoph Hellwig wrote:
> > Hi all,
> > 
> > is there any good reason for the recommends of apparmor in the latest
> > linux packages?
> 
> This is in response to a discussion that happened on this list. The
> thread started in august last year[1], but really picked up speed last
> month[2] and this one[3].
> 
> The idea is that, if no critical issues are found, buster would release
> with AppArmor enabled by default. If critical issues are found, however,
> I expect the decision will be reversed (or at the least, postponed).
> 
> [1] https://lists.debian.org/debian-devel/2017/08/msg00090.html
> [2] https://lists.debian.org/debian-devel/2017/10/threads.html#00086
> [3] https://lists.debian.org/debian-devel/2017/11/threads.html#0
> 

This doesn't strike me as a discussion, but looks more like a predetermined 
setup.

Re: recommends for apparmor in newest linux-image-4.13

[Lars Wirzenius]

On Thu, Nov 23, 2017 at 03:01:09PM +0100, Christoph Hellwig wrote:
> That's still not an upstream default lsm.  Looks like someone in
> Debian just decided to make apparmor the default, which is horrible
> news :(

Hello, Christoph,

do you think you could manage to either point the general -devel
reading population to a discussion of why using AppArmor by default is
horrible news, or write that yourself? That would seem to be more
constructive than you just showing up after months of discussion
saying it's horrible news.

(If you need to, I can lend you my time machine so you can send the
explantion last year and we can avoid escalating things to the current
stage.)

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: recommends for apparmor in newest linux-image-4.13

[Jonathan Dowland]

On Thu, Nov 23, 2017 at 03:01:09PM +0100, Christoph Hellwig wrote:

That's still not an upstream default lsm.  Looks like someone in
Debian just decided to make apparmor the default, which is horrible
news :(


not "just decided", it was extensively discussed.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: recommends for apparmor in newest linux-image-4.13

[Christoph Hellwig]

On Thu, Nov 23, 2017 at 01:59:44PM +, Ben Hutchings wrote:
> On Thu, 2017-11-23 at 14:58 +0100, Christoph Hellwig wrote:
> > On Thu, Nov 23, 2017 at 01:55:49PM +, Ben Hutchings wrote:
> > > AppArmor is the default LSM.
> > 
> > There is no such thing as a default LSM in Linux.
> 
> $ grep DEFAULT_SECURITY /boot/config-4.13.0-1-amd64 
> # CONFIG_DEFAULT_SECURITY_SELINUX is not set
> # CONFIG_DEFAULT_SECURITY_TOMOYO is not set
> CONFIG_DEFAULT_SECURITY_APPARMOR=y
> # CONFIG_DEFAULT_SECURITY_DAC is not set
> CONFIG_DEFAULT_SECURITY="apparmor"

That's still not an upstream default lsm.  Looks like someone in
Debian just decided to make apparmor the default, which is horrible
news :(

Re: recommends for apparmor in newest linux-image-4.13

[Christoph Hellwig]

On Thu, Nov 23, 2017 at 01:55:49PM +, Ben Hutchings wrote:
> AppArmor is the default LSM.

There is no such thing as a default LSM in Linux.

> > The changelog suggests it was done that systemd units might use it,
> > but in that case those systemd units should depend on apparmor.
> 
> They don't depend on AppArmor unless it's enabled.  Which is a decision
> made in the kernel configuration (potentially overriden by the kernel
> comamnd line).

So we should not need the recommends.

Re: recommends for apparmor in newest linux-image-4.13

[Wouter Verhelst]

On Thu, Nov 23, 2017 at 02:18:46PM +0100, Christoph Hellwig wrote:
> Hi all,
> 
> is there any good reason for the recommends of apparmor in the latest
> linux packages?

This is in response to a discussion that happened on this list. The
thread started in august last year[1], but really picked up speed last
month[2] and this one[3].

The idea is that, if no critical issues are found, buster would release
with AppArmor enabled by default. If critical issues are found, however,
I expect the decision will be reversed (or at the least, postponed).

[1] https://lists.debian.org/debian-devel/2017/08/msg00090.html
[2] https://lists.debian.org/debian-devel/2017/10/threads.html#00086
[3] https://lists.debian.org/debian-devel/2017/11/threads.html#0

> apparomor is just one of many security modules, and
> a fairly bogus one to start with.  The kernel should not recommend it
> as it doesn't add at all to the expected kernel functionality.

If AppArmor is to become the default, then having it be recommended by
the kernel is a proper way of implementing that; it would be pulled in
by default, but if you don't want it it's still possible to remove it.

(I won't comment on the "fairly bogus one" bit, I'm not that well versed
in the specifics of AppArmor vs the other options there)

> The changelog suggests it was done that systemd units might use it,
> but in that case those systemd units should depend on apparmor.

Perhaps the changelog could be clarified then, there are other reasons
:-)

> And to start with there probably should be a policty that no unit
> file shall fail the boot for a missing security module (any of them).

Yes, indeed. I haven't seen such a failure; but if you have, then please
do file a bug -- that's not supposed to happen.

Thanks,

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

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


signature.asc
Description: PGP signature

Re: recommends for apparmor in newest linux-image-4.13

[Ben Hutchings]

On Thu, 2017-11-23 at 14:58 +0100, Christoph Hellwig wrote:
> On Thu, Nov 23, 2017 at 01:55:49PM +, Ben Hutchings wrote:
> > AppArmor is the default LSM.
> 
> There is no such thing as a default LSM in Linux.

$ grep DEFAULT_SECURITY /boot/config-4.13.0-1-amd64 
# CONFIG_DEFAULT_SECURITY_SELINUX is not set
# CONFIG_DEFAULT_SECURITY_TOMOYO is not set
CONFIG_DEFAULT_SECURITY_APPARMOR=y
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="apparmor"

> > > The changelog suggests it was done that systemd units might use it,
> > > but in that case those systemd units should depend on apparmor.
> > 
> > They don't depend on AppArmor unless it's enabled.  Which is a decision
> > made in the kernel configuration (potentially overriden by the kernel
> > comamnd line).
> 
> So we should not need the recommends.
-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson



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

Re: recommends for apparmor in newest linux-image-4.13

[Ben Hutchings]

On Thu, 2017-11-23 at 14:18 +0100, Christoph Hellwig wrote:
> Hi all,
> 
> is there any good reason for the recommends of apparmor in the latest
> linux packages?  apparomor is just one of many security modules, and
> a fairly bogus one to start with.  The kernel should not recommend it
> as it doesn't add at all to the expected kernel functionality.

AppArmor is the default LSM.

> The changelog suggests it was done that systemd units might use it,
> but in that case those systemd units should depend on apparmor.

They don't depend on AppArmor unless it's enabled.  Which is a decision
made in the kernel configuration (potentially overriden by the kernel
comamnd line).

Ben.

> And to start with there probably should be a policty that no unit
> file shall fail the boot for a missing security module (any of them).

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson



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

recommends for apparmor in newest linux-image-4.13

[Christoph Hellwig]

Hi all,

is there any good reason for the recommends of apparmor in the latest
linux packages?  apparomor is just one of many security modules, and
a fairly bogus one to start with.  The kernel should not recommend it
as it doesn't add at all to the expected kernel functionality.

The changelog suggests it was done that systemd units might use it,
but in that case those systemd units should depend on apparmor.

And to start with there probably should be a policty that no unit
file shall fail the boot for a missing security module (any of them).