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?
Attachment:
signature.asc
Description: This is a digitally signed message part
