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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS 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 47BE9C43381 for ; Sun, 17 Mar 2019 20:28:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F310520872 for ; Sun, 17 Mar 2019 20:28:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ieee.org header.i=@ieee.org header.b="HDQmaeyt" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727453AbfCQU2H (ORCPT ); Sun, 17 Mar 2019 16:28:07 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:33604 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727452AbfCQU2H (ORCPT ); Sun, 17 Mar 2019 16:28:07 -0400 Received: by mail-qt1-f196.google.com with SMTP id k14so10021347qtb.0 for ; Sun, 17 Mar 2019 13:28:06 -0700 (PDT) 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=xOvNxWXKyCcnrxCRzyPA1tJKDSCZQI3pkuk5WOAk2eI=; b=HDQmaeytWxQoF6nW68gZ7lHfsRqTzTBWeCFcMVL2HDRua9FH4+6sKtbTNHP2OeOXDV ek1Y/vTuoXxFHuf6cKSbTR5LwhYqBY2xfc6z218F5ZFOIUTDCl7Up/ZQsHARInovb0ka 3FxpUk3UEtCTKd1R3fxggooPvutvmg1/rr9co= 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=xOvNxWXKyCcnrxCRzyPA1tJKDSCZQI3pkuk5WOAk2eI=; b=QL8hQXZHjg9dVfVmmq360fhmXpH+wVz5V4OByhNHM1UYmPShdKOLOcTjO9XFKHugfw 3tL4zMZOWiLE12fkOkVPaFb39ppyu/tev6un9tlc74VZQGamqefROg6sRjikp5Zj+Qle T6xds/RjTZAA8hxonOOyd0zdGxSaSQLOTRz6LGP+FjmjuGLuTuH7ncCHICxVA5dVqNbA plklNnDsGqVpBpJejt9EO9ELYx7JD66Abj+YdY8S0QaGWkTAbqpRT604uK1WropcFpLF Q9GtrSWMFWy3XtRqkAGUNecVq0gDVYRHOr92T41Sb1d95IZleC7fJfK/fxEo+pha1/+l uLcg== X-Gm-Message-State: APjAAAW0PqKiPCHk6NHYHaYidU2hQw7dkdMoOwXOnsANzK2URYpBKN7z aQfga46BWoiRJJW4HmL458mKjwefLsg= X-Google-Smtp-Source: APXvYqyHiOuAIWOMSS+tV/4rXz8dw8OeP5NVOqTIzUexxVfqthqGShBLzQTIXzKgvDUcyjaoVzYYZw== X-Received: by 2002:a0c:9acc:: with SMTP id k12mr10802142qvf.211.1552854485842; Sun, 17 Mar 2019 13:28:05 -0700 (PDT) Received: from [192.168.1.190] (pool-108-15-23-247.bltmmd.fios.verizon.net. [108.15.23.247]) by smtp.gmail.com with ESMTPSA id v2sm4624813qkc.41.2019.03.17.13.28.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Mar 2019 13:28:05 -0700 (PDT) Subject: Re: [PATCH v2] Setup attribute for fixed_disk_device and removable_device To: "Sugar, David" , "selinux-refpolicy@vger.kernel.org" References: <20190313181804.10224-1-dsugar@tresys.com> <20190313181804.10224-2-dsugar@tresys.com> <06720853-7f0a-7ed4-b180-7d6b6b4d4a3f@ieee.org> <36accfd4-7bc5-284e-5e9d-8684d1c51452@tresys.com> From: Chris PeBenito Message-ID: Date: Sun, 17 Mar 2019 16:14:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <36accfd4-7bc5-284e-5e9d-8684d1c51452@tresys.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: selinux-refpolicy-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org On 3/14/19 10:22 PM, Sugar, David wrote: > > > On 3/14/19 6:06 PM, Chris PeBenito wrote: >> On 3/13/19 2:18 PM, Sugar, David wrote: >>> I am having trouble with some denials due to the fact I am setting >>> up specific private types for media attached to my system.  This >>> changes to use an attribute for media and interfaces to add types >>> to the newly created attribute >> >> What you implemented doesn't seem consistent with what you have in the >> commit message.  sr0 is in your example denials, so these aren't all >> fixed disk devices, so the interface names and the attribute names >> should be related to all storage devices, it would seem. >> >> > > No, they are not all fixed disk denials. And maybe I should have split > this into 2 (or 3) patches. As I was making changes they all seemed > related from my use case, but from your point of view I can see why they > are probably different. And I may not be explaining what I'm trying to > accomplish clearly. > > Basically I have two (or three) cases: > 1) I want to provide distinct types for USB devices so that only certain > domains are able to mount/umount/format/etc... The attribute provides a > way to grant access to things like lvm_t and kernel_t which still need > to do stuff with the device nodes. The USB devices /dev/sd* by default > are labeled fixed_disk_device_t. > > 2) I want to provide distinct types for certain hard disk/LVM > partitions. This will provide a way to restrict access to certain > domains to alter those hard disk partitions (i.e. mount and umount and > cryptsetup (to change LUKS password)). At the same time this restricts > those domains that need this specific hard disk access to still not have > access to other partitions labeled fixed_disk_device_t. i.e. so if this > domain is compromised, it can only alter the single partition it has > access to, not others. > > 3) The last case maybe overkill (maybe not) where I am labeling /dev/sr0 > and /dev/sg1 with a separate type to better control access to write to > the generic scsi device node to only the process who is writing optical > media. Again this provides a way to restrict access to the other > /dev/sg* devices this process should not be accessing. /dev/sr0 is > removable_device_t by default but I also have some USB devices that > present as cdrom devices get /dev/sr1 as the device node and by default > are also labeled removable_device_t. > > I am able to use specific udev rules to correctly setup the SELinux > labels for these specific hard disk partitions, USB devices and optical > drive. > > I am also open to other recommendations for a better way to solve these > denials without giving domains that only need to access a single device > or partition access to all devices. These do not seem upstreamable. They sound very system-specific. -- Chris PeBenito