Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1758373pxb; Wed, 10 Feb 2021 16:35:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJz7Qy3lQ8Ocn/65xnQqe9lkS659+3hOOTAzp6vwJ6zSa0xp9c2P1WWKHOL8+GhK89QlIG4V X-Received: by 2002:a50:f382:: with SMTP id g2mr5706686edm.273.1613003726422; Wed, 10 Feb 2021 16:35:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613003726; cv=none; d=google.com; s=arc-20160816; b=ceENSbbrp87BFLzcmn4GC12oHaZk6hRi/nQ9s6HNhyK3B4OJJpner/zzKzGjze5AEV fIzTk9v1WAXfkf4wctwCKbrKyHgc7/MOfcfYzgdy64zrEQnnrK7DNGRfqm6TDo2bgpjv vODY5EnyToyTT28sXvoufgTHFeUe99nTCtMGg9iHBSX7jarXrfHBjK92BeuNxsVDlpmx DDbk1mUrzkrmRz9Mc4fmo7RoFW03CluSFZaRSHg38GhUpUVZUFOaLjfwz59Op+1/Qr4z hoGGCnwnzFKmECflw5p2KsFVhQNrtrWh5cte60VAL4++wfvBTldOaC2HiDeZhv2Jdd/n K8xA== 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=RHZyjDLOFDi0ZfkqD61Yg3tZtOTffsyWTFvMKMIBqsk=; b=WzzBdoqWQqYVO87qFhmWhH/nau3F+qJcDzOteoqZA0uz4enVfj0Uoj6Y0LOOrzJRel SKPrkFkXbX9cbGRwOv6EglIA3EdE4/7ZT48mxUk8kL8ZTfMQ/vCz3eO9QPZFLPWNuaoT 3OZ2PjGfs4GsJi966Q6D09RkQgk1wR22vWdSrAX/n+FKWlWeroabtjiLGZd/c9L+56jk ws+uhxS5/ivM+LT3ZV9hW2EE5JpbmZcskBasTsWz97kKSiDCZMi51Hb4XwqY3B/82F3U XJaapzpx8rjLPszfi5zYjVSvRhz5qkexq4lTc/nF1JoOQ1OQgiqbs1VI7fM8gsXLYgEZ eKsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=QOgP6URk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p17si2441558edw.347.2021.02.10.16.35.03; Wed, 10 Feb 2021 16:35:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=QOgP6URk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230289AbhBKAZz (ORCPT + 99 others); Wed, 10 Feb 2021 19:25:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229756AbhBKAZy (ORCPT ); Wed, 10 Feb 2021 19:25:54 -0500 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B328CC061756 for ; Wed, 10 Feb 2021 16:25:13 -0800 (PST) Received: by mail-ej1-x631.google.com with SMTP id a9so7357793ejr.2 for ; Wed, 10 Feb 2021 16:25:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RHZyjDLOFDi0ZfkqD61Yg3tZtOTffsyWTFvMKMIBqsk=; b=QOgP6URktIoHtmzQTAYppRNvm6zFn6NxboC+4KZJpsB3pxuX3MEWF3Lnf9Q+WxwZ2N JjgvdfcoaNoZQrgwcZm/suJd93cwKcrNpKljF/PJf5KEUK6PBufCHbO6bg/6DwGSXAgj 7uvnK6KMd25eSy+ZgsF/OJu37jp0x/i87n0pH/yNUjCOsEc03FtXoS0DFE9L70cCXH8C Ba6zwx2H2cOc5pueHFyGrm7TPMmewIUZf+wdjJ7OJWWr4sgQZ99p5QCF5b5bYGh450uR qThsUJ5z58stqZ83AyDD5oHl8w+6AuqUEp5HlGniSR208pplcMWy0ouKOxN7rGwt3hrl mLQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RHZyjDLOFDi0ZfkqD61Yg3tZtOTffsyWTFvMKMIBqsk=; b=HCtaW405gPS+eBD2lC3mPnew5ZMyVpTO/mdzB/Ne2t75+vu4IVzfmmM0hy1jSYPWkM ByRvZHZfkezsJc9TB9cTcn4EELus1FbJqnwJT/tbXDNWTbe66ib5ZD93zbkka30lK3/E DOurYrHXZ2r3ZVtq5hdLM5I0AkAs3VKGUxYVzd0bCNV2BqzbIR/wSAhU8nZWqaXp10+T ErEFy1PeQFnAn1D7hI3qwaCUCMOfErt17G+v+vQlHWVmcVgx7UrSquwFmDBosgCf7kVX KvpLFaNq2f4oDC3PVD6ZMXjpWDh+D+zNI/jRuOFV+2PWSMeLZDjSFlv/k6dil4Mq4EsX jWvw== X-Gm-Message-State: AOAM530QD7kPYFnpqzLPDYlFAeELrDQ9bO55BoO7Bai3Yfrc8+Fll+9l FHyjkfGRq/xqqNgwPGCWchRg19ZV4Kec6beU6PdF X-Received: by 2002:a17:906:1199:: with SMTP id n25mr5455044eja.431.1613003112253; Wed, 10 Feb 2021 16:25:12 -0800 (PST) MIME-Version: 1.0 References: <20210129164926.3939-1-nramas@linux.microsoft.com> In-Reply-To: <20210129164926.3939-1-nramas@linux.microsoft.com> From: Paul Moore Date: Wed, 10 Feb 2021 19:25:00 -0500 Message-ID: Subject: Re: [PATCH v2] selinux: measure state and policy capabilities To: Lakshmi Ramasubramanian Cc: zohar@linux.ibm.com, Stephen Smalley , tusharsu@linux.microsoft.com, tyhicks@linux.microsoft.com, casey@schaufler-ca.com, agk@redhat.com, snitzer@redhat.com, gmazyland@gmail.com, sashal@kernel.org, James Morris , linux-integrity@vger.kernel.org, selinux@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 29, 2021 at 11:49 AM Lakshmi Ramasubramanian wrote: > > SELinux stores the configuration state and the policy capabilities > in kernel memory. Changes to this data at runtime would have an impact > on the security guarantees provided by SELinux. Measuring this data > through IMA subsystem provides a tamper-resistant way for > an attestation service to remotely validate it at runtime. > > Measure the configuration state and policy capabilities by calling > the IMA hook ima_measure_critical_data(). > > To enable SELinux data measurement, the following steps are required: > > 1, Add "ima_policy=critical_data" to the kernel command line arguments > to enable measuring SELinux data at boot time. > For example, > BOOT_IMAGE=/boot/vmlinuz-5.11.0-rc3+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux ima_policy=critical_data > > 2, Add the following rule to /etc/ima/ima-policy > measure func=CRITICAL_DATA label=selinux > > Sample measurement of SELinux state and policy capabilities: > > 10 2122...65d8 ima-buf sha256:13c2...1292 selinux-state 696e...303b > > Execute the following command to extract the measured data > from the IMA's runtime measurements list: > > grep "selinux-state" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6 | xxd -r -p > > The output should be a list of key-value pairs. For example, > initialized=1;enforcing=0;checkreqprot=1;network_peer_controls=1;open_perms=1;extended_socket_class=1;always_check_network=0;cgroup_seclabel=1;nnp_nosuid_transition=1;genfs_seclabel_symlinks=0; > > To verify the measurement is consistent with the current SELinux state > reported on the system, compare the integer values in the following > files with those set in the IMA measurement (using the following commands): > > - cat /sys/fs/selinux/enforce > - cat /sys/fs/selinux/checkreqprot > - cat /sys/fs/selinux/policy_capabilities/[capability_file] > > Note that the actual verification would be against an expected state > and done on a separate system (likely an attestation server) requiring > "initialized=1;enforcing=1;checkreqprot=0;" > for a secure state and then whatever policy capabilities are actually > set in the expected policy (which can be extracted from the policy > itself via seinfo, for example). > > Signed-off-by: Lakshmi Ramasubramanian > Suggested-by: Stephen Smalley > Suggested-by: Paul Moore > --- > security/selinux/ima.c | 77 ++++++++++++++++++++++++++++++++-- > security/selinux/include/ima.h | 6 +++ > security/selinux/selinuxfs.c | 6 +++ > security/selinux/ss/services.c | 2 +- > 4 files changed, 86 insertions(+), 5 deletions(-) > > diff --git a/security/selinux/ima.c b/security/selinux/ima.c > index 03715893ff97..5c7f73cd1117 100644 > --- a/security/selinux/ima.c > +++ b/security/selinux/ima.c > @@ -13,18 +13,73 @@ > #include "ima.h" > > /* > - * selinux_ima_measure_state - Measure hash of the SELinux policy > + * selinux_ima_collect_state - Read selinux configuration settings > * > - * @state: selinux state struct > + * @state: selinux_state > * > - * NOTE: This function must be called with policy_mutex held. > + * On success returns the configuration settings string. > + * On error, returns NULL. > */ > -void selinux_ima_measure_state(struct selinux_state *state) > +static char *selinux_ima_collect_state(struct selinux_state *state) > +{ > + const char *on = "=1;", *off = "=0;"; > + char *buf; > + int buf_len, i; > + > + /* > + * Size of the following string including the terminating NULL char > + * initialized=0;enforcing=0;checkreqprot=0; > + */ > + buf_len = 42; It might be safer over the long term, and self-documenting, to do the following instead: buf_len = strlen("initialized=0;enforcing=0;checkreqprot=0;") + 1; > + for (i = 0; i < __POLICYDB_CAPABILITY_MAX; i++) > + buf_len += strlen(selinux_policycap_names[i]) + 3; 's/3/strlen(on)/' or is that too much? > + > + buf = kzalloc(buf_len, GFP_KERNEL); > + if (!buf) > + return NULL; > + > + strscpy(buf, "initialized", buf_len); I wonder if it might be a good idea to add a WARN_ON() to the various copies, e.g.: rc = strXXX(...); WARN_ON(rc); The strscpy/strlcat protections should ensure that nothing terrible happens with respect to wandering off the end of the string, or failing to NUL terminate, but they won't catch a logic error where the string is not allocated correctly (resulting in a truncated buffer). > + strlcat(buf, selinux_initialized(state) ? on : off, buf_len); > + > + strlcat(buf, "enforcing", buf_len); > + strlcat(buf, enforcing_enabled(state) ? on : off, buf_len); > + > + strlcat(buf, "checkreqprot", buf_len); > + strlcat(buf, checkreqprot_get(state) ? on : off, buf_len); > + > + for (i = 0; i < __POLICYDB_CAPABILITY_MAX; i++) { > + strlcat(buf, selinux_policycap_names[i], buf_len); > + strlcat(buf, state->policycap[i] ? on : off, buf_len); > + } > + > + return buf; > +} -- paul moore www.paul-moore.com