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
> > permis
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, mai
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
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
> p
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 AppAr
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
>
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 sav
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
>
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 rea
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
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
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.
>
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 appeali
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 th
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 c
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
]] 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-d
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'
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,
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 everyon
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 design
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
> lo
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 mad
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 quit
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 particular
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
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 tu
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
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!
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 alo
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 f
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 lo
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 act
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 onl
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
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/2
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 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
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
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 D
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
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
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_SELINU
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 doe
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 sug
45 matches
Mail list logo
