[refpolicy] [PATCH 1/2]: cpucontrol module updates (stricter policy for CPU microcode updates)
Christopher J. PeBenito
cpebenito at tresys.com
Mon Sep 17 08:28:56 CDT 2012
On 09/08/12 06:27, Guido Trentalancia wrote:
> 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
> 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)
>>> @@ -54,6 +64,10 @@ logging_send_syslog_msg(cpucontrol_t)
>>> + 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.
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
More information about the refpolicy