Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp2575861ybv; Mon, 24 Feb 2020 07:43:15 -0800 (PST) X-Google-Smtp-Source: APXvYqwjI7aIgqbvSpO2xfpAFMQnWo8nQ5rSYnR75Oz0vGxOY63q8PDhLoOGjvwWJj0nVAOiMYrq X-Received: by 2002:aca:dd05:: with SMTP id u5mr12965472oig.91.1582558995402; Mon, 24 Feb 2020 07:43:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582558995; cv=none; d=google.com; s=arc-20160816; b=Ri1hp0mca/oq8js5CVBP1+rY5i5YAcHiwlCzhaxD8R4n6PaZDWmqZqzWP6tqliVVfe u2QtEMDZda+KUvbLSJNVYtvStLSH9IXiFWACPGqlCSUr52ODsnMbBvr9JzxLzJmUzBaz t/WY1oqFpOPhzD3ZFWE1nCK2UEBgAQENZVPxLZpOznkppAsrFauJkohajyY4sS2hjhfo 9+8J/nhPDxbOuwY2zTY7bySiII3fhMKqiWy/1UZbuAiMjJEHqMexq0j6sri2uy/z7RLC PuCpVZV2U3kAPlDreISthmbUvC1H5SM3SQh5tyZcHakrVblfU5nDUZMVPfAAFkjy42yC 8hCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:reply-to:to:from :dkim-signature:dkim-signature; bh=Fw801uHHnwOGsS5Z0DRmlLoGTUxUb9ktRnfv93xr+7U=; b=Ryheu19C6o3g3RorcyOKBDy2alctlet4bp4sYG/H9S+7QdH4ZMlwbl+5bcpb9j6X3d lQn2prKfgEfasiWfkMaLVXcUv+5pRfnGBBqFlZ8yVK2JWK2wPGryz6DjW9MfpISYwzeX 0c9wGsd19bPF2fotTCYj1GIOUqguk1a3L35SrYTSbDbUl+wn0ubJydHxUOjlZDKleYs2 zJQuKitVrM9BamF4iq7VyqOA7iuwKSRHu03EYHQj7FiSowbg8JZLgJpvFVaPrepxPF43 wLKoS677F++wbZlWioHZTfm2deof2z05Ty2OBYVZly474LcWznUhvMFFGu0c9FOZfJPZ 9BGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@coker.com.au header.s=2008 header.b=cJ2VmZEq; dkim=pass header.i=@coker.com.au header.s=2008 header.b=XzpSZ1Y9; spf=pass (google.com: best guess record for domain of selinux-refpolicy-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=selinux-refpolicy-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=coker.com.au Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k1si5487959oic.245.2020.02.24.07.43.12; Mon, 24 Feb 2020 07:43:15 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of selinux-refpolicy-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@coker.com.au header.s=2008 header.b=cJ2VmZEq; dkim=pass header.i=@coker.com.au header.s=2008 header.b=XzpSZ1Y9; spf=pass (google.com: best guess record for domain of selinux-refpolicy-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=selinux-refpolicy-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=coker.com.au Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727719AbgBXPnL (ORCPT + 14 others); Mon, 24 Feb 2020 10:43:11 -0500 Received: from smtp.sws.net.au ([46.4.88.250]:51240 "EHLO smtp.sws.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727693AbgBXPnL (ORCPT ); Mon, 24 Feb 2020 10:43:11 -0500 Received: by smtp.sws.net.au (Postfix, from userid 116) id AD6D0F0AB; Tue, 25 Feb 2020 02:43:09 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coker.com.au; s=2008; t=1582558989; bh=Fw801uHHnwOGsS5Z0DRmlLoGTUxUb9ktRnfv93xr+7U=; l=3068; h=From:To:Reply-To:Cc:Subject:Date:In-Reply-To:References:From; b=cJ2VmZEq9r6TMCJEE1US1lWy9AJq+zrGj4y21RFo2i3xOkAG0Wtq92fIyrJMAffJ0 1Ldtl1E81w5JGjspeUebsOwE93CvMBsoFW6D5RjC4rN3adxfUvXbT4zJWs0PK5LiHN G/Ms5AHADMJloLpSp3z/vTFfosf3o30FWNrWjSds= X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on swssmtp X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-101.1 required=5.0 tests=ALL_TRUSTED=-1, DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1, USER_IN_WHITELIST=-100 autolearn=disabled version=3.4.2 X-Spam-Languages: en Received: from xev.coker.com.au (localhost [127.0.0.1]) by smtp.sws.net.au (Postfix) with ESMTP id 5B4EDF0AB; Tue, 25 Feb 2020 02:43:04 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coker.com.au; s=2008; t=1582558984; bh=Fw801uHHnwOGsS5Z0DRmlLoGTUxUb9ktRnfv93xr+7U=; l=3068; h=From:To:Reply-To:Cc:Subject:Date:In-Reply-To:References:From; b=XzpSZ1Y9OZK6duMu7O2wrlxsT2o2/xsr1ATv/wkq1KFc97lIShw1Z9vMXI0yTKy08 a48lSDaCPig4KGyKk7FohHZyfbW3WRp590dFcswqXj2hMRLfJ4EC1yOVvRNstr+SHL 0bHLlMOrKfD7YleTvL5Gx0cP/TdJ+6i5vsk2TtkY= Received: by xev.coker.com.au (Postfix, from userid 1001) id 9F5BCF3718F; Tue, 25 Feb 2020 02:42:58 +1100 (AEDT) From: Russell Coker To: Topi Miettinen Reply-To: russell@coker.com.au Cc: selinux-refpolicy@vger.kernel.org Subject: Re: Access to raw memory: remove or make boolean? Date: Tue, 25 Feb 2020 02:42:58 +1100 Message-ID: <2111138.8pYWFqxgyc@xev> In-Reply-To: <11011d01-844e-c526-a85f-92a7fc985d16@gmail.com> References: <11011d01-844e-c526-a85f-92a7fc985d16@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: selinux-refpolicy-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org On Tuesday, 25 February 2020 2:11:46 AM AEDT Topi Miettinen wrote: > Hi, > > I made a PR 192 (https://github.com/SELinuxProject/refpolicy/pull/192) > for introducing a new boolean to disable access to raw memory devices > (/dev/mem, /dev/kmem, /dev/mergemem, dev/oldmem, /dev/port) because on > modern systems, direct access shouldn't be needed anymore. Chris > PeBenito asked to propose to this list whether instead of boolean, the > access should be removed unconditionally if it's no longer needed. I > think boolean could be useful for those systems where this is still > needed but still use latest reference policy. https://lwn.net/Articles/147901/ A quick search turned up the above article from 2005 debating whether /dev/ kmem was of any use then. ./admin/ddcprobe.te:dev_read_raw_memory(ddcprobe_t) ./admin/ddcprobe.te:dev_wx_raw_memory(ddcprobe_t) ./admin/dmidecode.te:dev_read_raw_memory(dmidecode_t) ./admin/kudzu.te:dev_rx_raw_memory(kudzu_t) ./admin/kudzu.te:dev_wx_raw_memory(kudzu_t) ./admin/mcelog.te:dev_read_raw_memory(mcelog_t) ./admin/rpm.te:dev_read_raw_memory(rpm_t) ./admin/sosreport.te:dev_read_raw_memory(sosreport_t) ./admin/tboot.te:dev_read_raw_memory(txtstat_t) ./admin/vbetool.te:dev_wx_raw_memory(vbetool_t) ./admin/vbetool.te:dev_read_raw_memory(vbetool_t) ./apps/vmware.te:dev_read_raw_memory(vmware_t) ./apps/vmware.te:dev_write_raw_memory(vmware_t) ./services/hal.te:dev_read_raw_memory(hald_t) ./services/hal.te:dev_read_raw_memory(hald_mac_t) ./services/hal.te:dev_write_raw_memory(hald_mac_t) ./services/devicekit.te: dev_read_raw_memory(devicekit_disk_t) ./services/colord.te:dev_read_raw_memory(colord_t) ./services/colord.te:dev_write_raw_memory(colord_t) ./services/xserver.te:dev_read_raw_memory(xserver_t) ./services/xserver.te:dev_wx_raw_memory(xserver_t) ./system/iscsi.te:dev_read_raw_memory(iscsid_t) ./system/iscsi.te:dev_write_raw_memory(iscsid_t) ./system/raid.te:dev_read_raw_memory(mdadm_t) ./system/init.te: dev_rx_raw_memory(initrc_t) ./system/init.te: dev_wx_raw_memory(initrc_t) ./system/logging.te:dev_read_raw_memory(klogd_t) A quick grep of the latest policy turned up the above access to /dev/mem. Do ddcprobe_t, vbetool_t, and the X server still do that? mcelog_t, and klogd_t might have good uses, as might sosreport_t (don't even know what it does but guessing it's like klogd_t). rpm_t should maybe transition to a different domain for whatever it was doing and the same for kudzo_t. Vmware is a bit ugly, so vmware_t might actually do that. iscsi_t, mdadm_t, colord_t, and initrc_t should never have needed that. hald_t, hald_mac_t and devicekit_disk_t might have needed it, but hopefully that was fixed a long time ago. Interestingly bootloader_t doesn't have such access even though a quick inspection of the LILO source code shows that it still probes the boot order by directly reading the BIOS memory. I guess no-one uses LILO with SE Linux. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/