Xorg without root rights

[Fred]

The X.Org Server is a large piece of software which currently runs as root, making it a potential vector for attacks against the system. With recent changes made to systemd-logind it is possible for the xserver to let systemd-logind do device management for it, at which point the xserver will no longer need root rights. Initially this will likely be implemented as the xserver dropping root rights early on.

[Jaroslav (jaroslav-redhat-bugs)]

This is a tracking bug for Change: Xorg without root rights
For more details, see: http://fedoraproject.org//wiki/Changes/XorgWithoutRootRights

The Xorg xserver is a large piece of software which currently runs as root, making it a potential vector for attacks against the system. With recent changes made to systemd-logind it is possible for the xserver to let systemd-logind do device management for it, at which point the xserver will no longer need root rights. Initially this will likely be implemented as the xserver dropping root rights early on.

[Jaroslav (jaroslav-redhat-bugs)]

This message is a reminder that Fedora 21 Accepted Changes Freeze Deadline is on 2014-07-08 [1].

At this point, all accepted Changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be so enabled at Change Freeze.

This bug should be set to the MODIFIED state to indicate that it achieved completeness. Status will be provided to FESCo right after the deadline. If, for any reasons, your Change is not in required state, let me know and we will try to find solution. For Changes you decide to cancel/move to the next release, please use the NEW status and set needinfo on me and it will be acted upon.

In case of any questions, don't hesitate to ask Wrangler (jreznik). Thank you.

[1] https://fedoraproject.org/wiki/Releases/21/Schedule

[Hans (hans-redhat-bugs)]

Hi,

Not sure what to do with this bug, all the necessary Xorg bits have long landed, but the only way to run the Xserver as non-root atm is through startx from a text console, as all the display-managers are not ready yet. It might be best to move this to F-22 from a feature pov.

Regards,

Hans

[Jaroslav (jaroslav-redhat-bugs)]

Hi,
thank you for reply. From a feature and (probably even more) from users pov, it makes sense to move it to Fedora 22. I'll make sure all places are correctly updated to reflect it.

[Andrew (andrew-redhat-bugs)]

Is it possible to leave it for F-21 with startx only? I know I'm a minority here, but that's the way I use. Being done this way it might help to test Xorg in this mode before enabling it for a broader audience.

[Hans (hans-redhat-bugs)]

(In reply to Andrew Travneff from comment #4)
> Is it possible to leave it for F-21 with startx only? I know I'm a minority
> here, but that's the way I use. Being done this way it might help to test
> Xorg in this mode before enabling it for a broader audience.

For use with startx it requires a tiny bit of manual configuration (because otherwise various dm-s would be broken), see: http://hansdegoede.livejournal.com/14446.html

Other then that all the necessary functionality is there, and there is no intention to remove it.

[Andrew (andrew-redhat-bugs)]

Wow, thanks! Just in case, is it planned to make the same thing available for F-20?

[Hans (hans-redhat-bugs)]

(In reply to Andrew Travneff from comment #6)
> Wow, thanks! Just in case, is it planned to make the same thing available
> for F-20?

No.

[Petr (petr-redhat-bugs)]

Change moved to F22, so I'm setting the relnotes flag to - for F21.

[Andrew (andrew-redhat-bugs)]

Created attachment 972965
Xorg log failing with needs_root_rights = auto

Tried it on F21, unsuccessfully.
xorg log tells this:

> Fatal server error: xf86OpenConsole: VT_ACTIVATE failed: Operation not permitted

$ ll /etc/X11/Xwrapper.config
-rw-r--r--. 1 root root 25 Dec 24 20:13 /etc/X11/Xwrapper.config

$ cat /etc/X11/Xwrapper.config
needs_root_rights = auto

Selinux mode: permissive

$ rpm -qa \*xorg\*
xorg-x11-drv-fbdev-0.4.3-19.fc21.x86_64
xorg-x11-drv-modesetting-0.9.0-2.fc21.x86_64
xorg-x11-xkb-utils-7.7-12.fc21.x86_64
xorg-x11-xauth-1.0.9-2.fc21.x86_64
xorg-x11-font-utils-7.5-25.fc21.x86_64
xorg-x11-xinit-1.3.4-2.fc21.x86_64
xorg-x11-drv-evdev-2.9.0-3.fc21.x86_64
xorg-x11-drv-synaptics-1.8.0-9.fc21.x86_64
xorg-x11-server-common-1.16.2.901-1.fc21.x86_64
xorg-x11-fonts-ISO8859-1-100dpi-7.5-14.fc21.noarch
xorg-x11-fonts-Type1-7.5-14.fc21.noarch
xorg-x11-drv-vesa-2.3.2-19.fc21.x86_64
xorg-x11-drv-intel-2.99.916-3.20141117.fc21.x86_64
xorg-x11-utils-7.5-16.fc21.x86_64
xorg-x11-server-utils-7.7-10.fc21.x86_64
xorg-x11-server-Xorg-1.16.2.901-1.fc21.x86_64

[Hans (hans-redhat-bugs)]

Hi,

(In reply to Andrew Travneff from comment #9)
> Created attachment 972965 [details]
> Xorg log failing with needs_root_rights = auto

How are you starting X ? Unless you're using startx from a text console this failure is expected to happen since most display managers do not start the Xserver in a properly setup session (such as logging into a text console will give you), and without a proper session X cannot talk to systemd-logind.

Which is why we're carrying this patch:

http://pkgs.fedoraproject.org/cgit/xorg-x11-server.git/tree/0001-Fedora-hack-Make-the-suid-root-wrapper-always-start-.patch

And why the "Xorg without root rights" feature has been pushed back to F-22. With your custom
Xwrapper.config you're overriding the default selected by that patch, causing the problem you are seeing.

Regards,

Hans

[Andrew (andrew-redhat-bugs)]

Thank you. I think it corresponds with my understanding. I launch startx[1] on tty1 with no X running. Will try to make more convincing proof today.

1: more precisely, it is:
startx -- -verbose 7 -logverbose 7 &> /var/tmp/my_xorg.log

[Andrew (andrew-redhat-bugs)]

Just in case: I think I have no DM installed.
startx from a text console is my usual workflow.

[Andrew (andrew-redhat-bugs)]

Created attachment 973072
Test script output for a failed launch

OK, more details here. Created a test script[1] and executed following:

a. Logout from X. It was launched by startx, so logoff switches me to the text console.

b. Move Xwrapper.config to its place.

c. Run the test script: ". /tmp/xtest"

Output is attached. Just inserted some empty lines for easier reading.
Note additional errors (actually warnings) about KDSETMODE and VT_SETMODE.
Similar Xorg.0.log attached above.

1:
{ tty
PS_FORMAT=comm,args ps -e | grep /X
ll /etc/X11/Xwrapper.config
cat /etc/X11/Xwrapper.config
grep EE ~/.local/share/xorg/Xorg.0.log
startx -- -verbose 7 -logverbose 7
grep EE ~/.local/share/xorg/Xorg.0.log
} &> /tmp/xout.txt

[Hans (hans-redhat-bugs)]

(In reply to Andrew Travneff from comment #13)
> 1:
> { tty
> PS_FORMAT=comm,args ps -e | grep /X
> ll /etc/X11/Xwrapper.config
> cat /etc/X11/Xwrapper.config
> grep EE ~/.local/share/xorg/Xorg.0.log
> startx -- -verbose 7 -logverbose 7
> grep EE ~/.local/share/xorg/Xorg.0.log
> } &> /tmp/xout.txt

Hmm, that is likely confusing Xorg because you're decoupling its stdin & stdout from the tty it is running from, can you try doing a simple:

"startx"

Without any input / output redirection directly from a login on tty1 ?

[Andrew (andrew-redhat-bugs)]

That's it, thanks. Second X session seems launched without root rigths.
Would it be better to open a separate issue about streams redrection breaking this functionality?

$ PS_FORMAT=uid,gid,comm,args ps -e | grep /X
 1000 1000 xinit xinit /etc/X11/xinit/xinitrc -- /usr/bin/X :0 -verbose 7 -logverbose 7 vt1 -nolisten tcp -auth /home/andrew/.serverauth.1095
    0 1000 Xorg.bin /usr/libexec/Xorg.bin :0 -verbose 7 -logverbose 7 vt1 -nolisten tcp -auth /home/andrew/.serverauth.1095
 1000 1000 ssh-agent /usr/bin/ssh-agent /etc/X11/xinit/Xclients
 1000 1000 xinit xinit /etc/X11/xinit/xinitrc -- /usr/bin/X :1 vt2 -nolisten tcp -auth /home/andrew/.serverauth.2580
 1000 1000 Xorg.bin /usr/libexec/Xorg.bin :1 vt2 -nolisten tcp -auth /home/andrew/.serverauth.2580
 1000 1000 ssh-agent /usr/bin/ssh-agent /etc/X11/xinit/Xclients
 1000 1000 grep grep --color /X

[Hans (hans-redhat-bugs)]

(In reply to Andrew Travneff from comment #15)
> That's it, thanks. Second X session seems launched without root rigths.
> Would it be better to open a separate issue about streams redrection
> breaking this functionality?

Yes please, component xorg-x11-server and please assign the bug to me. Although I'm not sure if / when I'll get around to fixing that. Note you should be able to redirect any 2 streams, as long as you leave one connected to the tty, e.g.:

startx &> logfile

Should work fine, likewise redirecting stdin, but leaving stdout and/or stderr connected to the tty should
work fine. Note redirecting one of the streams to *another tty* will breaks things, but if you redirect to regular files and leave one stream unredirected things should work.

[Andrew (andrew-redhat-bugs)]

(In reply to Hans de Goede from comment #16)

> Note you should be able to redirect any 2 streams, as long as you leave one connected to the tty

Sorry, seems like it is more restrictive. Described it in rhbz#1177513
Don't see an ability to (re)assign a ticket and can't link it here as "see also".

[Andrew (andrew-redhat-bugs)]

Created attachment 977933
kcalc fails to render

OK, another issue here. Can't use some GUI apps launched in root session ("su - root" in Konsole) with subject feature. Example screenshot attached.
Removing Xwrapper.config seems fixing that.

[Bastiaan (bastiaan-redhat-bugs)]

(In reply to Hans de Goede from comment #5)
> For use with startx it requires a tiny bit of manual configuration (because
> otherwise various dm-s would be broken), see:
> http://hansdegoede.livejournal.com/14446.html

I've followed these instructions on several machines and it seems to work well, in that `ps' shows Xorg.bin running as the user that started it, except for the following.

If I understand correctly, it should be possible for several users, or a single user, to run multiple X servers simultaneously without root privileges. But this doesn't work on two systems that I've tried, using startx, logging output:

[1650443.633] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
[1650443.634] _XSERVTransMakeAllCOTSServerListeners: server already running
[1650443.634] (EE)
Fatal server error:
[1650443.634] (EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE)
[1650443.634] (EE)
Please consult the Fedora Project support

Am I missing something?

[Hans (hans-redhat-bugs)]

(In reply to Bastiaan Jacques from comment #19)
> (In reply to Hans de Goede from comment #5)
> > For use with startx it requires a tiny bit of manual configuration (because
> > otherwise various dm-s would be broken), see:
> > http://hansdegoede.livejournal.com/14446.html
>
> I've followed these instructions on several machines and it seems to work
> well, in that `ps' shows Xorg.bin running as the user that started it,
> except for the following.
>
> If I understand correctly, it should be possible for several users, or a
> single user, to run multiple X servers simultaneously without root
> privileges. But this doesn't work on two systems that I've tried, using
> startx, logging output:
>
> [1650443.633] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener()
> failed
> [1650443.634] _XSERVTransMakeAllCOTSServerListeners: server already running
> [1650443.634] (EE)
> Fatal server error:
> [1650443.634] (EE) Cannot establish any listening sockets - Make sure an X
> server isn't already running(EE)
> [1650443.634] (EE)
> Please consult the Fedora Project support
>
> Am I missing something?

You should be able to do what you want by starting the 2nd xserver like this:

startx -- :1

And the 3th:

startx -- :2

etc.

[Bastiaan (bastiaan-redhat-bugs)]

That works, thanks!

[Andrew (andrew-redhat-bugs)]

Installed xorg-x11-xinit-1.3.4-3.fc21.x86_64, now "&>" works for me w/o -keeptty

As for root apps issue (comment #18)—does it want a separate ticket?

[Hans (hans-redhat-bugs)]

(In reply to Andrew Travneff from comment #22)
> Installed xorg-x11-xinit-1.3.4-3.fc21.x86_64, now "&>" works for me w/o
> -keeptty
>
> As for root apps issue (comment #18)—does it want a separate ticket?

Ah I missed that comment, yes file a separate bug for that please, and assign it to me directly from the new bug screen.

I need to discuss this on the upstream xorg-devel list, in a way it is more of a feature then a bug really, the problem is that with the xserver running as user it cannot access shared-memory segments created by other users, such as the root user. One could argue that this is a qt/kde bug. I've written MIT SHM code in the past, and one should check the xshm-attach succeeds (it will also fail when running over the network) and when it does not fail, qt/kde should fallback to not using shm, which it clearly is not doing.

So now the question to discuss upstream becomes if we can do anything to make shm work in this case, or if we simply tell the qt/kde guys to fix their stuff.

[Andrew (andrew-redhat-bugs)]

Created RHBZ#1185893
Can't manipulate assignment, sorry.

[Jaroslav (jaroslav-redhat-bugs)]

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

[Fred (eldmannen+launchpad)]

This kinds of depends on bug #1292324 which is support in LightDM.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jan (jan-redhat-bugs)]

This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.