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] [thread-next>] [day] [month] [year] [list]

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

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?

Cheers,

Michael
 


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