From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Mon, 17 Sep 2012 09:28:56 -0400
Subject: [refpolicy] [PATCH 1/2]: cpucontrol module updates (stricter
 policy for CPU microcode updates)
In-Reply-To: <504B1DA9.9010601@trentalancia.com>
References: <5037897A.5050305@trentalancia.com> <503E136A.5070102@tresys.com>
	<504B1DA9.9010601@trentalancia.com>
Message-ID: <50572598.3020407@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 09/08/12 06:27, Guido Trentalancia wrote:
> Hello.
> 
> Here is a revised version (1/1) of the patch for the cpucontrol module.
> 
> On 29/08/2012 15:04, Christopher J. PeBenito wrote:
>> On 08/24/12 10:02, Guido Trentalancia wrote:
>>> cpucontrol module updates:
>>> - introduce the file contexts according to the standard location
>>>     of the most common application named microcode_ctl
>>>     (http://www.urbanmyth.org/microcode);
> 
> Dropped as risky. Can be tackled at a later time or by 
> users/distributions individually.
> 
>>> - add file contexts for CPUs from two different vendors, taking
>>>     into consideration specific customization of the location
>>>     for one distribution;
> 
> Not taking anymore into consideration binary location customizations as 
> too risky. Only adding generic support for the most likely location of 
> the application provided by the other manufacturer.
> 
>>> - add file contexts and declarations for the init script;
>>> - introduce the ability to update the CPU microcode as
>>>     tunable policy, as apparently such operation might
>>>     modify the original licensing conditions (under some or
>>>     all circumstances: "personal, non-commercial use only");
>>> - create a new device type specifically for the CPU microcode
>>>     updating functionality and modify the cpucontrol module so
>>>     that such distinct new type is used for the microcode
>>>     updating operation, thus leaving an open door for further
>>>     modifications that distinguish different CPU-related
>>>     applications/utilities to create further isolation;
>>> - modify the interface definitions so that the CPU microcode
>>>     update utility can only write and not read (unneeded) the
>>>     corresponding above mentioned device type.

Before I can commit this, I need an answer for this previous question:

>>> @@ -37,7 +48,6 @@ kernel_read_proc_symlinks(cpucontrol_t)
>>>    kernel_read_kernel_sysctls(cpucontrol_t)
>>>
>>>    dev_read_sysfs(cpucontrol_t)
>>> -dev_rw_cpu_microcode(cpucontrol_t)
>>>
>>>    fs_search_auto_mountpoints(cpucontrol_t)
>>>
>>> @@ -54,6 +64,10 @@ logging_send_syslog_msg(cpucontrol_t)
>>>
>>>    userdom_dontaudit_use_unpriv_user_fds(cpucontrol_t)
>>>
>>> +tunable_policy(`cpucontrol_can_upload_cpu_microcode',`
>>> +	dev_write_cpu_microcode(cpucontrol_t)
>>> +')
>>
>> I don't understand why this is conditional, especially since you removed the read permission on /dev/microcode.  The point of the app is to load microcode.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com