1 |
On Wed, Aug 22, 2012 at 09:12:52AM +0200, f.p.barile@×××××.com2 wrote: |
2 |
> Now the step by step denials. |
3 |
> I firstly removed the xdm initscript from the default runlevel and I |
4 |
> started it manually. After starting xdm these were the denials: |
5 |
> |
6 |
> Aug 22 08:39:03 dell-studio kernel: [ 162.895575] type=1400 |
7 |
> audit(1345617543.503:121): avc: denied { getattr } for pid=2010 |
8 |
> comm="console-kit-dae" path="/run/ConsoleKit" dev="tmpfs" ino=4632 |
9 |
> scontext=system_u:system_r:consolekit_t |
10 |
> tcontext=system_u:object_r:initrc_var_run_t tclass=dir |
11 |
|
12 |
This first one is an interesting one to immediately look at. It seems that |
13 |
the console-kit-dae(mon?) uses /run/ConsoleKit, and I guess (from the |
14 |
initrc_var_run_t domain) that its init script creates it, not? |
15 |
|
16 |
If that's indeed the case, I'll need to update the policy to reflect this, |
17 |
allowing initrc_t to create /run/ConsoleKit but with a good file transition |
18 |
(in this case, to consolekit_var_run_t). |
19 |
|
20 |
Skipping a few other denials related to this, and then we get: |
21 |
|
22 |
> Aug 22 08:39:34 dell-studio kernel: [ 193.785181] type=1400 |
23 |
> audit(1345617574.393:126): avc: denied { read } for pid=3101 |
24 |
> comm="udev-acl.ck" name="udev-acl" dev="tmpfs" ino=1427 |
25 |
> scontext=system_u:system_r:consolekit_t |
26 |
> tcontext=system_u:object_r:udev_var_run_t tclass=dir |
27 |
|
28 |
I don't know consolekit, but I assume there is some udev rule somewhere that |
29 |
creates a file for consolekit? |
30 |
|
31 |
The consolekit_t domain has the rights to read udev_tbl_t stuff (which I |
32 |
find a stupid name for a domain). Where is this udev-acl.ck file located? |
33 |
You can find it through its inode number (ino=1427) if you haven't rebooted |
34 |
yet (since it is on a tmpfs within a *_var_run_t so very likely to be within |
35 |
/run/udev somewhere). |
36 |
|
37 |
Usually, I ignore the remainder of denials (especially if it is in |
38 |
permissive mode) until I fixed the first ones, because those can be a |
39 |
trigger for other behavior (and I don't want to update the policy for things |
40 |
that aren't needed). |
41 |
|
42 |
> Then I tried to start powerdevil in kde systemsettings and these were |
43 |
> the denials: |
44 |
> |
45 |
> Aug 22 08:47:14 dell-studio kernel: [ 653.535413] type=1400 |
46 |
> audit(1345618034.143:239): avc: denied { execute } for pid=5378 |
47 |
> comm="dbus-daemon-lau" name="upowerd" dev="sda5" ino=939375 |
48 |
> scontext=system_u:system_r:system_dbusd_t |
49 |
> tcontext=system_u:object_r:bin_t tclass=file |
50 |
|
51 |
I had (still have actually) a bug open for udisks which is launched by dbus. |
52 |
From what I can tell, everything dbus launches should be in its own domain |
53 |
(otherwise it'll run in the permissions of system_dbusd_t, which we want to |
54 |
keep as limited as they are). |
55 |
|
56 |
So most of the remainder of the denials I'll have to ignore until we can get |
57 |
a policy for it. |
58 |
|
59 |
It looks like the devicekit policy is a match for it, but I haven't created |
60 |
an ebuild for it yet. I'll do so soon (with the rev4 release) so you can |
61 |
test this out. |
62 |
|
63 |
> About the su question, before and after logging in su the context is |
64 |
> unconfined_u:unconfined_r:unconfined_t, while the denials are: |
65 |
> |
66 |
> Aug 22 08:43:53 dell-studio kernel: [ 452.789311] type=1400 |
67 |
> audit(1345617833.396:228): avc: denied { search } for pid=4358 |
68 |
> comm="xauth" name="root" dev="sda5" ino=1308163 |
69 |
> scontext=unconfined_u:unconfined_r:xauth_t |
70 |
> tcontext=system_u:object_r:default_t tclass=dir |
71 |
|
72 |
That's not good. default_t means that there is a directory not labeled |
73 |
properly (most likely root's home directory). Run "rlpkg -a -r" to relabel |
74 |
the entire system and see if that removes any traces of default_t (you |
75 |
should never encounter default_t iirc). |
76 |
|
77 |
Wkr, |
78 |
Sven Vermeulen |