On Wed, Aug 29, 2012 at 06:36:07PM +0200, Paolo Barile wrote:
> Aug 29 18:09:04 dell-studio kernel: [ 112.875933] type=1400
> audit(1346256544.115:57): avc: denied { read } for pid=3066
> comm="udev-acl.ck" name="udev-acl" dev="tmpfs" ino=3219
> scontext=system_u:system_r:consolekit_t
> tcontext=system_u:object_r:udev_var_run_t tclass=dir
This one is biting me a bit. Could you try labeling udev-acl.ck (wherever it
is) as udev_exec_t and see if that helps?
The udev-acl.ck code tries to iterate over devices, setting the proper
access controls. This is most likely what is causing your USB disks to not
show up (properly). However, I'm not very fond of allowing consolekit_t to
do this if this is a udev-task (and more specifically, udev-acl.c (the
source cde) uses a lot of udev related methods for this.
The alternative (if we don't run it as udev) is to allow all possible rights
on consolekit, but I think that'll be a lot more than reading the directory
(as this is just the first step).
> Aug 29 18:10:14 dell-studio kernel: [ 183.307019] type=1400
> audit(1346256614.546:69): avc: denied { getattr } for pid=3233
> comm="pm-is-supported" path="/dev/snapshot" dev="tmpfs" ino=3438
> scontext=system_u:system_r:devicekit_power_t
> tcontext=system_u:object_r:apm_bios_t tclass=chr_file
> Aug 29 18:10:14 dell-studio kernel: [ 183.318766] type=1400
> audit(1346256614.558:70): avc: denied { getattr } for pid=3252
> comm="pm-is-supported" path="/dev/snapshot" dev="tmpfs" ino=3438
> scontext=system_u:system_r:devicekit_power_t
> tcontext=system_u:object_r:apm_bios_t tclass=chr_file
> Aug 29 18:10:14 dell-studio kernel: [ 183.717762] type=1400
> audit(1346256614.957:71): avc: denied { getattr } for pid=3276
> comm="pm-powersave" path="/dev/snapshot" dev="tmpfs" ino=3438
> scontext=system_u:system_r:devicekit_power_t
> tcontext=system_u:object_r:apm_bios_t tclass=chr_file
> Aug 29 18:10:14 dell-studio kernel: [ 183.721637] type=1400
> audit(1346256614.961:72): avc: denied { write } for pid=3281
> comm="mkdir" name="/" dev="tmpfs" ino=1059
> scontext=system_u:system_r:devicekit_power_t
> tcontext=system_u:object_r:var_run_t tclass=dir
[...]
This one we need to work out further. I'm okay with allowing
devicekit_power_t to get the attributes of apm_bios_t, but for some reason I
don't think that'll be enough.
Care to add in something like:
#v+
policy_module(localdevicekit, 1.0)
gen_require(`
type devicekit_power_t;
')
dev_getattr_apm_bios_dev(devicekit_power_t)
#v-
and then see what happens next? If it wants to read or write to it, add in:
#v+
dev_rw_apm_bios(devicekit_power_t)
#v-
For the rest, I've put in quite a few changes in the policy for the other
denials shown earlier. They will definitely be in revision 5, but if you
know how to work with live ebuilds, you can use the SELinux live ebuilds as
well (since the changes are in the policy repository).
An overview of all changes:
http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-refpolicy.git;a=summary
Wkr,
Sven Vermeulen
