From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754090AbcH0OT4 (ORCPT ); Sat, 27 Aug 2016 10:19:56 -0400 Received: from smtp-sh2.infomaniak.ch ([128.65.195.6]:42866 "EHLO smtp-sh2.infomaniak.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751195AbcH0OTy (ORCPT ); Sat, 27 Aug 2016 10:19:54 -0400 Subject: Re: [RFC v2 09/10] landlock: Handle cgroups (netfilter match) To: Alexei Starovoitov References: <1472121165-29071-1-git-send-email-mic@digikod.net> <1472121165-29071-10-git-send-email-mic@digikod.net> <20160826021432.GA8291@ast-mbp.thefacebook.com> <57C05BF0.8000706@digikod.net> <20160826230539.GA26683@ast-mbp.thefacebook.com> Cc: linux-kernel@vger.kernel.org, Alexei Starovoitov , Andy Lutomirski , Daniel Borkmann , Daniel Mack , "David S . Miller" , Kees Cook , Sargun Dhillon , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, netdev@vger.kernel.org, Tejun Heo , cgroups@vger.kernel.org From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: <57C1A159.3040905@digikod.net> Date: Sat, 27 Aug 2016 16:19:05 +0200 User-Agent: MIME-Version: 1.0 In-Reply-To: <20160826230539.GA26683@ast-mbp.thefacebook.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1AViPhua595H5srXjQ5OLiUBFcsaS6goS" X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1AViPhua595H5srXjQ5OLiUBFcsaS6goS Content-Type: multipart/mixed; boundary="kh3cLFMnt3QneMnCbueAoIcvaI7inpQLW" From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= To: Alexei Starovoitov Cc: linux-kernel@vger.kernel.org, Alexei Starovoitov , Andy Lutomirski , Daniel Borkmann , Daniel Mack , "David S . Miller" , Kees Cook , Sargun Dhillon , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, netdev@vger.kernel.org, Tejun Heo , cgroups@vger.kernel.org Message-ID: <57C1A159.3040905@digikod.net> Subject: Re: [RFC v2 09/10] landlock: Handle cgroups (netfilter match) References: <1472121165-29071-1-git-send-email-mic@digikod.net> <1472121165-29071-10-git-send-email-mic@digikod.net> <20160826021432.GA8291@ast-mbp.thefacebook.com> <57C05BF0.8000706@digikod.net> <20160826230539.GA26683@ast-mbp.thefacebook.com> In-Reply-To: <20160826230539.GA26683@ast-mbp.thefacebook.com> --kh3cLFMnt3QneMnCbueAoIcvaI7inpQLW Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 27/08/2016 01:05, Alexei Starovoitov wrote: > On Fri, Aug 26, 2016 at 05:10:40PM +0200, Micka=EBl Sala=FCn wrote: >> To sum up, there is four related patchsets: >> * "Landlock LSM: Unprivileged sandboxing" (this series) >> * "Add Checmate, BPF-driven minor LSM" (Sargun Dhillon) >> * "Networking cgroup controller" (Anoop Naravaram) >> * "Add eBPF hooks for cgroups" (Daniel Mack) >>> Anoop Naravaram's use case is to control the ports the applications >>> under cgroup can bind and listen on. >>> Such use case can be solved by such 'lsm cgroup controller' by >>> attaching bpf program to security_socket_bind lsm hook and >>> filtering sockaddr. >>> Furthermore Sargun's use case is to allow further sockaddr rewrites >>> from the bpf program which can be done as natural extension >>> of such mechanism. >>> >>> If I understood Daniel's Anoop's Sargun's and yours use cases >>> correctly the common piece of kernel infrastructure that can solve >>> them all can start from Daniel's current set of patches that >>> establish a mechanism of attaching bpf program to a cgroup. >>> Then adding lsm hooks to it and later allowing argument rewrite >>> (since they're already in the kernel and no ToCToU problems exist) >> For the network-related series, I think it make more sense to simply >> create a netfilter rule matching a cgroup and then add more features t= o >> netfilter (restrict port ranges and so on) thanks to eBPF programs. >> Containers are (usually) in a dedicated network namespace, which open >> the possibility to not only rely on cgroups (e.g. match UID, >> netmask...). It would also be more flexible to be able to load a BPF >> program in netfilter and update its maps on the fly to make dynamic >> rules, like ipset does, but in a more generic way. What do the netdev folks think about this design? --kh3cLFMnt3QneMnCbueAoIcvaI7inpQLW-- --1AViPhua595H5srXjQ5OLiUBFcsaS6goS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJXwaFZAAoJECLe/t9zvWqVnOgIAJE9TzZwl16ivzLISKo6pHhM op6kdDEYJERxX/xLBzeHWKYm2vFADhuWq8ijIAJmWFdriCSkJsX0x6YA4raUgEU7 cBTo26EqJ5zGPVIFWC4+PpXAxxQRS/s2lCqH4SRgtD2Shmpjb/end1IkEcuwFPiR unrF3OuwOe/T9JT8xaTqrefjYfgV9f06nVbLGTdj8wHLZk7aV+dWAIcD0gVE9jIc gtB7XVlHR0X1yKDIwKp0mgkAC/xgQtvCp5qNXtHPgZr3x7XEEhLa2IHE4WeFinCC gLZF8ovbtHSr2Dr1A02p5EulOpvmvBZ5lqrk2F70RzRxrDbtX+luBJrnvpS5Ux8= =inYj -----END PGP SIGNATURE----- --1AViPhua595H5srXjQ5OLiUBFcsaS6goS--