1 |
On Sat, Aug 25, 2012 at 07:00:09PM +0200, Paolo Barile wrote: |
2 |
> Hi Sven, thank you for rev4, but it didn't conclusively solve my |
3 |
> problems. Sone denial has gone, but many of them remain. |
4 |
> |
5 |
> So let's see again all the step by step denial, I'll avoid redundancies. |
6 |
> |
7 |
> As I boot (whithout starting xdm) I obtain: |
8 |
> |
9 |
> Aug 25 18:06:05 dell-studio kernel: [ 8.028595] type=1400 |
10 |
> audit(1345917944.027:3): avc: denied { search } for pid=1433 |
11 |
> comm="alsactl" name="root" dev="sda5" ino=1308163 |
12 |
> scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:default_t |
13 |
> tclass=dir |
14 |
|
15 |
This sais /root is default_t again. Mine sais: |
16 |
|
17 |
~ # matchpathcon /root |
18 |
/root root:object_r:user_home_dir_t |
19 |
|
20 |
~ # grep '/root' /etc/selinux/strict/contexts/files/file_contexts* | grep user_home_dir_t |
21 |
/etc/selinux/strict/contexts/files/file_contexts.homedirs:/root -d root:object_r:user_home_dir_t |
22 |
|
23 |
It is because /root is marked as a home directory of a user that a hole set |
24 |
of contexts is generated for it. Perhaps for a targeted system this is |
25 |
different, but I don't think so. |
26 |
|
27 |
Whenever you hit a denial with file_t or default_t in it, it means there is |
28 |
something awry with the contexts on the system. |
29 |
|
30 |
You might be able to fix it by running genhomedircon (without options). It |
31 |
should regenerate the file context as mentioned in my grep result above. |
32 |
|
33 |
> Aug 25 18:06:05 dell-studio kernel: [ 8.707035] type=1400 |
34 |
> audit(1345917944.706:7): avc: denied { read } for pid=1431 |
35 |
> comm="alsactl" name="urandom" dev="tmpfs" ino=3356 |
36 |
> scontext=system_u:system_r:alsa_t |
37 |
> tcontext=system_u:object_r:urandom_device_t tclass=chr_file |
38 |
|
39 |
Did you enable global_ssp (or are you not running a hardened system, just |
40 |
SELinux)? By enabling the global_ssp boolean, all domains get access to the |
41 |
urandom_device_t chr_file: |
42 |
|
43 |
~ # sesearch -s alsa_t -t urandom_device_t -A -C |
44 |
Found 2 semantic av rules: |
45 |
DT allow nsswitch_domain urandom_device_t : chr_file { ioctl read getattr lock open } ; [ authlogin_nsswitch_use_ldap ] |
46 |
ET allow domain urandom_device_t : chr_file { ioctl read getattr lock open } ; [ global_ssp ] |
47 |
|
48 |
> Aug 25 18:06:05 dell-studio kernel: [ 8.707053] type=1400 |
49 |
> audit(1345917944.706:9): avc: denied { read } for pid=1431 |
50 |
> comm="alsactl" name="random" dev="tmpfs" ino=1642 |
51 |
> scontext=system_u:system_r:alsa_t |
52 |
> tcontext=system_u:object_r:random_device_t tclass=chr_file |
53 |
|
54 |
This one is new for me. If it is prohibiting alsa to work, we'll need to |
55 |
allow this, but I think you're booting in permissive mode, so we can't know |
56 |
for sure if the denial is cosmetic or not. |
57 |
|
58 |
> Aug 25 18:06:05 dell-studio kernel: [ 8.707089] type=1400 |
59 |
> audit(1345917944.706:11): avc: denied { getattr } for pid=1431 |
60 |
> comm="alsactl" name="/" dev="tmpfs" ino=2970 |
61 |
> scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:tmpfs_t |
62 |
> tclass=filesystem |
63 |
|
64 |
Which file system is it trying to get attributes from here? |
65 |
|
66 |
> Aug 25 18:06:05 dell-studio kernel: [ 16.930444] type=1400 |
67 |
> audit(1345910753.814:32): avc: denied { module_request } for pid=1517 |
68 |
> comm="cryptsetup" kmod="cbc(aes)" scontext=system_u:system_r:lvm_t |
69 |
> tcontext=system_u:system_r:kernel_t tclass=system |
70 |
> Aug 25 18:06:05 dell-studio kernel: [ 16.930452] type=1400 |
71 |
> audit(1345910753.814:33): avc: denied { module_request } for pid=1517 |
72 |
> comm="cryptsetup" kmod="cbc(aes)-all" scontext=system_u:system_r:lvm_t |
73 |
> tcontext=system_u:system_r:kernel_t tclass=system |
74 |
> Aug 25 18:06:05 dell-studio kernel: [ 16.930505] type=1400 |
75 |
> audit(1345910753.814:34): avc: denied { module_request } for pid=1517 |
76 |
> comm="cryptsetup" kmod="cbc(aes-asm)" scontext=system_u:system_r:lvm_t |
77 |
> tcontext=system_u:system_r:kernel_t tclass=system |
78 |
> Aug 25 18:06:05 dell-studio kernel: [ 16.930512] type=1400 |
79 |
> audit(1345910753.814:35): avc: denied { module_request } for pid=1517 |
80 |
> comm="cryptsetup" kmod="cbc(aes-asm)-all" |
81 |
> scontext=system_u:system_r:lvm_t tcontext=system_u:system_r:kernel_t |
82 |
> tclass=system |
83 |
> Aug 25 18:06:05 dell-studio kernel: [ 16.936081] type=1400 |
84 |
> audit(1345910753.820:36): avc: denied { getattr } for pid=1517 |
85 |
> comm="cryptsetup" name="/" dev="tmpfs" ino=2970 |
86 |
> scontext=system_u:system_r:lvm_t tcontext=system_u:object_r:tmpfs_t |
87 |
> tclass=filesystem |
88 |
> Aug 25 18:06:05 dell-studio kernel: [ 17.138342] type=1400 |
89 |
> audit(1345910754.022:38): avc: denied { read } for pid=1538 |
90 |
> comm="cryptsetup" name="queue.bin" dev="tmpfs" ino=4265 |
91 |
> scontext=system_u:system_r:lvm_t |
92 |
> tcontext=system_u:object_r:udev_var_run_t tclass=file |
93 |
> Aug 25 18:06:05 dell-studio kernel: [ 27.701565] type=1400 |
94 |
|
95 |
The cryptsetup stuff might need some more updates, I only use cryptsetup for |
96 |
a small encrypted partition (and not a system partition) and I have most of |
97 |
the stuff in-kernel anyway, so no module requests here... |
98 |
|
99 |
We'll need to look at this when you boot in enforcing mode, since I need the |
100 |
error message(s) as well in order to update the policy. |
101 |
|
102 |
Same is true for most of the remaining denials btw. Some of them definitely |
103 |
need to be looked at in advance, like the next set, but most of them will |
104 |
need to be reproduced with enforcing mode... |
105 |
|
106 |
> audit(1345910765.120:46): avc: denied { getattr } for pid=1998 |
107 |
> comm="console-kit-dae" path="/run/ConsoleKit" dev="tmpfs" ino=5251 |
108 |
> scontext=system_u:system_r:consolekit_t |
109 |
> tcontext=system_u:object_r:initrc_var_run_t tclass=dir |
110 |
|
111 |
Need to add in this run directory, haven't done that yet. |
112 |
|
113 |
> Aug 25 18:06:05 dell-studio kernel: [ 28.632129] type=1400 |
114 |
> audit(1345910765.516:48): avc: denied { execute } for pid=2089 |
115 |
> comm="dbus-daemon-lau" name="polkitd" dev="sda5" ino=922900 |
116 |
> scontext=system_u:system_r:system_dbusd_t |
117 |
> tcontext=system_u:object_r:policykit_exec_t tclass=file |
118 |
|
119 |
Probably needs to be made a dbus domain. |
120 |
|
121 |
> Aug 25 18:06:06 dell-studio kernel: [ 29.168487] type=1400 |
122 |
> audit(1345910766.052:52): avc: denied { write } for pid=2222 |
123 |
> comm="mii-tool" path="/run/lock/lmt-req.lock" dev="tmpfs" ino=5314 |
124 |
> scontext=system_u:system_r:ifconfig_t |
125 |
> tcontext=system_u:object_r:var_lock_t tclass=file |
126 |
> Aug 25 18:06:06 dell-studio kernel: [ 29.168499] type=1400 |
127 |
> audit(1345910766.052:53): avc: denied { write } for pid=2222 |
128 |
> comm="mii-tool" path="/run/lock/lmt-invoc.lock" dev="tmpfs" ino=4776 |
129 |
> scontext=system_u:system_r:ifconfig_t |
130 |
> tcontext=system_u:object_r:var_lock_t tclass=file |
131 |
|
132 |
Probably legit, but I'm not sure if I need to create an ifconfig_lock_t type |
133 |
for this, or just grant in var_lock_t access. Probably the former. |
134 |
|
135 |
> After logging in, apart all the same mentioned above that repeat |
136 |
> themselves, I get a lot of: |
137 |
> Aug 25 18:10:25 dell-studio kernel: [ 289.004361] type=1400 |
138 |
> audit(1345911025.905:163): avc: denied { search } for pid=1968 |
139 |
> comm="dbus-daemon" name="console" dev="tmpfs" ino=5945 |
140 |
> scontext=system_u:system_r:system_dbusd_t |
141 |
> tcontext=system_u:object_r:consolekit_var_run_t tclass=dir |
142 |
|
143 |
What does the console dir contain? It's probably in /var/run/ConsoleKit |
144 |
(although from your earlier denials I get the impression /var/run/ConsoleKit |
145 |
is not correctly labeled, whereas in this denial it is - did you relabel the |
146 |
system or some parts of it in between?). |
147 |
|
148 |
I recommend to first work on the default_t and file_t stuff. That shouldn't |
149 |
be broken. Then in the denials, look at any denials for "execute", they |
150 |
almost always need to be fixed (whereas getattr/read's can often be ignored, |
151 |
especially in the beginning). |
152 |
|
153 |
Then, when booted and logged in, clear the denial log and switch to |
154 |
enforcing mode and see what stuff breaks. Then look in the denial log for |
155 |
the denials, and give the error messages for the broken applications. |
156 |
|
157 |
When we fixed that, we should then look at the cryptsetup stuff, since you |
158 |
need that in order to boot succesfully I guess. Only then can we try to boot |
159 |
in enforcing mode (once, until it boots fully). |
160 |
|
161 |
Wkr, |
162 |
Sven Vermeulen |