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
| ||
|
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?
Powered by blists - more mailing lists