Bug 1263350 - systemd user sessions running with the wrong context.
systemd user sessions running with the wrong context.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
24
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Lukas Vrabec
Fedora Extras Quality Assurance
:
Depends On: 1262933
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-15 11:34 EDT by Miroslav Grepl
Modified: 2016-12-06 12:03 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1262933
Environment:
Last Closed: 2016-12-06 12:03:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Miroslav Grepl 2015-09-15 11:34:08 EDT
+++ This bug was initially created as a clone of Bug #1262933 +++

The mechanism for launching user sessions via dbus has changed in rawhide, which is causing apps to run as unconfined_service_t

--- Additional comment from Daniel Walsh on 2015-09-14 12:24:24 EDT ---

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@redhat.com 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.

--- Additional comment from Miroslav Grepl on 2015-09-14 14:29:35 EDT ---

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.

--- Additional comment from Miroslav Grepl on 2015-09-14 14:31:18 EDT ---

(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.

--- Additional comment from Miroslav Grepl on 2015-09-15 02:23:02 EDT ---

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.

--- Additional comment from Petr Lautrbach on 2015-09-15 04:35:58 EDT ---

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

--- Additional comment from Daniel Walsh on 2015-09-15 09:23:55 EDT ---

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

--- Additional comment from Miroslav Grepl on 2015-09-15 11:31:52 EDT ---

(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.
Comment 1 Jan Kurik 2016-02-24 10:31:02 EST
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Comment 2 Fedora Admin XMLRPC Client 2016-09-27 11:13:17 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 3 Robin Powell 2016-12-04 04:18:06 EST
I can't tell if this is related or not, but systemd --user is utterly failing for me on both my F24 and Rawhide systems unless selinux is unenforcing.

If I do this:

sudo systemctl restart user@1000.service

I get:


type=AVC msg=audit(1480842972.704:1769): avc:  denied  { write } for  pid=10222 comm="systemd" name="user@1000.service" dev="cgroup" ino=371 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1480842972.704:1770): avc:  denied  { remove_name } for  pid=10222 comm="systemd" name="dbus.socket" dev="cgroup" ino=499 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1480842972.704:1771): avc:  denied  { rmdir } for  pid=10222 comm="systemd" name="dbus.socket" dev="cgroup" ino=499 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1480842972.704:1772): avc:  denied  { add_name } for  pid=10222 comm="systemd" name="systemd-exit.service" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1480842972.704:1773): avc:  denied  { create } for  pid=10222 comm="systemd" name="systemd-exit.service" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:cgroup_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1480842972.814:1779): avc:  denied  { ioctl } for  pid=10521 comm="systemd" path="socket:[79663]" dev="sockfs" ino=79663 ioctlcmd=0x5401 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket permissive=1
type=AVC msg=audit(1480842972.849:1780): avc:  denied  { write } for  pid=10521 comm="systemd" name="user@1000.service" dev="cgroup" ino=371 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1480842972.849:1781): avc:  denied  { add_name } for  pid=10521 comm="systemd" name="dbus.socket" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1480842972.849:1782): avc:  denied  { create } for  pid=10521 comm="systemd" name="dbus.socket" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:cgroup_t:s0 tclass=dir permissive=1

Not having user-level systemd is pretty bad, so please let me know if I should open another ticket, or anything else I can do to help.
Comment 4 Lukas Vrabec 2016-12-06 12:03:37 EST
This is another bug. You opened one issue for this. We'll discuss it there.

Note You need to log in before you can comment on or make changes to this bug.