From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932146AbcH0Ofl (ORCPT ); Sat, 27 Aug 2016 10:35:41 -0400 Received: from smtp-sh2.infomaniak.ch ([128.65.195.6]:51815 "EHLO smtp-sh2.infomaniak.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753322AbcH0Ofj (ORCPT ); Sat, 27 Aug 2016 10:35:39 -0400 Subject: Re: [RFC v2 09/10] landlock: Handle cgroups (program types) 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 From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: <57C1A50F.60605@digikod.net> Date: Sat, 27 Aug 2016 16:34:55 +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="UJCILjBJ49pKIqv7c57p9OiCUgIKp5eqo" 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) --UJCILjBJ49pKIqv7c57p9OiCUgIKp5eqo Content-Type: multipart/mixed; boundary="EcTFwxMO4xrUr4JB7meVvf4H9AtI5xrAr" 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 Message-ID: <57C1A50F.60605@digikod.net> Subject: Re: [RFC v2 09/10] landlock: Handle cgroups (program types) 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> --EcTFwxMO4xrUr4JB7meVvf4H9AtI5xrAr 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: > >>> As far as safety and type checking that bpf programs has to do, >>> I like the approach of patch 06/10: >>> +LANDLOCK_HOOK2(file_open, FILE_OPEN, >>> + PTR_TO_STRUCT_FILE, struct file *, file, >>> + PTR_TO_STRUCT_CRED, const struct cred *, cred >>> +) >>> teaching verifier to recognize struct file, cred, sockaddr >>> will let bpf program access them naturally without any overhead. >>> Though: >>> @@ -102,6 +102,9 @@ enum bpf_prog_type { >>> BPF_PROG_TYPE_SCHED_CLS, >>> BPF_PROG_TYPE_SCHED_ACT, >>> BPF_PROG_TYPE_TRACEPOINT, >>> + BPF_PROG_TYPE_LANDLOCK_FILE_OPEN, >>> + BPF_PROG_TYPE_LANDLOCK_FILE_PERMISSION, >>> + BPF_PROG_TYPE_LANDLOCK_MMAP_FILE, >>> }; >>> is a bit of overkill. >>> I think it would be cleaner to have single >>> BPF_PROG_TYPE_LSM and at program load time pass >>> lsm_hook_id as well, so that verifier can do safety checks >>> based on type info provided in LANDLOCK_HOOKs >> >> I first started with a unique BPF_PROG_TYPE but, the thing is, the BPF= >> verifier check programs according to their types. If we need to check >> specific context value types (e.g. PTR_TO_STRUCT_FILE), we need a >> dedicated program types. I don't see any other way to do it with the >> current verifier code. Moreover it's the purpose of program types, rig= ht? >=20 > Adding new bpf program type for every lsm hook is not acceptable. > Either do one new program type + pass lsm_hook_id as suggested > or please come up with an alternative approach. OK, so we have to modify the verifier to not only rely on the program type but on another value to check the context accesses. Do you have a hint from where this value could come from? Do we need to add a new bpf command to associate a program to a subtype? --EcTFwxMO4xrUr4JB7meVvf4H9AtI5xrAr-- --UJCILjBJ49pKIqv7c57p9OiCUgIKp5eqo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJXwaUQAAoJECLe/t9zvWqVr8AIAJJUHrL3vkMSUYwYnMXh+KTd JlFt5bZREQSkctvFcdb6Ynt+DdI0eMuNGyxYqh4TiqV2sqW8htOpyqdjbzzUv3g2 /HTP/V0WGNZu31C7Tj5Wiw1guBKg9HfTAzrGjDh35ZXs5EWVe1gglR8+0ocA8qdB 2c7JZPiOiLTXhWO2YcSe0020KQ3qNLfr5RrPROAwfNdwDsQhf0fjkQNajm9Qzj/2 FwEGPnEjmrkddWQ4KcKuJOeyewDPzLLo1iba2+j+u+zpyX9gb7wcLWSiIz9N/c2O dwK+bNdXE2xcL7TkBXwFSk4dNyGPzN26enqHwcCvqdbdXXyl9qZ7pubG0TUjgII= =73Hj -----END PGP SIGNATURE----- --UJCILjBJ49pKIqv7c57p9OiCUgIKp5eqo--