On 22/08/2012 20:43, Sven Vermeulen wrote:
> On Wed, Aug 22, 2012 at 09:12:52AM +0200, [email protected] wrote:
>> Now the step by step denials.
>> I firstly removed the xdm initscript from the default runlevel and I
>> started it manually. After starting xdm these were the denials:
>>
>> Aug 22 08:39:03 dell-studio kernel: [ 162.895575] type=1400
>> audit(1345617543.503:121): avc: denied { getattr } for pid=2010
>> comm="console-kit-dae" path="/run/ConsoleKit" dev="tmpfs" ino=4632
>> scontext=system_u:system_r:consolekit_t
>> tcontext=system_u:object_r:initrc_var_run_t tclass=dir
> This first one is an interesting one to immediately look at. It seems that
> the console-kit-dae(mon?) uses /run/ConsoleKit, and I guess (from the
> initrc_var_run_t domain) that its init script creates it, not?
In /etc/init.d/consolekit I read "checkpath -q -d -m 0755
/var/run/ConsoleKit" and being /var/run symlinked to /run, it seems
you're right.
>
> If that's indeed the case, I'll need to update the policy to reflect this,
> allowing initrc_t to create /run/ConsoleKit but with a good file transition
> (in this case, to consolekit_var_run_t).
Excuse me for the stupid question... In that case, will consolekit_t
have rights over consolekit_var_run_t? Will it be in rev4?
>
> Skipping a few other denials related to this, and then we get:
>
>> Aug 22 08:39:34 dell-studio kernel: [ 193.785181] type=1400
>> audit(1345617574.393:126): avc: denied { read } for pid=3101
>> comm="udev-acl.ck" name="udev-acl" dev="tmpfs" ino=1427
>> scontext=system_u:system_r:consolekit_t
>> tcontext=system_u:object_r:udev_var_run_t tclass=dir
> I don't know consolekit, but I assume there is some udev rule somewhere that
> creates a file for consolekit?
>
> The consolekit_t domain has the rights to read udev_tbl_t stuff (which I
> find a stupid name for a domain). Where is this udev-acl.ck file located?
> You can find it through its inode number (ino=1427) if you haven't rebooted
> yet (since it is on a tmpfs within a *_var_run_t so very likely to be within
> /run/udev somewhere).
Searching from inode I located a folder (/run/udev/tags/udev-acl)
containing files called bXXX:X or cXXX:X, but there is no trace of any
udev-acl.ck file.
>
> Usually, I ignore the remainder of denials (especially if it is in
> permissive mode) until I fixed the first ones, because those can be a
> trigger for other behavior (and I don't want to update the policy for things
> that aren't needed).
I completely agree with you.
>
>> Then I tried to start powerdevil in kde systemsettings and these were
>> the denials:
>>
>> Aug 22 08:47:14 dell-studio kernel: [ 653.535413] type=1400
>> audit(1345618034.143:239): avc: denied { execute } for pid=5378
>> comm="dbus-daemon-lau" name="upowerd" dev="sda5" ino=939375
>> scontext=system_u:system_r:system_dbusd_t
>> tcontext=system_u:object_r:bin_t tclass=file
> I had (still have actually) a bug open for udisks which is launched by dbus.
> From what I can tell, everything dbus launches should be in its own domain
> (otherwise it'll run in the permissions of system_dbusd_t, which we want to
> keep as limited as they are).
>
> So most of the remainder of the denials I'll have to ignore until we can get
> a policy for it.
>
> It looks like the devicekit policy is a match for it, but I haven't created
> an ebuild for it yet. I'll do so soon (with the rev4 release) so you can
> test this out.
>
>> About the su question, before and after logging in su the context is
>> unconfined_u:unconfined_r:unconfined_t, while the denials are:
>>
>> Aug 22 08:43:53 dell-studio kernel: [ 452.789311] type=1400
>> audit(1345617833.396:228): avc: denied { search } for pid=4358
>> comm="xauth" name="root" dev="sda5" ino=1308163
>> scontext=unconfined_u:unconfined_r:xauth_t
>> tcontext=system_u:object_r:default_t tclass=dir
> That's not good. default_t means that there is a directory not labeled
> properly (most likely root's home directory). Run "rlpkg -a -r" to relabel
> the entire system and see if that removes any traces of default_t (you
> should never encounter default_t iirc).
I tried rlpkg but /root still remains in system_u:object_r:default_t
context. Moreover in /etc/selinux/targeted/contexts/files/file_contexts
the only thing related to that folder is
"/root/\.default_contexts --
system_u:object_r:default_context_t".
>
> Wkr,
> Sven Vermeulen
>
Thank you again, Sven. Paolo.
