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=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 113F4C11D2F for ; Mon, 24 Feb 2020 15:56:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C493120828 for ; Mon, 24 Feb 2020 15:56:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rzIbe+a2" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727921AbgBXP4R (ORCPT ); Mon, 24 Feb 2020 10:56:17 -0500 Received: from mail-lj1-f195.google.com ([209.85.208.195]:45648 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727359AbgBXP4R (ORCPT ); Mon, 24 Feb 2020 10:56:17 -0500 Received: by mail-lj1-f195.google.com with SMTP id e18so10641761ljn.12 for ; Mon, 24 Feb 2020 07:56:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mauO+FqQxaXeszb+znqhyDeBTbv9RNt4rM4xiov/nnI=; b=rzIbe+a2YzmB22mmiiBGt7cJA3CyxNgBy1mBIoxthKpVW+49fuvEtE7mON+hmS1ztt TIiazNGTh05uH7a+9b8euzeoZcs1D5NqNGXFILkvV5VkacGDlRbU/Ye/IV389fLVq1hc mO17pyKb4dKDsSqMPjAIWJcWyImHRy0Vq0ONU57I8lIqmpdITbRMpmSLOyUo8QJzIaoo fG+13LyqRJnCSve2bmcHRV/N3SV52drw0/OD7fp/HxBRCgE1Vcgb1s0iXaaMKaGtmd9B j9uClfN70YyYSGMNoIXayvhtcm1MS7fniAw9i6tvI1qzaSf3L0tlJkbotJTkijdhyVWW JrsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mauO+FqQxaXeszb+znqhyDeBTbv9RNt4rM4xiov/nnI=; b=fEhoEq+VFm/PD2YEW9hiWK0dqaOfYgFcl7iT4IRp2PzZ5vxv1BscnjV2VM2+sYdhlK YlZfoZ/knRRaBiWK9WBRIDfsZGU+Xu8gFOZRn0w2pOt8DldabZQMteTqmhJ9UZI3vXqV 2t+eRhavIj1uIqDvr0n35WoTpO+2K2Ktnfioh0XbSmQc9QHK6q7eWg0YFLN8QoTr4Yky F3UvCAFVStwF/0J2mI+Dz+nZXJMC3SYquhdW7nzmsZvz9cB2gWqoSrGGYD2j7QkeCcEd z3NkUatlMYIdPJICrlgdY2mt3+7gnzSqRByEGKOD2YaMAfnCvnZS0I5WmrVmJWyf7UT/ 1INg== X-Gm-Message-State: APjAAAVF8GgmjMfH5a2VyOXTYhV2yOpiqrfn2wteZVXJ9BWTOTKc+6aY kRvz9O0mWBPlAaeYxnzzIm6AjwWd X-Google-Smtp-Source: APXvYqzLN0paoSMo1EwYYnuAW/IbTbdD0n0tDXBvwlYlbbYlOlmvIPQVMKxsj8TXRzRe1otWxK7bFg== X-Received: by 2002:a2e:87ca:: with SMTP id v10mr5705367ljj.253.1582559774731; Mon, 24 Feb 2020 07:56:14 -0800 (PST) Received: from [192.168.1.38] (88-114-211-119.elisa-laajakaista.fi. [88.114.211.119]) by smtp.gmail.com with ESMTPSA id i1sm6410877lji.71.2020.02.24.07.56.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Feb 2020 07:56:14 -0800 (PST) Subject: Re: Access to raw memory: remove or make boolean? To: russell@coker.com.au Cc: selinux-refpolicy@vger.kernel.org References: <11011d01-844e-c526-a85f-92a7fc985d16@gmail.com> <2111138.8pYWFqxgyc@xev> From: Topi Miettinen Message-ID: <710a52cc-5b72-e833-9ac6-4289b1bc0b61@gmail.com> Date: Mon, 24 Feb 2020 17:56:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <2111138.8pYWFqxgyc@xev> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: selinux-refpolicy-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org On 24.2.2020 17.42, Russell Coker wrote: > 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) The PR would make all these conditional to new boolean, allow_raw_memory_access. > 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. I also don't know most of these programs. Direct memory access was probably needed for X server during SVGA times, at least NVIDIA driver on my system does not seem to need it. -Topi