Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp924819iog; Wed, 15 Jun 2022 15:50:23 -0700 (PDT) X-Google-Smtp-Source: AGRyM1v8i88YNg5epZgded+wqS0DKMaLAsNnzAfpDjrQjBquUsvQHNDh/nzbS9HjbUkLBm5cAACX X-Received: by 2002:a17:907:16a2:b0:711:d048:7d41 with SMTP id hc34-20020a17090716a200b00711d0487d41mr1909514ejc.126.1655333423686; Wed, 15 Jun 2022 15:50:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655333423; cv=none; d=google.com; s=arc-20160816; b=fftGCnjoN2XGIrx7Y/SpEaq31qxyH8ZmsTWy0xMvI38GNhN77uxvsW2iRodIgjkizO smxQEWWteJF9uMbZKxXmk1dH8cXqPXXDjUiM1ToOIB6oXZbcDkjE/jIanUCClS+Hz9ne SgWbCszC2Q0z96I2kHvek4OS3tWimPpiBWoi8STyQBfENLagcc5uhmzZLuV8G8R/eT5O tGLbjNmNRg5jWlRdadXr7Pr3cZnKcJltEKhNYwIWSonN6k3cH6BZ6oyX8HHmS6NFTB/V m1S2TDxQea+wkP0SPHLvVP/rd7/gkarWH7EwkAilsGUY9Ilv7uXmf5TlbhGSjj3SPqvh hjHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=0nYF2+L0+nfm2ZZrGFnn5kpR2H6SVKM0WrlyyHrypck=; b=p/GdmZZavzdZGyJM4JQxMFRETN0T25TEuF2dDeYkeileGU0/RJCaTe4bVl+i0uhZBb dXkZ6HyUDdKe0j6IjfMKjTjurlDq0RteBF6ZwJWVvUuzPuWPJ1nVDrtjxdyiua5Bo3uj 61gyLMexuttnyn7jpxa61pWLMRSw9UsxwlILbOSUiITekVxDuoPUx2lze2dGkVD6/gjN /nk27ZMsa7FI3MXMMxSbigZf2AlusbHEwG2RTOhUl4r6XkdHf8bF01smOzOxY1mb2dZS YPaz6GnAGPJKQSKyO0+Bpiif/NWr2oMjljPytjevJH+S3FW0tQmJoRFJ3IceJ2tkZVwi pPJg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b=IfERn+03; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 22-20020a17090600d600b00718bebeb259si11061327eji.696.2022.06.15.15.49.56; Wed, 15 Jun 2022 15:50:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b=IfERn+03; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349840AbiFOWMn (ORCPT + 99 others); Wed, 15 Jun 2022 18:12:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34658 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345675AbiFOWMk (ORCPT ); Wed, 15 Jun 2022 18:12:40 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9C724109E for ; Wed, 15 Jun 2022 15:12:33 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id v14so17106872wra.5 for ; Wed, 15 Jun 2022 15:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0nYF2+L0+nfm2ZZrGFnn5kpR2H6SVKM0WrlyyHrypck=; b=IfERn+03UqWtxXLyO34clbji2GIEw/NmkaNlK0oeunYY/1Hsy4RFRtzmZRukgQ38zS BZJDIKoEyYef2iPVHLWo2zeziufyg23fZvcvQwstDSlaP3Co8MYRvbvCA8cN7dzV+i86 M9xQetZI485xvvbOtVjDy+1wJG/y2zrDyysgM0Elv9145+H/1cUqnn220imqz118qZVu +GGQzJ2Ak9lVih6J0scW99b1gdgm0STHKRJXpOwAXryBgGma7c/m+VuTprCV/CjwXA/q qDPvEDudDimD3QikadNk3tJv8DuFl1zzvXPFPycPuDupe0Ih4S7u7yEFoOf/tZzq7MK0 J8zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0nYF2+L0+nfm2ZZrGFnn5kpR2H6SVKM0WrlyyHrypck=; b=8LrG0xyL7fs09VGSIj/7ijZr8JD4LRm5SWGI1QUu55rqbai3MnHvo9Dv/2qigRnwY7 6CWmOme0F1TdNyM6CMdazr40vi+pl3VNw/DQFKSuN2UgvBYy8KddMSnv8qPVPqs9vIHz VVU2yl9ysQRIsa8kOTsdjuS3v1LtzU2d2FzlesoXNeYnMjhbAK5+XYBlSrDDP32fQ8ko XoO/jyfPohlYdw1SLhN23dgLsH/5KXqgXEI4sjbQ2Oh+Ys2CTdkHgG1wzq3VQF8pimDK KBX+DgrsDkHk9tSVT3KFnj/iRaMFXqndtVk2YClEDliMF/Z4UZQSowN+GB4Bd4tcAReC PTyw== X-Gm-Message-State: AJIora/O8659eK5qWaBb+FAgBMynIwcTTjUoVjyEyjdY/4hkHdEvWXbo 6Ga5Tp/5OAsarYw8hi6N7Vt+H0/geAK4fDdRGb8J X-Received: by 2002:a05:6000:230:b0:210:31ca:28b8 with SMTP id l16-20020a056000023000b0021031ca28b8mr1794755wrz.538.1655331152126; Wed, 15 Jun 2022 15:12:32 -0700 (PDT) MIME-Version: 1.0 References: <1654714889-26728-1-git-send-email-deven.desai@linux.microsoft.com> <1654714889-26728-3-git-send-email-deven.desai@linux.microsoft.com> In-Reply-To: <1654714889-26728-3-git-send-email-deven.desai@linux.microsoft.com> From: Paul Moore Date: Wed, 15 Jun 2022 18:12:21 -0400 Message-ID: Subject: Re: [RFC PATCH v8 02/17] ipe: add policy parser To: Deven Bowers Cc: corbet@lwn.net, zohar@linux.ibm.com, jmorris@namei.org, serge@hallyn.com, tytso@mit.edu, ebiggers@kernel.org, axboe@kernel.dk, agk@redhat.com, snitzer@kernel.org, eparis@redhat.com, linux-doc@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-block@vger.kernel.org, dm-devel@redhat.com, linux-audit@redhat.com, roberto.sassu@huawei.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 8, 2022 at 3:03 PM Deven Bowers wrote: > > IPE's interpretation of the what the user trusts is accomplished through > its policy. IPE's design is to not provide support for a single trust > provider, but to support multiple providers to enable the end-user to > choose the best one to seek their needs. > > This requires the policy to be rather flexible and modular so that > integrity providers, like fs-verity, dm-verity, dm-integrity, or > some other system, can plug into the policy with minimal code changes, > and IPE can > > Signed-off-by: Deven Bowers > > --- > v2: > + Split evaluation loop, access control hooks, > and evaluation loop from policy parser and userspace > interface to pass mailing list character limit > > v3: > + Move policy load and activation audit event to 03/12 > + Fix a potential panic when a policy failed to load. > + use pr_warn for a failure to parse instead of an > audit record > + Remove comments from headers > + Add lockdep assertions to ipe_update_active_policy and > ipe_activate_policy > + Fix up warnings with checkpatch --strict > + Use file_ns_capable for CAP_MAC_ADMIN for securityfs > nodes. > + Use memdup_user instead of kzalloc+simple_write_to_buffer. > + Remove strict_parse command line parameter, as it is added > by the sysctl command line. > + Prefix extern variables with ipe_ > > v4: > + Remove securityfs to reverse-dependency > + Add SHA1 reverse dependency. > + Add versioning scheme for IPE properties, and associated > interface to query the versioning scheme. > + Cause a parser to always return an error on unknown syntax. > + Remove strict_parse option > + Change active_policy interface from sysctl, to securityfs, > and change scheme. > > v5: > + Cause an error if a default action is not defined for each > operaiton. > + Minor function renames > > v6: > + No changes > > v7: > + Further split parser and userspace interface into two > separate commits, for easier review. > > + Refactor policy parser to make code cleaner via introducing a > more modular design, for easier extension of policy, and > easier review. > > v8: > + remove unnecessary pr_info emission on parser loading > > + add explicit newline to the pr_err emitted when a parser > fails to load. > --- > include/asm-generic/vmlinux.lds.h | 16 + > security/ipe/Makefile | 6 + > security/ipe/ipe.c | 61 ++ > security/ipe/ipe.h | 5 + > security/ipe/ipe_parser.h | 59 ++ > security/ipe/modules.c | 109 +++ > security/ipe/modules.h | 17 + > security/ipe/modules/ipe_module.h | 33 + > security/ipe/parsers.c | 143 ++++ > security/ipe/parsers/Makefile | 12 + > security/ipe/parsers/default.c | 106 +++ > security/ipe/parsers/policy_header.c | 126 ++++ > security/ipe/policy.c | 946 +++++++++++++++++++++++++++ > security/ipe/policy.h | 97 +++ > 14 files changed, 1736 insertions(+) > create mode 100644 security/ipe/ipe_parser.h > create mode 100644 security/ipe/modules.c > create mode 100644 security/ipe/modules.h > create mode 100644 security/ipe/modules/ipe_module.h > create mode 100644 security/ipe/parsers.c > create mode 100644 security/ipe/parsers/Makefile > create mode 100644 security/ipe/parsers/default.c > create mode 100644 security/ipe/parsers/policy_header.c > create mode 100644 security/ipe/policy.c > create mode 100644 security/ipe/policy.h I had a few small comments while reading through this code, e.g. try to drop the support for quoted values, but I think my big issue here is that non-trivial string parsers in the kernel make me nervous and with +1700 lines spread across 14 files this is definitely a non-trivial parser. I understand the basic 'key=value' pair format, and I think that's okay, but I worry about the added complexity in the parser brought about by the need to introduce an abstraction layer between the core parser(s) and modules. I realize flexibility is an important part of IPE, and this relies on the ability to add support for new language keys/modules, but I don't believe that requires the level of indirection seen here. I'm not asking you to make radical changes to the IPE policy language, but I do believe spending some time to rethink how you parse the language would be a good idea. When in doubt keep the parser as simple as possible, you can always add complexity and more nuance in the future when the language requires it. The IPE policy language grammar is the immutable kernel/userspace API promise, not the parser implementation. -- paul-moore.com