Discussion on IRC

<dwalsh> poettering, Hey did kdbus just get turned on in Rawhide?  I am seeing some weird SELinux issues.  Lots of processes being started by dbus are running as unconfined_service_t.  This only happens if init_t or systemd_dbusd_t executes a file labeled bin_t.  What executeable launches sessions/services with kdbus?
<dvdhrm> dwalsh, no, it did not.
<dvdhrm> dwalsh, might be related to Dbus updates, though.
<dvdhrm> They're optionally started on the user-bus.
<dwalsh> I see sessions in my login as well as system sessions.  setroubleshootd, udisksd etc, In my user session, I am seeing gnome-terminal running as unconfined_service_t.
<dvdhrm> dwalsh, weird.
<dwalsh> http://ur1.ca/ns54a
<dwalsh> Actually it looks like it is mostly session bus, for gdm and my login
<dvdhrm> dwalsh, it's all session-bus
<dvdhrm> dwalsh, Hm. They should still be spawned by dbus-daemon.
<dvdhrm> But applications are free to enable dbus-activation via --user units.
<dwalsh> Is session-bus now spawned by dbus-daemon, where as it was different before.
<dvdhrm> dwalsh, dbus-daemon is now spawned by --user, so maybe that's the issue.
<dvdhrm> Before it was spawned by gdm/X
<dvdhrm> dwalsh, there's now a systemd unit for dbus-daemon (dbus.service / dbus.socket)
<dwalsh> Right, I see /usr/bin/dbus-daemon --session  running as dbusd_exec_t in the user session where it used to run as unconfined_dbusd_t
<dvdhrm> dwalsh, Can you fix this? I'll gladly provide you more information, but I'm kinda lost, sorry.
<dwalsh> How does dbus-daemon --session now get launched?
<dvdhrm> dwalsh, via systemd --user. It's socket activated via /run/user/$uid/bus
<halfline> so previously when you first logged in GDM would start a dbus daemon right before it started the user session
<halfline> GDM only does this if DBUS_SESSION_BUS_ADDRESS isn't set
<dvdhrm> Yepp.
<halfline> i assume now, pam_systemd settings DBUS_SESSION_BUS_ADDRESS ?
<dvdhrm> dbus-daemon-1.10 optionally supports the user-bus to make it socket-activated
<halfline> and it it implicitly activates dbus-daemon from the session stack of the pam service ?
<dvdhrm> systemd-226 also added support for this, if the socket-activation is enabled.
<dvdhrm> Nah, systemd doesn't enable it. Only if the dbus.socket/service unit is enabled, the user-bus is used.
<dwalsh> Well we might need to patch systemd to get the right thing to happen. Basically we want the session bus to run based off of the caller process.  If it is unconfined_t it should run it as unconfined_dbusd_t
<dwalsh> if staff_t run it as staff_dbusd_t.
<dwalsh> This happens automatically via transition rules.
<dwalsh> unconfined_t @dbusd_exec_t -> unconfined_dbusd_t
<halfline> is the dbus.socket user unit enabled by default now ?
<dwalsh> Seems to be
<dvdhrm> dbus-daemon-1.10 installs it by default as multi-user dependency, yes.
<halfline> so what's 1) connecting to the socket first to make it activate at login time 2) pushing DBUS_SESSION_BUS_ADDRESS into the environment before GDM runs its own instance ?
<dvdhrm> halfline, pam_systemd pushes it into the environment if the socket in /run exists
<dvdhrm> Regarding 1): no-one. Socket activation does _not_ require activation at login time
<dvdhrm> It's transparent.
<halfline> oh, i understand now, the socket address is a well known name, so pam_systemd sets it before hand
<dvdhrm> Yes, it's even hard-coded in gdbus, libdbus, etc.
<halfline> gotcah
<halfline> *gotcha
<dvdhrm> dwalsh, `systemd --user` is run from within a pam-session of the user. dbus-daemon is then forked off there.
<halfline> s/a/the first/
<dvdhrm> true
<dwalsh> <dwalsh> We need systemd to do something like, ask kernel if SOURCE executes dbusd_exec_t, what context should it run as, and then setexeccon on it.
<dwalsh> <dwalsh> unconfined_t @ dbusd_exec_t -> unconfined_dbusd_t
<dwalsh> <dwalsh> staff_t @dbusd_exec_t -> staff_dbusd_t
<dwalsh> If the process that is talking to the socket is running as unconfined_t this will work.
<halfline> yea it should be unconfined by default since it's a child of the first pam session
<halfline> hmm there's a bit of asymmetry here though
<halfline> if something causes a system service to activate, the activated service doesn't run in the context of the thing activating it
<dwalsh> Currently it is just executing the dbusd_exec_t based on systemds label.  init_t @dbusd_exec_t -> system_dbusd_t Which is very wrong.
<halfline> e.g. if I run "systemctl start foo.service" foo.service doesn't run unconfined
<dwalsh> As long as the session bus is running as unconfined_dbusd_t or staff_dbusd_t the rest of the transitions will work.
<dwalsh> Correct.
<dwalsh> The problem is just with systemd executing dbusd_exec_t on behalf of a user.
<halfline> but you're suggesting that if i run systemctl --user start foo.service it should run the foo user service as the context of the process that ran the command
<dwalsh> No I am suggesting that it follow the rules as is the user session ran dbusd_exec_t itself.
<dwalsh> Rather then init_t running itself.
<dwalsh> init_t @ dbusd_exec_t -> system_dbusd_t
<dwalsh> unconfined_t @dbusd_exec_t -> unconfined_dbusd_t
<dwalsh> Which is what we have in f23 and before.
<halfline> okay so you're not saying to look at the source directly, i misunderstood
<dvdhrm> What's "systemd --user" running as?
<dwalsh> Right we have two options from systemd it either queries the policy, which systemd already does for other impersonations.  Or it could do a fork(), setcon(SOURCE); exec dbusd_exec_t
<dwalsh> dvdhrm, unconfined_t or staff_t or gdm_t 
<dwalsh> It is running in the uses session. 
<dwalsh> It is running in the user session. 
<dwalsh> When systemd does socket activation for a service, it is doing this via setcon()  IE If it listens for apache it does it as httpd_t, if it does it for sshd it does it as sshd_t, at least theoretically.
<sd-bot7> [systemd|jwrdegoede] hwdb: Add Thinkpad X1 carbon 3rd gen to 70-pointingstick.hwdb https://github.com/systemd/systemd/commit/c01705b
<sd-bot7> [systemd|zonque] Merge pull request #1267 from systemd-mailing-devs/1442233013-14985-1-git-send-email-hdegoede https://github.com/systemd/systemd/commit/e72b93f
<halfline> dwalsh: so i don't understand how it's running as dbus_exec_t
<halfline> if it's parent is systemd --user running as unconfined_t how is it transitioning to dbus_exec_t right now?
<halfline> if it didn't do that wouldn't things be golden ?
<halfline> socket activation is handled by the systemd --user instance, not the systemd system instance if i understand correctly
<dwalsh> I think systemd --user sends a message to systemd and systemd executes the user session.
<dwalsh> I don't think systemd --user is executing dbusd directly.

Ok, this is maybe a problem with 

/usr/lib/systemd/systemd --user

running as init_t instead of unconfined_t for unconfined_u SELinux user. So the problem is we lack of pam_selinux support for /etc/pam.d/systemd-user. AFAIK there is a bug for this.

$ ps axfZ | grep dbus
http://pastebin.test.redhat.com/312551

But we need to do more testing if this could be a solution here.

(In reply to Miroslav Grepl from comment #2)
> Ok, this is maybe a problem with 
> 
> /usr/lib/systemd/systemd --user
> 
> running as init_t instead of unconfined_t for unconfined_u SELinux user. So
> the problem is we lack of pam_selinux support for /etc/pam.d/systemd-user.
> AFAIK there is a bug for this.
> 
> $ ps axfZ | grep dbus
> http://pastebin.test.redhat.com/312551

This is with pam_selinux + systemd-user.

> 
> But we need to do more testing if this could be a solution here.

For testing you need to uncomment pam_selinux.so calling in /etc/pam.d/systemd-user and add the following local policy

$ cat mysystemdpam.cil
(allow userdomain init_exec_t(file (entrypoint)))
(allow init_t userdomain( process (transition)))

# semodule -i mysystemdpam.cil 

Note: It has been tested only for unconfined_u SELinux user. I see some pam_selinux troubles with SELinux confined users which need to be more explored.

I've added the following 2 lines to /etc/pam.d/systemd-user and it seems to work for stafff_u and session services while system services stay unconfined_service_t.

session    required     pam_selinux.so close
session    required     pam_selinux.so open env_params

system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 1101 ? Ssl   0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
system_u:system_r:unconfined_service_t:s0-s0:c0.c1023 1702 ? Sl   0:00 /usr/sbin/abrt-dbus -t133
system_u:system_r:xdm_t:s0-s0:c0.c1023  dbus-launch --autolaunch=562c1ca6bb7244098a931fe890f9e2fc --binary-syntax --close-stderr
system_u:system_r:xdm_t:s0-s0:c0.c1023  /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
staff_u:staff_r:staff_t:s0-s0:c0.c1023  dbus-launch --sh-syntax --exit-with-session
staff_u:staff_r:staff_dbusd_t:s0-s0:c0.c1023 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
staff_u:staff_r:staff_dbusd_t:s0-s0:c0.c1023  /bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3

So gdm seems to be working correctly?  Only abrt-dbus is a problem?  Or is this a separate issue?

(In reply to Daniel Walsh from comment #6)
> So gdm seems to be working correctly?  Only abrt-dbus is a problem?  Or is
> this a separate issue?

Yes, this is a separate issue which we have also for setroubleshoot (#1262993).

Thank you for testing. Going to create a policy clone and add fixes to rawhide. 

We will need to have 

# This file is part of systemd.
#
# Used by systemd --user instances.

account  include system-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so nottys open
session  include system-auth

in /etc/pam.d/systemd-user.

http://koji.fedoraproject.org/koji/taskinfo?taskID=11129482

*** Bug 1261602 has been marked as a duplicate of this bug. ***

This should be now fixed in rawhide. Please feel to reopen this bug if not.

Any chance this could be backported to Fedora 23?