run as different user fails (wrong ownership of .Xauthority and /tmp/libgksu-xxx)

Bug #275304 reported by Peter Cordes on 2008-09-27
36
This bug affects 5 people
Affects Status Importance Assigned to Milestone
gksu (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: gksu

peter@whale:~$ gksudo xterm

root@whale:/home/peter# ll $XAUTHORITY
-rw------- 1 peter peter 150 2008-09-27 20:20 /tmp/libgksu-3t0ebS/.Xauthority

 The directory is also owned by the user who ran gksudo, so they could modify .Xauthority during the gksudo session.

 This isn't really a security problem, because anyone who runs gksudo is root-equivalent in the first place. An attacker gaining access to their account could do lots of things besides try to exploit root X processes by writing to their .Xauthority. e.g. capture user's password and sudo themselves.

 The problem this does cause is that gksudo only works for sudo-to-root. gksudo -u other-user xterm fails, because xterm can't open .Xauthority, because it doesn't have read permission on it or even exec permission on the dir it's in.

Peter Cordes (peter-cordes) wrote :

sorry, this is on an updated Intrepid i386 with
gksu 2.0.0-5ubuntu3
libgksu2-0 2.0.7-1ubuntu2

nglnx (nglnx) wrote :

Confirming this. Trying to run an application as another (non-root) user

gksudo -u anotherusername

fails due to the way gksudo sets permissions

* on the file

-rw------- 1 originaluser originaluser 123 2009-03-05 01:44 .Xauthority

* and on the directory:

drwx------ 2 originaluser originaluser 4096 2009-03-05 01:30 libgksu-abcde

The description of this package says:

"...It is useful to menu items or other graphical programs that need to ask a user's password to run another program as another user..."

So it should be reasonable to expect that this package would work to execute a program as a another "non root user".

Changed in gksu:
status: New → Confirmed
Changed in gksu (Ubuntu):
importance: Undecided → Low
ceg (ceg) wrote :

This may help tracking down this bug:

The ownership is set correctly when using the the "su" method (by calling the "gksu" binary directly instead of of through the "gksudo" symlink AND with the -w option).

This fails:

$ gksudo -u firefoxuser firefox
No protocol specifiedNo protocol specified
Error: cannot open display: :0.0

The following works inspite of the warnings, however the password of the target user is allways required and you can not make use of the NOPASSWORD option in the sudoers file with that.

$ gksu -w -u firefoxuser firefox

(firefox:3439): GnomeUI-WARNING **: While connecting to session manager:
None of the authentication protocols specified are supported.

(firefox:3439): GnomeUI-WARNING **: While connecting to session manager:
None of the authentication protocols specified are supported.

(firefox:3439): GnomeUI-WARNING **: While connecting to session manager:
None of the authentication protocols specified are supported.

---

It's quite a security shame that ubuntu ships without fully working "running as different user" mechanisms for so long.

Peter Cordes (peter-cordes) wrote :

(way off topic...)

> It's quite a security shame that ubuntu ships without fully working "running as different user" mechanisms for so long.

 I wouldn't give un-trusted programs access to my X display. X isn't secure like that! When I run p2p filesharing programs (complex and crash-prone programs written in C, specifically designed to connect to many untrusted peers... What could possibly be wrong with that?) I run them as a different user (that doesn't have sudo privs, among other things), displaying on a Xvnc. I even have a startxvnc.sh script that starts xvnc, starts fluxbox on it, starts mrxvt, and injects commands into the mrxvt (via its --useFifo option), so it's like I interactively started things from the shell in the mrxvt. Or, most usefully, from an interactive gdb in the shell in the mrxvt, so I can thread apply all bt full when the program eventually crashes.

 I've thought about using apparmor to restrict p2p programs, but they're written to be able to upgrade themselves, so they need write access to their own binaries, and of course access to an X display. (using Xvnc makes it detachable/re-attachable after restarting my desktop, like screen(1) is for programs in a terminal window.)

ceg (ceg) wrote :

Thank you for the hints Peter. Which vnc packages did you install?

So regading the fix for running apps as different user, it should probably make use of xnest or Xephyr?

ceg (ceg) wrote :

Fedora's "sandbox -X" seems to be made for this.

summary: - wrong ownership of .Xauthority and /tmp/libgksu-xxx
+ run as different user fails (wrong ownership of .Xauthority and /tmp
+ /libgksu-xxx)
ceg (ceg) wrote :

The following wikipage contains valuable information about working with different user accounts
https://wiki.ubuntu.com/MultiUserManagement

Marcus (marcus-liljedahl) wrote :

Any progress on this bug?

Marcus (marcus-liljedahl) wrote :

I made a small program that solves this problem.

Schuft (schuft69) wrote :

@ Markus: Script works very well! Thanks!

AZ (m-dev) wrote :

Still present with xenial

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments