From: Joshua Brindle <jbrindle@snu.edu>
To: SELinux <SELinux@tycho.nsa.gov>
Subject: Re: audio-entropyd policy
Date: Sun, 11 Apr 2004 06:00:37 -0500 [thread overview]
Message-ID: <40792555.7020808@snu.edu> (raw)
In-Reply-To: <40791D2C.7010702@snu.edu>
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.
prev parent reply other threads:[~2004-04-11 11:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-10 23:29 audio-entropyd policy Joshua Brindle
[not found] ` <200404112013.10012.russell@coker.com.au>
[not found] ` <40791D2C.7010702@snu.edu>
2004-04-11 11:00 ` Joshua Brindle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40792555.7020808@snu.edu \
--to=jbrindle@snu.edu \
--cc=SELinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.