netdev - Re: Override default socket policy per cgroup

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 9 Feb 2022 13:02:07 -0800
From:   Martin KaFai Lau <kafai@...com>
To:     <sdf@...gle.com>
CC:     <ast@...nel.org>, <daniel@...earbox.net>, <netdev@...r.kernel.org>,
        <bpf@...r.kernel.org>
Subject: Re: Override default socket policy per cgroup

On Wed, Feb 09, 2022 at 09:03:45AM -0800, sdf@...gle.com wrote:
> Let's say I want to set some default sk_priority for all sockets in a
> specific cgroup. I can do it right now using cgroup/sock_create, but it
> applies only to AF_INET{,6} sockets. I'd like to do the same for raw
> (AF_PACKET) sockets and cgroup/sock_create doesn't trigger for them :-(
Other than AF_PACKET and INET[6], do you have use cases for other families?

> (1) My naive approach would be to add another cgroup/sock_post_create
> which runs late from __sock_create and triggers on everything.
> 
> (2) Another approach might be to move BPF_CGROUP_RUN_PROG_INET_SOCK and
> make it work with AF_PACKET. This might be not 100% backwards compatible
> but I'd assume that most users should look at the socket family before
> doing anything. (in this case it feels like we can extend
> sock_bind/release for af_packets as well, just for accounting purposes,
> without any way to override the target ifindex).
If adding a hook at __sock_create, I think having a new CGROUP_POST_SOCK_CREATE
may be better instead of messing with the current inet assumption
in CGROUP_'INET'_SOCK_CREATE.  Running all CGROUP_*_SOCK_CREATE at
__sock_create could be a nice cleanup such that a few lines can be
removed from inet[6]_create but an extra family check will be needed.

The bpf prog has both bpf_sock->family and bpf_sock->protocol field to
check with, so it should be able to decide the sk type if it is run
at __sock_create.  All bpf_sock fields should make sense or at least 0
to all families (?), please check.

For af_packet bind, the ip[46]/port probably won't be useful?  What
the bpf prog will need?