| 1 |
On Wed, Aug 29, 2012 at 06:36:07PM +0200, Paolo Barile wrote: |
| 2 |
> > Okay. I'll take a look at the AVCs earlier and draft up a possible fix for |
| 3 |
> > you to try out (you can use audit2allow but I'm not sure yet if the result |
| 4 |
> > is correct or not). |
| 5 |
> Thank you very much. |
| 6 |
|
| 7 |
You're welcome. |
| 8 |
|
| 9 |
> As for your question about error messages, i |
| 10 |
> noticed that starting kmix from shell gives me: |
| 11 |
> |
| 12 |
> QDBusConnection: session D-Bus connection created before |
| 13 |
> QCoreApplication. Application may misbehave. |
| 14 |
> |
| 15 |
> And kmix doesn't start. |
| 16 |
|
| 17 |
Yes. I *think* it is because alsa in the beginning wants to access /dev/shm |
| 18 |
(and then create shared memory for interacting with pulseaudio) but because |
| 19 |
/dev/shm is mislabeled (in your output, it is device_t, whereas it should be |
| 20 |
tmpfs_t) alsa can't do all that. That's probably the cause of this. |
| 21 |
|
| 22 |
See this: |
| 23 |
|
| 24 |
#v+ |
| 25 |
Aug 21 08:45:49 dell-studio kernel: [ 8.588644] type=1400 |
| 26 |
audit(1345538718.587:10): avc: denied { write } for pid=1452 |
| 27 |
comm="alsactl" name="shm" dev="tmpfs" ino=2984 |
| 28 |
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:device_t |
| 29 |
tclass=dir |
| 30 |
Aug 21 08:45:49 dell-studio kernel: [ 8.588652] type=1400 |
| 31 |
audit(1345538718.587:11): avc: denied { add_name } for pid=1452 |
| 32 |
comm="alsactl" name="pulse-shm-1979112542" |
| 33 |
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:device_t |
| 34 |
tclass=dir |
| 35 |
#v- |
| 36 |
|
| 37 |
As you are using cryptsetup, I imagine you are using an initramfs, right? Is |
| 38 |
the /dev/shm location mounted in the initramfs or afterwards by openrc? |
| 39 |
|
| 40 |
Is the context corrected later in the boot process (in other words, if you |
| 41 |
check the label now with "ls -dZ /dev/shm" is it tmpfs_t now?) |
| 42 |
|
| 43 |
> > following command again, I hope you get enough output? |
| 44 |
> > |
| 45 |
> > ~# grep root /etc/selinux/*/contexts/files/file_contexts.homedirs |
| 46 |
> Oh well, even too much perhaps now! ;) I mean it contains strings like: |
| 47 |
> |
| 48 |
> /root/\.mozilla(/.*)? unconfined_u:object_r:mozilla_home_t |
| 49 |
|
| 50 |
That's correct. |
| 51 |
|
| 52 |
> But I don't know why the root user should have rights for X |
| 53 |
> applications. Is that normal? If so, I think we can consider it solved! |
| 54 |
|
| 55 |
Well, the root user for SELinux is just another unconfined user, so it maps |
| 56 |
all contexts it knows for users to the root user location. |
| 57 |
|
| 58 |
> Do you suggest to map to unconfined_u the other users too? I'm asking it |
| 59 |
> because I noticed a slowness in openening folders (in X) for the first |
| 60 |
> time after the login. |
| 61 |
|
| 62 |
They should already be mapped (because of the "__default__" login mapping). |
| 63 |
You can verify that using the same grep command as before: |
| 64 |
|
| 65 |
~# grep yourusername /etc/selinux/*/contexts/files/file_contexts.homedirs |
| 66 |
|
| 67 |
> Well thanks to you for the yours! |
| 68 |
> Anyway with that module (but the creat_dirs_pattern rule is necessary), |
| 69 |
> the /run/console situation is solved too. |
| 70 |
|
| 71 |
Great. Now all I have to do is find out where exactly the creation is done |
| 72 |
(to document it properly), but a grep in the sources will probably help me |
| 73 |
with that ;-) |
| 74 |
|
| 75 |
[... many denials ...] |
| 76 |
> Thank you again for following me. |
| 77 |
|
| 78 |
You're welcome. I'm going over the denials right now one by one and looking |
| 79 |
at the ones I think I can resolve and document already. Some of them I skip |
| 80 |
and create a bugreport for, like with bug #433177, as I am not certain they |
| 81 |
are cosmetic or needed (but some way to track them through a bugreport is |
| 82 |
always a good idea imo). |
| 83 |
|
| 84 |
Wkr, |
| 85 |
Sven Vermeulen |
Archives