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?
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).
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).
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).
> 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).
Wkr,
Sven Vermeulen
