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?