On Tue, 2020-11-17 at 17:19 +, Ben Hutchings wrote:
> On Tue, 2020-11-17 at 11:18 -0500, Antoine Beaupré wrote:
> [...]
> > Could we get a little more hard data about the attack vectors here? I
> > totally trust the security team's "gut feeling" on this, but it would be
> > great to be able to
On Tue, 2020-11-17 at 11:18 -0500, Antoine Beaupré wrote:
[...]
> Could we get a little more hard data about the attack vectors here? I
> totally trust the security team's "gut feeling" on this, but it would be
> great to be able to evaluate more concretely what we're talking about
> here.
>
>
On 2020-10-22 22:55:33, Salvatore Bonaccorso wrote:
> Hi,
>
> On Tue, Oct 20, 2020 at 05:21:24PM +0100, Simon McVittie wrote:
>> On Thu, 16 Apr 2020 at 03:09:25 +0100, Ben Hutchings wrote:
>> > I don't think we should keep patching in
>> > kernel.unprivileged_userns_clone forever, so the
On Tue, 2020-10-20 at 17:21 +0100, Simon McVittie wrote:
> On Thu, 16 Apr 2020 at 03:09:25 +0100, Ben Hutchings wrote:
> > I don't think we should keep patching in
> > kernel.unprivileged_userns_clone forever, so the documented way to
> > disable user namespaces should be setting
I think there are two aspects here. (In)security of unpriv user ns is one of
them - personally I'm in favor of opinions from people who argue that the
attack vector they open will remain for foreseeable future because kernel is
simply too big to fix all bugs. The other thing is that containers
On Thu, Oct 22, 2020 at 10:55:33PM +0200, Salvatore Bonaccorso wrote:
> TBH, I think not having it enabled by default until now saved us a
> couple of time from needing to release urgent fixes. It is more a gut
> feeling and might not have enough weight: but having it still disabled
> in bullseye
On Thu, Oct 22, 2020 at 10:55:33PM +0200, Salvatore Bonaccorso wrote:
> but having it still disabled
> in bullseye by default we would be still better of from security
> releases/DSA's perspectives.
Agreed.
Cheers,
Moritz
Hi,
On Tue, Oct 20, 2020 at 05:21:24PM +0100, Simon McVittie wrote:
> On Thu, 16 Apr 2020 at 03:09:25 +0100, Ben Hutchings wrote:
> > I don't think we should keep patching in
> > kernel.unprivileged_userns_clone forever, so the documented way to
> > disable user namespaces should be setting
On Thu, 16 Apr 2020 at 03:09:25 +0100, Ben Hutchings wrote:
> I don't think we should keep patching in
> kernel.unprivileged_userns_clone forever, so the documented way to
> disable user namespaces should be setting user.max_user_namespaces to
> 0. But then there's no good way to have a drop-in
On Wed, 2020-04-15 at 08:32 +0100, Simon McVittie wrote:
> On Wed, 15 Apr 2020 at 02:52:11 +0100, Ben Hutchings wrote:
> > I think you've made a good case that user namespaces are likely to be a
> > net positive for security on Debian desktop systems.
> >
> > This might not be true yet for
On Wed, 15 Apr 2020 at 02:52:11 +0100, Ben Hutchings wrote:
> I think you've made a good case that user namespaces are likely to be a
> net positive for security on Debian desktop systems.
>
> This might not be true yet for servers that aren't container hosts.
Perhaps Debian's kernel should
On Mon, 2020-03-30 at 10:56 +0100, Simon McVittie wrote:
> On Fri, 11 May 2018 at 20:44:50 +0200, Laurent Bigonville wrote:
> > Firefox (and probably other applications) are using user namespaces these
> > days to enhance the security.
> >
> > Debian is disabling these since 2013, the original
On Mon, Mar 30, 2020 at 10:56:48AM +0100, Simon McVittie wrote:
> On Fri, 11 May 2018 at 20:44:50 +0200, Laurent Bigonville wrote:
> > Firefox (and probably other applications) are using user namespaces these
> > days to enhance the security.
> >
> > Debian is disabling these since 2013, the
On Fri, 11 May 2018 at 20:44:50 +0200, Laurent Bigonville wrote:
> Firefox (and probably other applications) are using user namespaces these
> days to enhance the security.
>
> Debian is disabling these since 2013, the original patch states it's a
> short term solution, but we are here 5 years
Le 13/05/18 à 01:33, Ben Hutchings a écrit :
Control: tag -1 moreinfo
On Fri, 2018-05-11 at 20:44 +0200, Laurent Bigonville wrote:
Source: linux
Version: 4.16.5-1
Severity: normal
Hi,
Firefox (and probably other applications) are using user namespaces these
days to enhance the security.
Can
Control: tag -1 - moreinfo
On Sun, 2018-05-13 at 19:19 +0200, Frederik Himpe wrote:
> On Sun, 13 May 2018 00:33:02 +0100 Ben Hutchings
> wrote:
> > Control: tag -1 moreinfo
> >
> > On Fri, 2018-05-11 at 20:44 +0200, Laurent Bigonville wrote:
> > > Source: linux
> > >
Ben Hutchings wrote:
> And this still mitigates a significant fraction of the security issues
> found in the kernel.
A quite significant fraction; on average this neutralises a root privilege
escalation every month or so. This is really not something that we should
re-enable any time soon.
On Sun, 13 May 2018 00:33:02 +0100 Ben Hutchings
wrote:
> Control: tag -1 moreinfo
>
> On Fri, 2018-05-11 at 20:44 +0200, Laurent Bigonville wrote:
> > Source: linux
> > Version: 4.16.5-1
> > Severity: normal
> >
> > Hi,
> >
> > Firefox (and probably other applications)
Control: tag -1 moreinfo
On Fri, 2018-05-11 at 20:44 +0200, Laurent Bigonville wrote:
> Source: linux
> Version: 4.16.5-1
> Severity: normal
>
> Hi,
>
> Firefox (and probably other applications) are using user namespaces these
> days to enhance the security.
Can you provide some information
Source: linux
Version: 4.16.5-1
Severity: normal
Hi,
Firefox (and probably other applications) are using user namespaces these
days to enhance the security.
Debian is disabling these since 2013, the original patch states it's a
short term solution, but we are here 5 years later and they are
20 matches
Mail list logo