9:02 p.m.
Trying to generate a new gpg key fails with the latest policy updates.
Below is the avc:
audit(1082512578.827:0): avc: denied { read } for pid=2543
exe=/usr/bin/gpg name=random dev=hda5 ino=267501
scontext=user_u:user_r:user_gpg_t
tcontext=system_u:object_r:random_device_t tclass=chr_file
[jwboyer@localhost jwboyer]$ rpm -q policy
policy-1.11.2-9
Any tips?
thx,
josh
9:36 p.m.
On Tue, 2004-04-20 at 22:02, Josh Boyer wrote:
Trying to generate a new gpg key fails with the latest policy
updates.
Below is the avc:
audit(1082512578.827:0): avc: denied { read } for pid=2543
exe=/usr/bin/gpg name=random dev=hda5 ino=267501
scontext=user_u:user_r:user_gpg_t
tcontext=system_u:object_r:random_device_t tclass=chr_file
[jwboyer@localhost jwboyer]$ rpm -q policy
policy-1.11.2-9
Try this patch, will be in the next policy.
9:49 p.m.
On Tue, 2004-04-20 at 22:36, Colin Walters wrote:
On Tue, 2004-04-20 at 22:02, Josh Boyer wrote:
> Trying to generate a new gpg key fails with the latest policy updates.
> Below is the avc:
>
> audit(1082512578.827:0): avc: denied { read } for pid=2543
> exe=/usr/bin/gpg name=random dev=hda5 ino=267501
> scontext=user_u:user_r:user_gpg_t
> tcontext=system_u:object_r:random_device_t tclass=chr_file
>
> [jwboyer@localhost jwboyer]$ rpm -q policy
> policy-1.11.2-9
Try this patch, will be in the next policy.
I presume by the way there's a reason access to random_device_t is was
originally denied - it prevents users from draining your good entropy by
generating a ton of keys. On the other hand, if you have GPG installed
on a system, I think most system administrators are going to expect
users to be able to generate keys securely.
Maybe the right way is a resource constraint framework. Anyways, do
people think this is worth being made into a tunable or something?
3:40 a.m.
On Wed, 21 Apr 2004 12:49, Colin Walters <walters(a)redhat.com> wrote:
I presume by the way there's a reason access to random_device_t
is was
originally denied - it prevents users from draining your good entropy by
generating a ton of keys. On the other hand, if you have GPG installed
Actually when I gave different types to /dev/random and /dev/urandom we just
sorted out which access each program seemed to need. At the time GPG didn't
seem to want /dev/random access. If it wants it then it should get it.
Maybe the right way is a resource constraint framework. Anyways, do
people think this is worth being made into a tunable or something?
I think that a resource constraint framework for entropy would be useful.
However there are other ways of attacking the problem.
It seems that every desktop, laptop, and PDA shipped in the last few years has
sound hardware. The microphone that's built in to many machines can be used
as a source of entropy, and even an unconnected line-in if sampled at 16bit
will do reasonably well. There is already policy
for /usr/sbin/audio-entropyd to use this, if we get this packaged then maybe
it would be the best solution to the problem?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
8:29 a.m.
On Wed, 2004-04-21 at 04:40, Russell Coker wrote:
On Wed, 21 Apr 2004 12:49, Colin Walters <walters(a)redhat.com>
wrote:
> I presume by the way there's a reason access to random_device_t is was
> originally denied - it prevents users from draining your good entropy by
> generating a ton of keys. On the other hand, if you have GPG installed
Actually when I gave different types to /dev/random and /dev/urandom we just
sorted out which access each program seemed to need. At the time GPG didn't
seem to want /dev/random access. If it wants it then it should get it.
I think it only uses /dev/random when generating keys.
It seems that every desktop, laptop, and PDA shipped in the last few
years has
sound hardware. The microphone that's built in to many machines can be used
as a source of entropy, and even an unconnected line-in if sampled at 16bit
will do reasonably well. There is already policy
for /usr/sbin/audio-entropyd to use this, if we get this packaged then maybe
it would be the best solution to the problem?
That does sound like a cool idea. You can really get data even if
there's no microphone connected?
9:40 a.m.
On Wed, 21 Apr 2004 09:29:47 EDT, Colin Walters <walters(a)redhat.com> said:
That does sound like a cool idea. You can really get data even if
there's no microphone connected?
I think the basic concept there is that even without a microphone, as you
sample, most cards won't return a steady stream of exact zeros - you'll get
back the tiniest bit of background hiss, and the low-order bits have entropy.
Of course, doing this without filtering is a Bad Idea - the amount of entropy
coming off the always-on cheap sound card in my laptop that has maybe 70db S/N
is probably a lot higher than somebody who has a high-end card that has 85db
S/N - and if their card supports auto-muting for unused inputs, you're basically
screwed...
12:37 a.m.
On Thu, 22 Apr 2004 00:40, Valdis.Kletnieks(a)vt.edu wrote:
I think the basic concept there is that even without a microphone, as
you
sample, most cards won't return a steady stream of exact zeros - you'll get
back the tiniest bit of background hiss, and the low-order bits have
entropy.
Of course, doing this without filtering is a Bad Idea - the amount of
entropy coming off the always-on cheap sound card in my laptop that has
maybe 70db S/N is probably a lot higher than somebody who has a high-end
card that has 85db S/N - and if their card supports auto-muting for unused
inputs, you're basically screwed...
Detecting an auto-mute input should be quite easy, just read for a second or
two and see if there is any change in the signal. Also writing non-random
data to /dev/random is supposed to not cause any problems.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
7302
days inactive
7303
days old
selinux@lists.fedoraproject.org
7 comments
4 participants
participants (4)
-
Colin Walters -
Josh Boyer -
Russell Coker -
Valdis.Kletnieks＠vt.edu