Gnome PolicyKit + Keyring + dbus issues [Archive]

View Full Version : Gnome PolicyKit + Keyring + dbus issues

Beeblebrox

March 14th, 2011, 08:58

My Gnome environment has a security issue affecting many other apps. The root of the problem is with the dbus => gnome-keyring interaction. Messages are:
From Dmesg:
polkitd(authority=local): Registered Authentication Agent for unix-session: /org/
freedesktop/ConsoleKit/Session1 (system bus name :1.15 [/usr/local/libexec/polkit-gnome-
authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale )

gnome-keyring-daemon: couldn't allocate secure memory to keep passwords and or
keys from being written to the disk

dbus-daemon: [system] Rejected send message, 2 matched rules; type="method_call",
sender=":1.39" (uid=xxx pid=1710 comm="nautilus ") interface="org.freedesktop.DBus.
Properties" member="GetAll" error name="(unset)" requested_reply=0 destination=":1.2"
(uid=0 pid=1710 comm="/usr/local/sbin/console-kit-daemon --no-daemon "))

seahorse-daemon: init gpgme version 1.3.0
and in other places:
(polkit-gnome-authentication-agent-1:1722): polkit-gnome-1-WARNING **: Error
enumerating temporary authorizations: GDBus.Error:org.freedesktop.PolicyKit1.
Error.Failed: Cannot determine session the caller is in
atk-bridge-WARNING **: AT_SPI_REGISTRY was not started at session startup.
(gnome-settings-daemon:1710): atk-bridge-WARNING **: IOR not set.
Supporting Evidence: Other apps complain in various ways when they are launched as root from terminal emulator:
a. Failed to connect to the session manager: None of the authentication
protocols specified are supported. GLib-GIO:ERROR:gdbusconnection.c:2270:
initable_init: assertion failed: (connection->initialization_error == NULL)

b. cannot connect to the session bus: org.freedesktop.DBus.Error.NoReply:
Did not receive a reply. Possible causes include: the remote application
did not send a reply, the message bus security policy blocked the reply, etc.
c. GDM pitches in with its 2 (or 50) cents:
Window manager warning: meta_window_activate called by a pager with a 0 timestamp;
the pager needs to be fixed.
CurrentTime used to choose focus window; focus window may not be correct.
Got a request to focus the no_focus_window with a timestamp of 0.
This shouldn't happen!

Unfortunately, my google search did not turn up with much relevant answers on the topic. Thanks in advance.

SirDice

March 14th, 2011, 10:38

Are dbus and hal actually running?

Beeblebrox

March 14th, 2011, 11:27

yes, both are running, in rc.conf these (hald, dbus, gdm, gnome) are enable="YES".
Relevant output from ps -ax
Is 0:00.16 /usr/local/bin/dbus-daemon --system
Is 0:00.92 /usr/local/sbin/hald
I 0:00.10 /usr/local/sbin/console-kit-daemon --no-daemon
I 0:00.15 /usr/local/libexec/polkitd
S 0:00.38 /usr/local/libexec/gam_server
I 0:00.03 hald-runner
I 0:00.01 hald-addon-mouse-sysmouse: /dev/psm0 (hald-addon-mouse-sy)
I 0:00.06 /usr/local/libexec/gdm-simple-slave --display-id /org/gnome/Disp
S 1:57.23 /usr/local/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-
I 0:00.00 /usr/local/bin/dbus-launch --exit-with-session
I 0:00.10 /usr/local/libexec/polkit-gnome-authentication-agent-1
I 0:00.02 /usr/local/libexec/gdm-session-worker
I 0:00.04 /usr/local/libexec/upowerd
I 0:00.04 /usr/local/bin/gnome-keyring-daemon --daemonize --login
Is 0:00.27 gnome-session
I 0:00.00 dbus-launch --exit-with-session /usr/local/bin/seahorse-agent --
Is 0:00.37 /usr/local/bin/dbus-daemon --fork --print-pid 5 --print-address
Is 0:00.05 /usr/local/bin/seahorse-agent --execute gnome-session
S 0:00.21 /usr/local/libexec/gvfs-hal-volume-monitor
I 0:00.06 /usr/local/libexec/polkit-gnome-authentication-agent-1

AlexN

March 16th, 2011, 12:41

The same thing on 8.2-release i386. 8.1-stable amd64 looks like works fine. Ports are up to date and upgraded on both systems.

KNOStic

March 18th, 2011, 02:18

I can confirm similar.

When gnome-session is started the old way with dbus-launch, all works well. With ck-launch, it does not. ck-list-sessions shows two sessions, first one has a value of TRUE, second one has a value of FALSE for "active" ...

My guess is that ck-launch is not enabling DBUS properly.

Have overload of work tonight and tomorrow on my end - if this doesn't help trigger some thoughts on the matter, will offer more assistance on Friday night or Saturday but thought my information here might help to properly point the finger.

KNOStic

March 19th, 2011, 06:13

Here's the relevant output from ck-list-sessions

[user@64bit ~]$ ck-list-sessions
Session1:
unix-user = '1001'
realname = 'user'
seat = 'Seat1'
session-type = ''
active = TRUE
x11-display = ':0'
x11-display-device = '/dev/ttyv8'
display-device = ' ? '
remote-host-name = ''
is-local = TRUE
on-since = '2011-03-19T00:55:50.778200Z'
login-session-id = ''
Session2:
unix-user = '1001'
realname = 'user'
seat = 'Seat2'
session-type = ''
active = FALSE
x11-display = ':0'
x11-display-device = '/dev/ttyv8'
display-device = ' ? '
remote-host-name = ''
is-local = FALSE
on-since = '2011-03-19T00:55:51.274081Z'
login-session-id = ''
[user@64bit ~]$

since "active" and "is-local" on the second session are FALSE, I would assume that this is likely to be the reason why gvfs is not automounting to the desktop nor is the shutdown option appearing under "Log out user" on the System dropdown at the top of the menu.

KNOStic

March 19th, 2011, 06:22

Just wanted to also confirm that I have verified and REverified that everything is in compliance with both the latest 2.32 FAQ and the HAL FAQ as far as to configuration.

Beeblebrox

March 20th, 2011, 12:41

My ck-list-sessions gives only 1 user:
unix-user = '1001'
realname = 'some guy'
seat = 'Seat1'
session-type = ''
active = TRUE
x11-display = ':0'
x11-display-device = '/dev/ttyv8'
display-device = ' ? '
remote-host-name = ''
is-local = TRUE
on-since = 'the middle ages'
login-session-id = ''
I suspect that the real problem here is that login-session-id is blank as this is what the error log is telling us. AFAIK this is how gnome security (like seahorse) keeps track of authorisations, somewhat independently from the unix-user id number (??).

There seems to be a partial answer here, but I don't quite get it:
http://lists.freedesktop.org/archives/polkit-devel/2009-December/000285.html

KNOStic

March 22nd, 2011, 06:47

Not sure if this is going to help you, but it did solve my own problem.

First off, I pulled the plug on ck-launch and reverted back to dbus-launch and therefore something definitely is amiss with ck-launch. While this might not be of any help to you, possibly the following WILL be.

I added the following line to the /etc/pam.d/gdm-autologin file:

session optional /usr/local/lib/pam_gnome_keyring.so auto_start

The reason why I looked at replacing dbus-launch with ck-launch in the first place was because startup time for gnome was unacceptably long. However, adding the above now makes the speed of dbus-launch comparable to using ck-launch and so I consider my problem solved, though not the way I would have preferred. And yes, when using dbus-launch, only one seat is listed in ck-list-sessions and it's active as expected.

Beeblebrox

April 3rd, 2011, 21:08

@ KNOStic: Thanks for the input, but as you expected, your mods did not fix the problem on my system.

A large number of gui apps misbehave in the x11/gnome environment and I suspect it is due to this error. Any way I can diagnose the problem? Log files have limited info.

UPDATE: This looks like a bug (?) found on the PC-BSD 9.0 Testing issues page, dated Jan 27 2011: http://lists.pcbsd.org/pipermail/testing/2011-January/004923.html
gnome-keyring-daemon[2521]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk.

Not sure if this a FreeBSD bug with gnome-keyring-daemon, its just the standard port build, and can't find any additional information on why this warning is thrown.

Beeblebrox

June 14th, 2011, 13:20

Some more goooogleing regarding this issue and I have come accross several reported cases that this is an mlock problem; does not play nice with gnome-keyring-daemon. Various quotes:
gnome-keyring-daemon calls mlock to make the memory not swapped out of memory, but by default, Solaris users don't have this priviledge. You can add the following line into /etc/security/exec_attr: Basic Solaris
User:solaris:cmd:::/usr/bin/gnome-keyring-daemon:privs=proc_lock_memory
This error will always be seen since FreeBSD's mlock() requires setuid privileges, and g-k-d cannot run as setuid
Thoughts anyone?

cpu82

January 5th, 2012, 21:13

Same problem here http://www.daemonforums.org/showthread.php?p=4395

its not running as root. you could make the program suid but IMO making a program suid thats not been carefully written and audited is a greater risk than someone reading sensitive info paged out to disk.
i would suggest that you ignore the error messages and if it bugs you too much you could disable it via syslog.conf. if you still have any doubts then write to the port maintainer.

You can disable console notification. Remove the line:

#*.err;kern.debug;auth.notice;mail.crit /dev/console
from /etc/syslog.conf

OR redirect it to a file:

*.err;kern.debug;auth.notice;mail.crit /var/log/console.log

mzettler

January 7th, 2012, 20:05

I see the same error messages as Beeblebrox. I'm not sure whether this is related, but in my case I can't use sftp with nautilus. (thread "nautilus and ssh problem (http://forums.freebsd.org/showthread.php?t=28687)").

Is there any ideas how to debug this or solution yet, since in my eyes this looks more like a general problem?

Beeblebrox

January 8th, 2012, 23:16

Although I have not as yet tried this solution, I think it should work. It is shown by Gnome its self and is described as an integration of Keyring with PAM:
http://live.gnome.org/GnomeKeyring/Pam

mzettler

January 9th, 2012, 22:29

I just had a short look at it and I did not find any differences between my pam.d/gdm file (default after gdm install) and the one described in the gnome tutorial. However error messages are still present.

cpu82

January 10th, 2012, 00:24

mzettler

January 10th, 2012, 08:58

I did not change anything on my files. They are the default files, originating from installing gdm.

Beeblebrox

January 10th, 2012, 12:26

I tried the solution in the link but it did not work for me either; so no change.

1. The pam tests work if you run them in their relevant folders:
cd /usr/local/lib && grep -rq pam_gnome_keyring.so
cd ~ && test -f ~/.gnome2/keyrings/login.keyring

2. FreeBSD does not have the file /etc/pam.d/gdm. If you try to create one, pam re-names it to gdm_disabled. But there is a file xdm. so I placed these in /etc/pam.d/xdm:
auth optional pam_gnome_keyring.so
session optional pam_gnome_keyring.so auto_start
@ mzettler: For ssh look at the end of the page http://live.gnome.org/GnomeKeyring/Pam/Manual. The page also has a link to gnome-keyring ssh.
Gnome Keyring implements its own SSH agent, therefore you should not stack it with pam_ssh for session management

mzettler

January 10th, 2012, 20:54

2. FreeBSD does not have the file /etc/pam.d/gdm.

I've found it under /usr/local/etc/pam.d/gdm

For ssh look at the end of the page http://live.gnome.org/GnomeKeyring/Pam/Manual. The page also has a link to gnome-keyring ssh.

Thanks for the hint. I disabled ssh-agent support for gnome-keyring, but it did not change a thing.

cpu82

January 11th, 2012, 00:05

You can "setuid root" with these two commands:

# chown root /usr/local/bin/gnome-keyring-daemon
# chmod u+s /usr/local/bin/gnome-keyring-daemon

The first command makes root the "owner" of the gnome-keyring-daemon binary (in case root didn’t already have ownership of the file). The second makes the program run with the privileges of its "owner" no matter who started it up.

Remember that "setuid root" is bad for security purposes.