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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 7D416C35DF0 for ; Tue, 25 Feb 2020 00:27:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5051B218AC for ; Tue, 25 Feb 2020 00:27:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=coker.com.au header.i=@coker.com.au header.b="S9xCI8zS"; dkim=pass (1024-bit key) header.d=coker.com.au header.i=@coker.com.au header.b="sCsKQMDQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728578AbgBYA1a (ORCPT ); Mon, 24 Feb 2020 19:27:30 -0500 Received: from smtp.sws.net.au ([46.4.88.250]:34170 "EHLO smtp.sws.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728087AbgBYA1a (ORCPT ); Mon, 24 Feb 2020 19:27:30 -0500 Received: by smtp.sws.net.au (Postfix, from userid 116) id 1B71CEC82; Tue, 25 Feb 2020 11:27:28 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coker.com.au; s=2008; t=1582590449; bh=ApwbTZB/C11qX5HqFQ4IvPwNBqFziP4M+aftgsXr/Bs=; l=1836; h=From:To:Reply-To:Cc:Subject:Date:In-Reply-To:References:From; b=S9xCI8zSQ5x/VSSAX5AstPbr5j3OmE8JQNvpP6sGGYGlg+cTO6EM+VnebakGcoRCu uUExUojq2x/qNSpRJ6hNA3r4gvBmN3i+2eBECo8KDkTxAjueVLhkbhx7ArSWzSy7kO tlboGm2lO42qtN+G+Qfrxd3jh1Rv38u1JK9hUljc= Received: from xev.coker.com.au (localhost [127.0.0.1]) by smtp.sws.net.au (Postfix) with ESMTP id 682E0EC82; Tue, 25 Feb 2020 11:27:27 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coker.com.au; s=2008; t=1582590447; bh=ApwbTZB/C11qX5HqFQ4IvPwNBqFziP4M+aftgsXr/Bs=; l=1836; h=From:To:Reply-To:Cc:Subject:Date:In-Reply-To:References:From; b=sCsKQMDQtb4DLfimk46vEoyky0Bsbt4jslcAGUDgdPygHsS9UUdVx8hLCfGiU2H1x 9/vH0hTQa9+22MTtmNEYDVJ0lrvys+ASfF6lkPT+tXbg2bJZkL+i6JYmTSon/eFfaW rcdtfBVcJVKE6c27BN35I79OJg0BpcYQOf7i6Xok= Received: by xev.coker.com.au (Postfix, from userid 1001) id 011C6F37865; Tue, 25 Feb 2020 11:27:22 +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 11:27:22 +1100 Message-ID: <2012273.jey3ENlaR0@xev> In-Reply-To: <710a52cc-5b72-e833-9ac6-4289b1bc0b61@gmail.com> References: <11011d01-844e-c526-a85f-92a7fc985d16@gmail.com> <2111138.8pYWFqxgyc@xev> <710a52cc-5b72-e833-9ac6-4289b1bc0b61@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:56:01 AM AEDT Topi Miettinen wrote: > The PR would make all these conditional to new boolean, > allow_raw_memory_access. So if someone needs one of those many accesses (klogd_t or hald_t seems likely) then they also get access for things that aren't needed on most systems nowadays (EG xserver_t) and things that never made any sense (such as colord_t). I think it would be best to remove most of those /dev/mem access rules and add them back only after testing with recent software and comments about why they are needed. > > 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. I think it was needed before KMS. Is it even possible to run without KMS nowadays? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/