On 29/08/2012 20:49, Sven Vermeulen wrote:
> Is the context corrected later in the boot process (in other words, if you
> check the label now with "ls -dZ /dev/shm" is it tmpfs_t now?)
Well in fact /dev/shm was mislabeled even if I don't use initramfs, so I
added the following to fstab:
shm /dev/shm tmpfs
rw,rootcontext=system_u:object_r:tmpfs_t,seclabel,nosuid,nodev,noexec,relatime
0 0
So now (after reboot) it is labeled: system_u:object_r:tmpfs_t /dev/shm.
Anyway alsactl (and kmix) still doesn't work. It is (I think) because
there's something strange in denials:
Aug 30 19:52:15 dell-studio kernel: [ 8.562950] type=1400
audit(1346356301.561:3): avc: denied { getattr } for pid=1461
comm="alsactl" name="/" dev="tmpfs" ino=1232
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:tmpfs_t
tclass=filesystem
Aug 30 19:52:15 dell-studio kernel: [ 8.562975] type=1400
audit(1346356301.561:5): avc: denied { write } for pid=1461
comm="alsactl" name="shm" dev="tmpfs" ino=1236
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:device_t
tclass=dir
Aug 30 19:52:15 dell-studio kernel: [ 8.562984] type=1400
audit(1346356301.561:6): avc: denied { add_name } for pid=1461
comm="alsactl" name="pulse-shm-3830975079"
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:device_t
tclass=dir
Aug 30 19:52:15 dell-studio kernel: [ 8.563014] type=1400
audit(1346356301.561:7): avc: denied { create } for pid=1461
comm="alsactl" name="pulse-shm-3830975079"
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:device_t
tclass=file
Aug 30 19:52:15 dell-studio kernel: [ 8.563027] type=1400
audit(1346356301.562:8): avc: denied { read write open } for pid=1461
comm="alsactl" name="pulse-shm-3830975079" dev="tmpfs" ino=4239
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:device_t
tclass=file
Aug 30 19:52:15 dell-studio kernel: [ 8.608145] type=1400
audit(1346356301.607:9): avc: denied { remove_name } for pid=1461
comm="alsactl" name="pulse-shm-3830975079" dev="tmpfs" ino=4239
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:device_t
tclass=dir
Aug 30 19:52:15 dell-studio kernel: [ 8.608154] type=1400
audit(1346356301.607:10): avc: denied { unlink } for pid=1461
comm="alsactl" name="pulse-shm-3830975079" dev="tmpfs" ino=4239
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:device_t
tclass=file
As you can see even if the first denial reports shm labeled as tmpfs_t
all the other report it as device_it. How can it be possible?
> 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).
The file is /usr/lib64/ConsoleKit/run-seat.d/udev-acl.ck, it is a
symlink to /usr/libexec/udev-acl that is labeled bin_t.
Anyway I relabeled udev-acl.ck as udev_exec_t, so that denial
disappeard, but now I have this new one:
Aug 30 19:31:06 dell-studio kernel: [ 75.419082] type=1400
audit(1346347866.859:59): avc: denied { read } for pid=3121
comm="console-kit-dae" name="udev-acl.ck" dev="sda5" ino=1057310
scontext=system_u:system_r:consolekit_t
tcontext=system_u:object_r:udev_exec_t tclass=lnk_file
>> 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-
Ok with this module the denial about devicekit_power_t over apm_bios has
gone. It seems that the rw rights are not necessary.
Now it only remains the last one:
Aug 30 19:53:13 dell-studio kernel: [ 98.792934] type=1400
audit(1346349193.267:60): avc: denied { write } for pid=3240
comm="mkdir" name="/" dev="tmpfs" ino=2982
scontext=system_u:system_r:devicekit_power_t
tcontext=system_u:object_r:var_run_t tclass=dir
But even if it is related to devicekit_power_t it isn't over apm_bios,
but over var_run_t. Should I try to add something similar (but to
var_run_t) in that module?
>
> 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
>
Ok, tomorrow I'll try the live ebuilds and I'll let you know. Pure
curiosity: when I'll try the live ebuild or when the rev5 will be out,
should I remove these modules you wrote in emails (localconsolekit and
localdevicekit)?
Thank you.
Paolo.
