From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6732C4361B for ; Mon, 14 Dec 2020 15:14:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A44CC22A99 for ; Mon, 14 Dec 2020 15:14:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725871AbgLNPOR (ORCPT ); Mon, 14 Dec 2020 10:14:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726618AbgLNPOI (ORCPT ); Mon, 14 Dec 2020 10:14:08 -0500 Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 99B7CC0613D3 for ; Mon, 14 Dec 2020 07:13:28 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id h4so10949548qkk.4 for ; Mon, 14 Dec 2020 07:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=fQ0ygsow+fa4VCL6Aj5VzpOJ/pkb2JK+JGAKVZz2e+E=; b=O5DmWmzyk4+Ej4tG5t/G7e4vioOqciNZiqyTJIXhNeiA4mGMnI2xDNyU7BF/juBWh1 RQGg0Ma02s54CVYbTvIUwzVOBFUfMwvh5mwIT6n4Gll3TMOkxJck9Ueqo+zEcoYwN7EZ 5whCKAw8d26n+xydB8y1LkBS9ihz40Y7OevHA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fQ0ygsow+fa4VCL6Aj5VzpOJ/pkb2JK+JGAKVZz2e+E=; b=N3qp/0v9mlixEfyp2B3QInimgUyZP7PYuVxxghy86njoUsXRzHialHDqZmfiZc0KHR 2+RC7d3c9gpvRt4xhc6IxawhXT/E+4FB2s7Nzfz6FUiEImMWfC1YfoLfkIgJUYGX+dIc HZe5P1zF73XfxMpK4+3kKuADGqNe84XNW57OJOydAkEX9EeClJT7o7gh7C8JqoZxMrzo aMtyPf1wNLep5jnuqjkzx950r/wdSTH3Gb93mSYL5jHAGNf2UFOMFWfeTRx2w4Lt2eI+ EgAAHJK3KVGmSbg3i5ZK2YrQUyE0M+EvtxPUGsgNbsPyv8NCqBD6e7wTHq0xPNyjrLfP sv1g== X-Gm-Message-State: AOAM5335+Mp1VtVQBZuuJbKE3Dk6JisZw0W95rnXonul23zu8PlGRO0l OV7jifYGBSChWEAomOEDwNDT/G6nUmwHNA== X-Google-Smtp-Source: ABdhPJz7bgbvFtvhcvI8aGbbmxl1Zo44CdlsV12dol1ilY82cEn3jSddSaBTmoRNznAmtlLSRNj1TQ== X-Received: by 2002:a37:60f:: with SMTP id 15mr31017068qkg.211.1607958807553; Mon, 14 Dec 2020 07:13:27 -0800 (PST) Received: from fedora.pebenito.net (pool-96-234-173-17.bltmmd.fios.verizon.net. [96.234.173.17]) by smtp.gmail.com with ESMTPSA id e10sm13946642qte.48.2020.12.14.07.13.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Dec 2020 07:13:27 -0800 (PST) Subject: Re: lockdown class To: Russell Coker , selinux-refpolicy@vger.kernel.org References: <2911391.mirxchbQ87@liv> From: Chris PeBenito Message-ID: <4f69f374-3a67-55a2-3704-5cafd3719bf0@ieee.org> Date: Mon, 14 Dec 2020 10:13:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <2911391.mirxchbQ87@liv> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org On 12/11/20 2:01 AM, Russell Coker wrote: > allow systemd_modules_load_t systemd_modules_load_t:lockdown integrity; > allow udev_t udev_t:lockdown confidentiality; > > I've seen access that caused the above to be generated from audit2allow. > > /var/log/audit/audit.log.1:type=AVC msg=audit(1607515838.132:56): avc: denied > { confidentiality } for pid=253 comm="systemd-udevd" lockdown_reason="use of > tracefs" scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tclass=lockdown permissive=1 > > Above is the only log entry I've got for that from my previous testing (I > haven't been able to reproduce whatever it was that caused the > systemd_modules_load_t to get that audited). > > https://www.paul-moore.com/blog/d/2020/03/linux_v56.html > > I've read the above blog post and I'm still not sure exactly how we are to use > it. Do I allow this for systemd_modules_load_t because loading modules is an > integrity issue? Do I allow it for udev_t because changing device names etc > allows universal MITM attacks? The SELinux check mirrors the lockdown LSM checks but the policy's granularity, instead of the single granularity (system-wide)that lockdown LSM has. If you had the lockdown LSM running too and set to the integrity level, the systemd_modules_load_t would have been denied by lockdown instead of getting to SELinux's check. The udev access to tracefs in would be allowed by the lockdown LSM and go to SELinux's check. Effectively you could reimplement the lockdown LSM in SELinux like this: bool lockdown_integrity false; bool lockdown_confidentiality false; if (!lockdown_integrity && !lockdown_confidentiality) { allow domain self:lockdown integrity; } if (!lockdown_confidentiality) { allow domain self:lockdown confidentiality; } -- Chris PeBenito