1 |
On 29/08/2012 20:49, Sven Vermeulen wrote: |
2 |
> Is the context corrected later in the boot process (in other words, if you |
3 |
> check the label now with "ls -dZ /dev/shm" is it tmpfs_t now?) |
4 |
Well in fact /dev/shm was mislabeled even if I don't use initramfs, so I |
5 |
added the following to fstab: |
6 |
|
7 |
shm /dev/shm tmpfs |
8 |
rw,rootcontext=system_u:object_r:tmpfs_t,seclabel,nosuid,nodev,noexec,relatime |
9 |
0 0 |
10 |
|
11 |
So now (after reboot) it is labeled: system_u:object_r:tmpfs_t /dev/shm. |
12 |
|
13 |
Anyway alsactl (and kmix) still doesn't work. It is (I think) because |
14 |
there's something strange in denials: |
15 |
|
16 |
Aug 30 19:52:15 dell-studio kernel: [ 8.562950] type=1400 |
17 |
audit(1346356301.561:3): avc: denied { getattr } for pid=1461 |
18 |
comm="alsactl" name="/" dev="tmpfs" ino=1232 |
19 |
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:tmpfs_t |
20 |
tclass=filesystem |
21 |
Aug 30 19:52:15 dell-studio kernel: [ 8.562975] type=1400 |
22 |
audit(1346356301.561:5): avc: denied { write } for pid=1461 |
23 |
comm="alsactl" name="shm" dev="tmpfs" ino=1236 |
24 |
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:device_t |
25 |
tclass=dir |
26 |
Aug 30 19:52:15 dell-studio kernel: [ 8.562984] type=1400 |
27 |
audit(1346356301.561:6): avc: denied { add_name } for pid=1461 |
28 |
comm="alsactl" name="pulse-shm-3830975079" |
29 |
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:device_t |
30 |
tclass=dir |
31 |
Aug 30 19:52:15 dell-studio kernel: [ 8.563014] type=1400 |
32 |
audit(1346356301.561:7): avc: denied { create } for pid=1461 |
33 |
comm="alsactl" name="pulse-shm-3830975079" |
34 |
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:device_t |
35 |
tclass=file |
36 |
Aug 30 19:52:15 dell-studio kernel: [ 8.563027] type=1400 |
37 |
audit(1346356301.562:8): avc: denied { read write open } for pid=1461 |
38 |
comm="alsactl" name="pulse-shm-3830975079" dev="tmpfs" ino=4239 |
39 |
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:device_t |
40 |
tclass=file |
41 |
Aug 30 19:52:15 dell-studio kernel: [ 8.608145] type=1400 |
42 |
audit(1346356301.607:9): avc: denied { remove_name } for pid=1461 |
43 |
comm="alsactl" name="pulse-shm-3830975079" dev="tmpfs" ino=4239 |
44 |
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:device_t |
45 |
tclass=dir |
46 |
Aug 30 19:52:15 dell-studio kernel: [ 8.608154] type=1400 |
47 |
audit(1346356301.607:10): avc: denied { unlink } for pid=1461 |
48 |
comm="alsactl" name="pulse-shm-3830975079" dev="tmpfs" ino=4239 |
49 |
scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:device_t |
50 |
tclass=file |
51 |
|
52 |
As you can see even if the first denial reports shm labeled as tmpfs_t |
53 |
all the other report it as device_it. How can it be possible? |
54 |
|
55 |
|
56 |
> On Wed, Aug 29, 2012 at 06:36:07PM +0200, Paolo Barile wrote: |
57 |
>> Aug 29 18:09:04 dell-studio kernel: [ 112.875933] type=1400 |
58 |
>> audit(1346256544.115:57): avc: denied { read } for pid=3066 |
59 |
>> comm="udev-acl.ck" name="udev-acl" dev="tmpfs" ino=3219 |
60 |
>> scontext=system_u:system_r:consolekit_t |
61 |
>> tcontext=system_u:object_r:udev_var_run_t tclass=dir |
62 |
> This one is biting me a bit. Could you try labeling udev-acl.ck (wherever it |
63 |
> is) as udev_exec_t and see if that helps? |
64 |
> |
65 |
> The udev-acl.ck code tries to iterate over devices, setting the proper |
66 |
> access controls. This is most likely what is causing your USB disks to not |
67 |
> show up (properly). However, I'm not very fond of allowing consolekit_t to |
68 |
> do this if this is a udev-task (and more specifically, udev-acl.c (the |
69 |
> source cde) uses a lot of udev related methods for this. |
70 |
> |
71 |
> The alternative (if we don't run it as udev) is to allow all possible rights |
72 |
> on consolekit, but I think that'll be a lot more than reading the directory |
73 |
> (as this is just the first step). |
74 |
The file is /usr/lib64/ConsoleKit/run-seat.d/udev-acl.ck, it is a |
75 |
symlink to /usr/libexec/udev-acl that is labeled bin_t. |
76 |
Anyway I relabeled udev-acl.ck as udev_exec_t, so that denial |
77 |
disappeard, but now I have this new one: |
78 |
|
79 |
Aug 30 19:31:06 dell-studio kernel: [ 75.419082] type=1400 |
80 |
audit(1346347866.859:59): avc: denied { read } for pid=3121 |
81 |
comm="console-kit-dae" name="udev-acl.ck" dev="sda5" ino=1057310 |
82 |
scontext=system_u:system_r:consolekit_t |
83 |
tcontext=system_u:object_r:udev_exec_t tclass=lnk_file |
84 |
|
85 |
|
86 |
>> Aug 29 18:10:14 dell-studio kernel: [ 183.307019] type=1400 |
87 |
>> audit(1346256614.546:69): avc: denied { getattr } for pid=3233 |
88 |
>> comm="pm-is-supported" path="/dev/snapshot" dev="tmpfs" ino=3438 |
89 |
>> scontext=system_u:system_r:devicekit_power_t |
90 |
>> tcontext=system_u:object_r:apm_bios_t tclass=chr_file |
91 |
>> Aug 29 18:10:14 dell-studio kernel: [ 183.318766] type=1400 |
92 |
>> audit(1346256614.558:70): avc: denied { getattr } for pid=3252 |
93 |
>> comm="pm-is-supported" path="/dev/snapshot" dev="tmpfs" ino=3438 |
94 |
>> scontext=system_u:system_r:devicekit_power_t |
95 |
>> tcontext=system_u:object_r:apm_bios_t tclass=chr_file |
96 |
>> Aug 29 18:10:14 dell-studio kernel: [ 183.717762] type=1400 |
97 |
>> audit(1346256614.957:71): avc: denied { getattr } for pid=3276 |
98 |
>> comm="pm-powersave" path="/dev/snapshot" dev="tmpfs" ino=3438 |
99 |
>> scontext=system_u:system_r:devicekit_power_t |
100 |
>> tcontext=system_u:object_r:apm_bios_t tclass=chr_file |
101 |
>> Aug 29 18:10:14 dell-studio kernel: [ 183.721637] type=1400 |
102 |
>> audit(1346256614.961:72): avc: denied { write } for pid=3281 |
103 |
>> comm="mkdir" name="/" dev="tmpfs" ino=1059 |
104 |
>> scontext=system_u:system_r:devicekit_power_t |
105 |
>> tcontext=system_u:object_r:var_run_t tclass=dir |
106 |
> [...] |
107 |
> |
108 |
> This one we need to work out further. I'm okay with allowing |
109 |
> devicekit_power_t to get the attributes of apm_bios_t, but for some reason I |
110 |
> don't think that'll be enough. |
111 |
> |
112 |
> Care to add in something like: |
113 |
> |
114 |
> #v+ |
115 |
> policy_module(localdevicekit, 1.0) |
116 |
> |
117 |
> gen_require(` |
118 |
> type devicekit_power_t; |
119 |
> ') |
120 |
> |
121 |
> dev_getattr_apm_bios_dev(devicekit_power_t) |
122 |
> #v- |
123 |
> |
124 |
> and then see what happens next? If it wants to read or write to it, add in: |
125 |
> |
126 |
> #v+ |
127 |
> dev_rw_apm_bios(devicekit_power_t) |
128 |
> #v- |
129 |
Ok with this module the denial about devicekit_power_t over apm_bios has |
130 |
gone. It seems that the rw rights are not necessary. |
131 |
Now it only remains the last one: |
132 |
|
133 |
Aug 30 19:53:13 dell-studio kernel: [ 98.792934] type=1400 |
134 |
audit(1346349193.267:60): avc: denied { write } for pid=3240 |
135 |
comm="mkdir" name="/" dev="tmpfs" ino=2982 |
136 |
scontext=system_u:system_r:devicekit_power_t |
137 |
tcontext=system_u:object_r:var_run_t tclass=dir |
138 |
|
139 |
But even if it is related to devicekit_power_t it isn't over apm_bios, |
140 |
but over var_run_t. Should I try to add something similar (but to |
141 |
var_run_t) in that module? |
142 |
> |
143 |
> For the rest, I've put in quite a few changes in the policy for the other |
144 |
> denials shown earlier. They will definitely be in revision 5, but if you |
145 |
> know how to work with live ebuilds, you can use the SELinux live ebuilds as |
146 |
> well (since the changes are in the policy repository). |
147 |
> |
148 |
> An overview of all changes: |
149 |
> http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-refpolicy.git;a=summary |
150 |
> |
151 |
> Wkr, |
152 |
> Sven Vermeulen |
153 |
> |
154 |
|
155 |
Ok, tomorrow I'll try the live ebuilds and I'll let you know. Pure |
156 |
curiosity: when I'll try the live ebuild or when the rev5 will be out, |
157 |
should I remove these modules you wrote in emails (localconsolekit and |
158 |
localdevicekit)? |
159 |
Thank you. |
160 |
Paolo. |