audio-entropyd policy

audio-entropyd policy

[Joshua Brindle]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

audio-entropyd available at http://www.vanheusden.com/aed/ adds entropy 
from sound devices (after being cleansed and hashed). This is 
particularly useful on headless servers which don't get any 
mouse/keyboard related entropy. The policy was written by Chris Pebenito.

Joshua Brindle

[-- Attachment #2: audio-entropyd.te --]
[-- Type: text/plain, Size: 347 bytes --]

#DESC audio-entropyd - Generate entropy from audio input
#
# Author: Chris PeBenito <pebenito@gentoo.org>
#

daemon_domain(entropyd)

allow entropyd_t self:capability { ipc_lock sys_admin };

allow entropyd_t random_device_t:chr_file rw_file_perms;
allow entropyd_t device_t:dir r_dir_perms;
allow entropyd_t sound_device_t:chr_file r_file_perms;

[-- Attachment #3: audio-entropyd.fc --]
[-- Type: text/plain, Size: 62 bytes --]

/usr/sbin/audio-entropyd	--	system_u:object_r:entropyd_exec_t

Re: audio-entropyd policy

[Joshua Brindle]

oops, i forgot to include the list in this

Joshua Brindle wrote:
> Russell Coker wrote:
> 
>> On Sun, 11 Apr 2004 09:29, Joshua Brindle <jbrindle@snu.edu> wrote:
>>  
>>
>>> audio-entropyd available at http://www.vanheusden.com/aed/ adds entropy
>>> from sound devices (after being cleansed and hashed). This is
>>> particularly useful on headless servers which don't get any
>>> mouse/keyboard related entropy. The policy was written by Chris 
>>> Pebenito.
>>>   
>>
>>
>> Why is ipc_lock needed?  The random driver is designed such that 
>> knowing all data which is written to it does not permit predicting the 
>> output, and also if an attacker can access swap space then they can 
>> probably do worse attacks than attempting to predict the next random 
>> number.
>>
>> It seems to me that ipc_lock gives no benefit and just permits 
>> marginally reducing the amount of pagable memory.
>>
>> It's really a pity that sys_admin is needed for writing to the random 
>> device, that capability grants so much extra...
>>
>> I've added the policy to my tree, although I expect that any active 
>> server will be getting hard disk and network interrupts to generate 
>> some entropy.
>>
>>  
>>
> I'm not sure about the ipc_lock, pebenito will have to answer that one, 
> but on the subject of entropy the reason I investigated and started 
> using this is because ssp (formerly known as propolice) gets 32 bytes of 
> entropy per exec during guard_setup to make canaries. This is obviously 
> a huge drain on entropy. Network inturrupts only contribute to entropy 
> on a few drivers, the majority of them don't (unless you patch in the 
> netrand patches), disk access would contribute but not all servers have 
> major disk access (web servers where the majority of the content is 
> cached and/or on a remote database server for example). I found that 
> many of my machines had no entropy available most of the time wheras 
> with this I can set the poolsize to 8192 and consistantly have over 
> 50000 bits of entropy available (with good audio input).
> 
> Joshua Brindle
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.