netdev - Re: [PATCH v2] socket.7: Document some BPF-related socket options

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 1 Mar 2016 10:40:32 -0500
From:	Craig Gallek <kraigatgoog@...il.com>
To:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:	Vincent Bernat <bernat@...fy.cx>, linux-man@...r.kernel.org,
	netdev <netdev@...r.kernel.org>,
	Alexei Starovoitov <alexei.starovoitov@...il.com>
Subject: Re: [PATCH v2] socket.7: Document some BPF-related socket options

On Tue, Mar 1, 2016 at 5:29 AM, Michael Kerrisk (man-pages)
<mtk.manpages@...il.com> wrote:
> On 03/01/2016 11:10 AM, Vincent Bernat wrote:
>>  ❦  1 mars 2016 11:03 +0100, "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com> :
>>
>>>           Once   the   SO_LOCK_FILTER  option  has  been  enabled,
>>>           attempts by an unprivileged process to change or  remove
>>>           the  filter  attached  to  a  socket,  or to disable the
>>>           SO_LOCK_FILTER option will fail with the error EPERM.
>>
>> You should remove "unprivileged". I didn't try to check for permissions
>> because I was just lazy (and I didn't have a need for it). As root, you
>> can just recreate another socket.
>
> Bother. That's what I meant to do, and then I omitted to do it! Done now
> And thanks for catching that, Vincent.
>
> Revised text below, with another query.
>
>        SO_LOCK_FILTER
>               When set, this option will prevent changing the  filters
>               associated  with  the socket.  These filters include any
>               set   using   the   socket   options   SO_ATTACH_FILTER,
>               SO_ATTACH_BPF,        SO_ATTACH_REUSEPORT_CBPF       and
>               SO_ATTACH_REUSEPORT_EPBF.
>
>               The typical use case is for a privileged process to  set
>               up  a  socket with restrictive filters, set SO_LOCK_FIL‐
>               TER, and then either drop its  privileges  or  pass  the
>               socket file descriptor to an unprivileged process.
>
>               Once   the   SO_LOCK_FILTER  option  has  been  enabled,
>               attempts to change or remove the filter  attached  to  a
>               socket,  or  to  disable  the SO_LOCK_FILTER option will
>               fail with the error EPERM.
>
> I think the second paragraph should probably drop mention of privileges,
> right? In fact, maybe just drop the paragraph altogether?
Thanks Michael, all of your changes in the git tree look good to me.
I parsed the one-way nature of LOCK_FILTER completely backwards from
the commit message.  It's describing BSD's root-modify behavior, not
the implementation in Linux.  I think I like this last paragraph as
you have it to explicitly call out this as intended behavior.

Thanks again,
Craig

> Cheers,
>
> Michael
>
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/