On Wed, Aug 29, 2012 at 06:36:07PM +0200, Paolo Barile wrote:
> > Okay. I'll take a look at the AVCs earlier and draft up a possible fix for
> > you to try out (you can use audit2allow but I'm not sure yet if the result
> > is correct or not).
> Thank you very much.
You're welcome.
> As for your question about error messages, i
> noticed that starting kmix from shell gives me:
>
> QDBusConnection: session D-Bus connection created before
> QCoreApplication. Application may misbehave.
>
> And kmix doesn't start.
Yes. I *think* it is because alsa in the beginning wants to access /dev/shm
(and then create shared memory for interacting with pulseaudio) but because
/dev/shm is mislabeled (in your output, it is device_t, whereas it should be
tmpfs_t) alsa can't do all that. That's probably the cause of this.
See this:
#v+
Aug 21 08:45:49 dell-studio kernel: [ 8.588644] type=1400
audit(1345538718.587:10): avc: denied { write } for pid=1452
comm="alsactl" name="shm" dev="tmpfs" ino=2984
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:device_t
tclass=dir
Aug 21 08:45:49 dell-studio kernel: [ 8.588652] type=1400
audit(1345538718.587:11): avc: denied { add_name } for pid=1452
comm="alsactl" name="pulse-shm-1979112542"
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:device_t
tclass=dir
#v-
As you are using cryptsetup, I imagine you are using an initramfs, right? Is
the /dev/shm location mounted in the initramfs or afterwards by openrc?
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?)
> > following command again, I hope you get enough output?
> >
> > ~# grep root /etc/selinux/*/contexts/files/file_contexts.homedirs
> Oh well, even too much perhaps now! ;) I mean it contains strings like:
>
> /root/\.mozilla(/.*)? unconfined_u:object_r:mozilla_home_t
That's correct.
> But I don't know why the root user should have rights for X
> applications. Is that normal? If so, I think we can consider it solved!
Well, the root user for SELinux is just another unconfined user, so it maps
all contexts it knows for users to the root user location.
> Do you suggest to map to unconfined_u the other users too? I'm asking it
> because I noticed a slowness in openening folders (in X) for the first
> time after the login.
They should already be mapped (because of the "__default__" login mapping).
You can verify that using the same grep command as before:
~# grep yourusername /etc/selinux/*/contexts/files/file_contexts.homedirs
> Well thanks to you for the yours!
> Anyway with that module (but the creat_dirs_pattern rule is necessary),
> the /run/console situation is solved too.
Great. Now all I have to do is find out where exactly the creation is done
(to document it properly), but a grep in the sources will probably help me
with that ;-)
[... many denials ...]
> Thank you again for following me.
You're welcome. I'm going over the denials right now one by one and looking
at the ones I think I can resolve and document already. Some of them I skip
and create a bugreport for, like with bug #433177, as I am not certain they
are cosmetic or needed (but some way to track them through a bugreport is
always a good idea imo).
Wkr,
Sven Vermeulen
