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