[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1495787025.2392.0.camel@gmail.com>
Date: Fri, 26 May 2017 04:23:45 -0400
From: Daniel Micay <danielmicay@...il.com>
To: Anisse Astier <anisse@...ier.eu>, Kees Cook <keescook@...omium.org>
Cc: HacKurx <hackurx@...il.com>, Rik van Riel <riel@...hat.com>, intrigeri
<intrigeri@...m.org>, "kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>
Subject: Re: Patch for random mac address
On Thu, 2017-05-25 at 23:28 +0200, Anisse Astier wrote:
> Hi,
>
> On Thu, May 25, 2017 at 10:28:19AM -0700, Kees Cook wrote:
> > On Thu, May 25, 2017 at 8:59 AM, Rik van Riel <riel@...hat.com>
> > wrote:
> > > On Thu, 2017-05-25 at 17:47 +0200, intrigeri wrote:
> > > > Rik van Riel:
> > > > > That suggests maybe this kind of functionality should
> > > > > be implemented in userspace, instead?
> > > > > Maybe in NetworkManager, […]
> > > >
> > > > It's already implemented in NetworkManager :)
> > >
> > > So this kernel patch does not solve any problem,
> > > because the solution has already been implemented
> > > in userspace?
> >
> > It makes sure you can never not randomize the MAC, no matter what
> > userspace is doing. I'm not opposed to the idea, but it feels like
> > overkill to me.
> >
> > BTW, the proposed patch is slightly wrong: it still allows userspace
> > to change the MAC address. The ifdef with the return 0 should be
> > moved
> > up (and "return 0" seems like a bit of a lie: maybe -EINVAL or
> > -ENOTSUPPORTED?). How about sending a v2 with that fixed, inline,
> > etc.
> > And see if other people chime in?
>
> Yes, the original grsec patch is slightly different.
It was never included in grsecurity, so it's not really a grsecurity
patch.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
