Gnome PolicyKit + Keyring + dbus issues

Beeblebrox · #1 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:

Code:

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:

Code:

(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

Code:

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:

Code:

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:

Code:

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** · #2 March 14th, 2011, 10:38

Are dbus and hal actually running?

Beeblebrox · #3 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

Code:

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 · #4 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 · #5 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 · #6 March 19th, 2011, 06:13

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

Code:

[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 · #7 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 · #8 March 20th, 2011, 12:41

My ck-list-sessions gives only 1 user:

Code:

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/archive...er/000285.html

KNOStic · #9 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:

Code:

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 · #10 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/tes...ry/004923.html

Quote:

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 · #11 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:

Quote:

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

Quote:

This error will always be seen since FreeBSD's mlock() requires setuid privileges, and g-k-d cannot run as setuid

Thoughts anyone?

cpu82 · #12 January 5th, 2012, 21:13

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

Quote:

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:

Code:

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

OR redirect it to a file:

Code:

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

mzettler · #13 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").

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

Beeblebrox · #14 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 · #15 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 · #16 January 10th, 2012, 00:24

Quote:

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.

Post files you edited

mzettler · #17 January 10th, 2012, 08:58

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

Beeblebrox · #18 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:

Code:

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.

Quote:

Gnome Keyring implements its own SSH agent, therefore you should not stack it with pam_ssh for session management

mzettler · #19 January 10th, 2012, 20:54

Quote:

Originally Posted by Beeblebrox

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

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

Quote:

Originally Posted by Beeblebrox

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 · #20 January 11th, 2012, 00:05

You can "setuid root" with these two commands:

Code:

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

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
keyring for the command line?	feralape	Installation and Maintenance of FreeBSD Ports or Packages	3	July 30th, 2010 21:13
[Solved] FreeBSD 8.0 i386 KDE and GNOME issues	bpappan	X.Org	11	January 29th, 2010 10:14
[Solved] gnome-session reports libpolkit-dbus.so.2 not found	shrikanth07	GNOME	4	July 24th, 2009 17:16
Gnome Issues and Possibly X issues	haibane	X.Org	61	June 8th, 2009 17:47
gnome-keyring	lumiwa	Installing & Upgrading	1	January 19th, 2009 03:15