Bug 684846 - selinux denial prevents dbus activation of gnome-keyring-daemon
selinux denial prevents dbus activation of gnome-keyring-daemon
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gnome-keyring (Show other bugs)
15
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tomáš Bžatek
Fedora Extras Quality Assurance
AcceptedBlocker
:
: 701312 (view as bug list)
Depends On:
Blocks: F15Blocker-kde
  Show dependency treegraph
 
Reported: 2011-03-14 12:18 EDT by Rex Dieter
Modified: 2015-03-03 17:58 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-06 14:48:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 644918 None None None Never

  None (edit)
Description Rex Dieter 2011-03-14 12:18:12 EDT
Testing F15-alpha, with both gnome, kde installed.  Up-to-date as of Mar 14, cannot get any gnome-keyring-using app to save stuff on kde.

Testing nm-applet, for example, I see console error output:

** Message: secret service operation failed: Failed to execute program /usr/bin/gnome-keyring-daemon: Success

over and over, abrt-gui also has

Can't connect to gnome-keyring-daemon, changes won't be saved.

Ah, looking into
/etc/xdg/autostart/gnome-keyring-secrets.desktop
has
OnlyShowIn=GNOME;LXDE;XFCE;

Is there some purposeful reason to not include KDE here?
Comment 1 Rex Dieter 2011-03-14 12:24:05 EDT
Tested modifying gnome-keyring-secrets.desktop to not exclude KDE makes it work

Not sure how the other gnome-keyring autostart items:
gnome-keying-gpg
gnome-keying-pkcs11
gnome-keying-ssh
may play a similar role in reduced functionality of apps run on KDE.

Any comment or advice wrt these latter items would be appreciated as well.
Comment 2 Tomáš Bžatek 2011-03-14 12:36:54 EDT
I remember when we did the same thing for XFCE. IMHO the autostart condition should be removed altogether. Will discuss upstream.

https://bugzilla.gnome.org/show_bug.cgi?id=644305
https://bugzilla.gnome.org/show_bug.cgi?id=610715 (although this was a slightly different issue)
Comment 3 Rex Dieter 2011-03-14 12:48:37 EDT
I would tend to agree wrt autostart condition (or at worst, use NotShowIn for exceptions)
Comment 4 Adam Williamson 2011-04-15 15:29:00 EDT
Discussed at 2011-04-15 blocker review meeting. Accepted as a blocker per criterion "# Saving passwords in the desktop default keyring (if the desktop implements one), and retrieving passwords from the keyring, must work " (it's a slight stretch as gnome-keyring isn't KDE's default keyring manager, but it's often used in KDE and some apps won't use KDE's keyring manager, we think).

We suspect this may be fixed already; can someone check?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 5 Kevin Kofler 2011-04-15 16:02:25 EDT
So in a cursory look, I don't see any change which would fix this, but I also haven't done any testing to reproduce it.

The upstream bug (which specifically requested the daemon to be set to autostart on login) got closed as NOTABUG, saying that gnome-keyring should be getting started through D-Bus activation in KDE. So it seems that the real bug is that this is (was?) not working.
Comment 6 Kevin Kofler 2011-04-15 16:04:14 EDT
(The idea is that KDE users might not need gnome-keyring running at all, depending on the applications they use. With D-Bus activation, it will get started automatically when something needs it.)
Comment 7 Adam Williamson 2011-04-18 12:21:16 EDT
rex: can you try this with beta and see how it is at present?
Comment 8 Rex Dieter 2011-04-18 12:36:44 EDT
Can confirm problem with my current (as of today, apr 18) f15/x86_64 laptop, trying to run abrt-gui on kde, I get an error dialog:
"Cannot connect to gnome keyring daemon"
(added similar comment on upstream bug too)

(I can try too with a f15-beta live image if you insist though...)
Comment 9 Rex Dieter 2011-04-18 12:59:03 EDT
debugging with stefw on #keyring @ irc.gimp.net:

[04/18/11 11:46] <rdieter> stefw: ping, hi, Rex here from https://bugzilla.gnome.org/show_bug.cgi?id=644918
[04/18/11 11:46] <stefw> hey rdieter
[04/18/11 11:46] <stefw> i'm sure you have dbus activation running and all?
[04/18/11 11:47] <stefw> does abrt-gui use libgnome-keyring?
[04/18/11 11:47] <stefw> ldd /path/to/abrt-gui
[04/18/11 11:47] <rdieter> unsure, actually.
[04/18/11 11:47] <stefw> would be a pretty good indication
[04/18/11 11:47] <rdieter> lemme see
[04/18/11 11:47] <rdieter> looks like it indeed does link against libgnome-keyring
[04/18/11 11:47] <stefw> okay, that takes away one variable
[04/18/11 11:48] <stefw> and it's probably libgnome-keyring 3.0.x or something like that.
[04/18/11 11:48] <rdieter> though I could use a different app to test
[04/18/11 11:48] <rdieter> libgnome-keyring-3.0.0-1.fc15 it is
[04/18/11 11:48] <stefw> righto.
[04/18/11 11:48] <stefw> so i assume gnome-keyring-daemon isn't running when you log into kde right?
[04/18/11 11:49] <rdieter> correct
[04/18/11 11:49] * rdieter still sees a bunch of keyring-related items in /etc/xdg/autostart too
[04/18/11 11:49] <stefw> and what does this tell you
[04/18/11 11:49] <stefw> grep -R org.freedesktop.secrets /usr/share/dbus-1/services/
[04/18/11 11:50] <rdieter> org.freedesktop.secrets.service (owned by gnome-keyring-3.0.0)
[04/18/11 11:51] <stefw> okay, so kwalletd has a secret service implementation too, but it doesn't seem to be deployed yet... at least not on fedora.
[04/18/11 11:51] <rdieter> anyway, the grep output is:  org.freedesktop.secrets.service:Name=org.freedesktop.secrets
[04/18/11 11:51] <stefw> right on
[04/18/11 11:52] <stefw> any messages in /var/log/auth.log after 'Cannot connect to Gnome keyring daemon'
[04/18/11 11:52] <stefw> btw, that message looks wierd, did you copy it into the bug report verbatim?
[04/18/11 11:53] <rdieter> yes, though I transcribed it from another box, so may have a typo
[04/18/11 11:53] <rdieter> my box has no /var/log/auth.log  , I'll try grepping everything there
[04/18/11 11:55] <rdieter> ah, here we go
[04/18/11 11:55] <stefw> gnome-keyring-daemon logs to syslog 'auth' facility
[04/18/11 11:56] <rdieter> localhost gnome-keyring-daemon[28643]: couldn't connect to dbus session bus: An SELinux policy prevents this sender from sending this message to this recipient (rejected message had sender "(unset)" interface "org.freedesktop.DBus" member "Hello" error name "(unset)" destination "org.freedesktop.DBus")
[04/18/11 11:56] <rdieter> so looks like an selinux thing perhaps
[04/18/11 11:56] <stefw> grumble.
[04/18/11 11:56] <stefw> i guess file a bug at bugzilla.redhat.com
[04/18/11 11:57] <stefw> sorry that you're getting the run around :/
[04/18/11 11:57] <rdieter> k (though I'm in permissive mode at the moment, that logged message should be purely informative, not actually blocking anything)
[04/18/11 11:57] <rdieter> back to bz.rh.com
[04/18/11 11:57] <stefw> this isn't informative: "couldn't connect to dbus session"
[04/18/11 11:57] <stefw> it's gnome-keyring-daemon complaining
[04/18/11 11:58] <stefw> i mean it's an actual error
Comment 10 Rex Dieter 2011-04-18 12:59:50 EDT
Anyway, the Cliff's notes version of that dialog is that it would appear there's some selinux mojo possibly blocking the dbus activation of this service.
Comment 11 Adam Williamson 2011-04-18 13:09:07 EDT
you can try booting with selinux=0 to force selinux entirely off (though it'll require a relabel at the next boot with it turned on), just to identify for sure if it's selinux we're running into here.
Comment 12 Rex Dieter 2011-04-18 13:17:24 EDT
Yup, looks like we have a winner now, booting with selinux=0, things get further and gnome-keyring-daemon activates...

though I do have in /var/log/messages:
gnome-keyring-daemon[1399]: couldn't set environment variable in session: The name .org.gnome.SessionManager was not provided by any .service files
(though that's not surprising)
Comment 13 Adam Williamson 2011-04-18 13:38:02 EDT
so, let's re-assign.
Comment 14 Daniel Walsh 2011-04-18 15:23:21 EDT
What avc's are you seeing?
Comment 15 Rex Dieter 2011-04-18 15:42:24 EDT
long relabel later, these seem to be the relevant snippets from /var/log/audit/audit.log:

type=SELINUX_ERR msg=audit(1303155816.203:55): security_compute_sid:  invalid context unconfined_u:unconfined_r:staff_gkeyringd_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gkeyringd_exec_t:s0 tclass=process
type=SYSCALL msg=audit(1303155816.203:55): arch=c000003e syscall=59 success=yes exit=0 a0=7f39cc539cc0 a1=7f39cc539c20 a2=7f39cc5be1d0 a3=7fffb5f3d560 items=0 ppid=1928 pid=1929 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gnome-keyring-d" exe="/usr/bin/gnome-keyring-daemon" subj=unconfined_u:unconfined_r:staff_gkeyringd_t:s0-s0:c0.c1023 key=(null)
Comment 16 Daniel Walsh 2011-04-18 15:47:38 EDT
Rex were you playing with confined users?
Comment 17 Rex Dieter 2011-04-18 15:54:37 EDT
not to my knowledge
Comment 18 Daniel Walsh 2011-04-18 16:59:31 EDT
Very strange to have a staff_gkeyringd_t?

This would not have caused the system to not boot though.  Since this would happen at login time.
Comment 19 Adam Williamson 2011-04-18 18:52:53 EDT
"This would not have caused the system to not boot though.  Since this would
happen at login time."

No, it doesn't, that's not a reported symptom anywhere in the bug AFAICS. It's simply as described - gnome-keyring-daemon should get dbus activated when something tries to use it from within KDE, but doesn't (for Rex, at least).

Rex, could you test with the Beta RC2 live image to discount any local config issues? Thanks!
Comment 20 Daniel Walsh 2011-04-19 11:14:54 EDT
Sorry I misread.


We added some fixes to execute the keyring from the pam stack with the correct context.  I am trying to remember what we did, and maybe this is working differently from the gdm to kdm.
Comment 21 Kevin Kofler 2011-04-19 11:27:42 EDT
It's getting activated through D-Bus here, I think we need a policy for that.
Comment 22 Peter Lemenkov 2011-04-20 04:31:18 EDT
The same for me:

[   69.769305] type=1401 audit(1303287861.129:6): security_compute_sid:  invalid context unconfined_u:unconfined_r:staff_gkeyringd_t:s0 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0 tcontext=system_u:object_r:gkeyringd_exec_t:s0 tclass=process
Comment 23 Daniel Walsh 2011-04-20 11:14:10 EDT
The problem is staff_gkeyringd_t is the wrong context.  It should be unconfined_gkeyringd_t or just unconfined_t.

This context should only happen with a staff_t user.
Comment 24 Daniel Walsh 2011-04-20 11:34:58 EDT
I believe this is being caused by.

https://bugzilla.redhat.com/attachment.cgi?id=485554
Comment 25 Daniel Walsh 2011-04-20 12:04:46 EDT
When you log in what does

id -Z 

Show?
Comment 26 Tomáš Bžatek 2011-04-20 12:11:48 EDT
There are two things here.

According to http://live.gnome.org/GnomeKeyring/RunningDaemon, gnome-keyring-daemon must be initialized from the session startup. Which is not the case in KDE. I wonder if the pam module initialization takes place with KDM (probably yes) and if there's a hanging process waiting for initialization. 

In case there isn't any, gnome-keyring-daemon is autospawned from d-bus, trying to switch the context from unconfined_dbusd_t.

In Gnome, gnome-keyring-daemon is autostarted by desktop session, running under standard user desktop context (most probably). D-bus is not involved here.
Comment 27 Rex Dieter 2011-04-20 12:13:34 EDT
$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Comment 28 Daniel Walsh 2011-04-20 12:50:41 EDT
I got to believe this is caused by someone calling pam_gnome_keyring.   Does this get called in kde?  Not in the stack?

The standard transition unconfined_dbusd_t execs gnome-keyringd-daemon should trasition properly.  The problem we were seeing was gnome-keyring-daemon launched out of pam_gnome_keyring was being executed as staff_t, which caused other stuff to  blow up.


When you log in in permissive mode what context is the keyring running under.

ps -eZ | grep gnome-keyring
Comment 29 Kevin Kofler 2011-04-29 13:18:27 EDT
pam_gnome_keyring might be run from KDM.

(Setting needinfo on rdieter because there's a question for him in comment #28.)
Comment 30 Rex Dieter 2011-04-29 13:48:30 EDT
$ grep keyring /etc/pam.d/kdm
auth     optional  pam_gnome_keyring.so
session  optional  pam_gnome_keyring.so auto_start

(pretty much the same as f14)

$ abrt-gui
(try to configure bugzilla plugin)
** Message: secret service operation failed: Failed to execute program /usr/bin/gnome-keyring-daemon: Success
Can't connect to gnome-keyring-daemon, changes won't be saved.

# setenforce 0

$ abrt-gui
(same)
** Message: couldn't connect to dbus session bus
Can't connect to gnome-keyring-daemon

$ ps aux | grep gnome-keyring | grep -v grep
(nothing)

# grep ri keyring /var/log/*
...
/var/log/audit/audit.log:type=SELINUX_ERR msg=audit(1304098755.120:52): security_compute_sid:  invalid context undefined_u:unconfined_r:staff_gkeyringd_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=system.u:object_r:gkeyringd_exec_t:s0 tclass=process

lots of these, same whether selinux enforcing or not.
Comment 31 Daniel Walsh 2011-04-29 13:57:26 EDT
Are more info.  This is the abrt-gui doing this?   Why is the abrt-gui running a pam stack?
Comment 32 Daniel Walsh 2011-04-29 13:57:52 EDT
I have a feeling consolehelper is rearing its ugly head?
Comment 33 Rex Dieter 2011-04-29 14:13:33 EDT
I don't think consolehelper is involved here

I'll try to get a full vm installed here, and find some other gnome-keyring-using app to gather more data
Comment 34 Rex Dieter 2011-04-29 14:29:14 EDT
OK, reproducible with seahorse too.

#
type=SELINUX_ERR msg=audit(1304101539.188:73): security_compute_sid: invalid context unconfined_u:unconfined_r:staff_gkeyringd_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gkeyringd_exec_t:s0 tclass=process
#
type=SYSCALL msg=audit(1304101539.188:73): arch=c000003e syscall=59 success=no exit=-13 a0=7f40cc6ea730 a1=7f40cc761380 a2=7f40cc743c80 a3=7fff3747ec10 items=0 ppid=2400 pid=2401 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="dbus-daemon" exe="/bin/dbus-daemon" subj=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 key=(null)
#
type=SELINUX_ERR msg=audit(1304101539.228:74): security_compute_sid: invalid context unconfined_u:unconfined_r:staff_gkeyringd_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gkeyringd_exec_t:s0 tclass=process
#
type=SYSCALL msg=audit(1304101539.228:74): arch=c000003e syscall=59 success=no exit=-13 a0=7f40cc6ee280 a1=7f40cc761380 a2=7f40cc743c80 a3=7fff3747ec10 items=0 ppid=2402 pid=2403 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="dbus-daemon" exe="/bin/dbus-daemon" subj=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 key=(null)


IN permissive mode, now seahorse errors with "couldn't communicate with key ring daemon".  audit.log contains:

#
type=SELINUX_ERR msg=audit(1304101657.790:80): security_compute_sid: invalid context unconfined_u:unconfined_r:staff_gkeyringd_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gkeyringd_exec_t:s0 tclass=process
#
type=SYSCALL msg=audit(1304101657.790:80): arch=c000003e syscall=59 success=yes exit=0 a0=7f40cc6ee240 a1=7f40cc6ed220 a2=7f40cc83db60 a3=7fff3747ec10 items=0 ppid=2469 pid=2470 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gnome-keyring-d" exe="/usr/bin/gnome-keyring-daemon" subj=unconfined_u:unconfined_r:staff_gkeyringd_t:s0-s0:c0.c1023 key=(null)
Comment 35 Daniel Walsh 2011-04-29 14:33:49 EDT
ps -eZ | grep staff
Comment 36 Daniel Walsh 2011-04-29 14:40:50 EDT
Ok I guess I have to setup kde.  Any quick way to update my test message to kde?

yum install kdm konsole\*

Seems to be updating.
Comment 37 Rex Dieter 2011-04-29 14:43:11 EDT
$ ps -eZ | grep staff
(empty)
Comment 38 Rex Dieter 2011-04-29 14:44:41 EDT
To install a minimal test environment you probably want (at least):

yum install kdm kdebase-workspace

(though theoretically could skip kdm, though that may be relevant for testing here).  and to use kdm set
/etc/sysconfig/desktop
to include
DISPLAYMANAGER="KDE"
Comment 39 James Laska 2011-04-29 14:49:32 EDT
Discussed at 2011-04-29 blocker review meeting (http://meetbot.fedoraproject.org/fedora-bugzappers/2011-04-29/f15-blocker-review.2011-04-29-17.00.html).  Adamw was going to reach out to Rex for how to proceed, but it appears this bug is moving again.

Be advised the Final TC1 compose is on Monday, 2011-05-02.  Also, the Final RC compose is on Tuesday, 2011-05-10.

http://rbergero.fedorapeople.org/schedules/f-15/f-15-releng-tasks.html
Comment 40 Rex Dieter 2011-04-29 14:58:00 EDT
Confirmed same problem using gdm + kde login, so that *may* rule out anything DM-related.
Comment 41 Rex Dieter 2011-04-29 15:00:54 EDT
and, reconfirmed issue remains after installing all of updates-testing (2011-04-29)
Comment 42 Daniel Walsh 2011-04-29 19:04:23 EDT
Try selinux-policy-3.9.16-19.fc15
Comment 43 Rex Dieter 2011-05-03 14:02:22 EDT
Tested with selinux-policy-3.9.16-21.fc15 , seems A-OK now.
Comment 44 Daniel Walsh 2011-05-03 14:41:32 EDT
Rex, Thanks for helping me diagnose this problem.  (And kicking me in the ass to actually fix it.)
Comment 45 Brian Pepple 2011-05-05 15:44:11 EDT
*** Bug 701312 has been marked as a duplicate of this bug. ***
Comment 46 Adam Williamson 2011-05-06 14:48:26 EDT
The fixed selinux-policy has gone stable, so closing. (I also confirmed this fix.)



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

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