[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jKY+Fc5PcZdbXEXKXsxN2xb9Ext15yrhPrg4Afd1Rq_yA@mail.gmail.com>
Date: Thu, 25 May 2017 10:28:19 -0700
From: Kees Cook <keescook@...omium.org>
To: HacKurx <hackurx@...il.com>
Cc: 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, 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?
It might also be nice to have it be a kernel command line option as
well as a Kconfig, so that distros could include the Kconfig but not
enable it by default (interested users could set the command line
option to enable it).
Thanks!
-Kees
--
Kees Cook
Pixel Security
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.
