X.Org Server Hit By Its Latest Batch Of Security Vulnerabilities

[pal666]

I agree will be interesting to see if OpenBSD's Xenocara is affected by the bugs since it runs not as root but as a local user.

xorg also runs as user if you run it as user(fedors does)

[pal666]

I'm not sure why I didn't think of it before, it seems like such an obvious solution. I'll try to implement it and see if it works well. Thanks.

PS: Oh I remembered why I didn't pick it at first - because I was thinking about letting this daemon not exit after executing the first batch of commands, but since later I decided that it should exit after the 1st batch (for security reasons, because it has root privileges) I don't strictly need it to deal with sockets.

you can use stdin even with long-running daemon

[dec05eba]

I'm not sure why I didn't think of it before, it seems like such an obvious solution. I'll try to implement it and see if it works well. Thanks.

PS: Oh I remembered why I didn't pick it at first - because I was thinking about letting this daemon not exit after executing the first batch of commands, but since later I decided that it should exit after the 1st batch (for security reasons, because it has root privileges) I don't strictly need it to deal with sockets.

You can use socketpair to create an anonymous socket between processes that other processes cant interfer with. You can reuse that socket for new processes as long as the processes are parent/children

[ssokolow]

No, it has no GUI, but it does use Qt, which from pkexec's point of view means "gui", which in this case it's not.
Why not use Qt at all? Because I have all the I/O logic implemented in Qt, and it's far more complicated than it seems at first glance.

I may be wrong, but it sounds like you're still using QGuiApplication or QApplication for your helper's event loop, instead of QCoreApplication, which should be used for non-GUI stuff.

[oiaohm]

Sorry for the off-topic, but also security related.
I have a file browser I'm creating that I want to allow the user to manage root protected files (e.g. system files) by
1) querying him for the root password, then
2) executing sudo -S (password) (daemon_exe) (not using pkexec because it doesn't work with GUI/X11 apps).
3) daemon_exe is a lightweight daemon that when it starts it listens on a socket(AF_UNIX, SOCK_STREAM, 0), executes the first command it gets and exits.

I imagine the problem with this is that in theory it's possible that in between launching this privileged daemon and sending it an I/O command some other app might maliciously intervene and tell it to do nasty things as a root. If that's the biggest problem - how should it be tackled? Or to be more precise, how do I make sure that the newly started daemon will only execute the command it receives thru a socket from my app, not some other one?

Don't reinvent the wheel. gvfsd-admin exists to allow altering system files as part of gnome and there is work to bring the same feature to kio. You will notice when you look at both of them they are using dbus and polkit.

Also you are wrong pkexec does work for non GUI/X11 applications. some case you do need to pkttyagent the bash/program you are running pkexec from you are using before you can use pkexec when running without X11 loaded but this is due to a bug. Reality is if pkexec does not work with terminal application this is a reportable bug.

Yes polkit pkexec uses to authenticate is meant to choose a suitable agent be you running pure text mode, X11 or Wayland.

Starting deamon yourself instead of using dbus has the problem that you cannot have clean start on demand. No using dbus means you miss out on a lot of stuff for setting up a safe and secure connection.

Final killer to your idea what if the user is not using a password but a token device or finger print scanner. You application will not be able get the authorisation from those to duplicate because your application is not pam. Yes polkit can be a pain in ass to deal with but its hooked up so it supports all forms of authorisation.

[cl333r]

I may be wrong, but it sounds like you're still using QGuiApplication or QApplication for your helper's event loop, instead of QCoreApplication, which should be used for non-GUI stuff.

I just checked, it's QCoreApplication:

int main(int argc, char *argv[])
{
QCoreApplication app(argc, argv);

cornus::PrintHelp(argv[0]);
cornus::Listen();

return 0;
}

Though I'm not really sure it's blocking GUI apps, it just seems *to me* it's saying so (search for "X11"):

https://www.freedesktop.org/software/polkit/docs/0.105/pkexec.1.html

[cl333r]

what if the user is not using a password but a token device or finger print scanner. You application will not be able get the authorisation from those to duplicate because your application is not pam.

Who uses "token device or finger print scanner" on their PCs as root passwords?

[cl333r]

Also you are wrong pkexec does work for non GUI/X11 applications. some case you do need to pkttyagent the bash/program you are running pkexec from you are using before you can use pkexec when running without X11 loaded but this is due to a bug. Reality is if pkexec does not work with terminal application this is a reportable bug.

I'm not sure what you're saying here because I was saying it doesn't want to run gui apps, at least here on my Plasma 5, e.g. dolphin fails to start:

$ pkexec dolphin
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinsta
lling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland
-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

Aborted (core dumped)

There is a solution, but it only works from the command line and fails when executing programmatically:
pkexec env DISPLAY=:0 XAUTHORITY=/run/user/1000/gdm/Xauthority dolphin

[horizonbrave]

if ain't working, don't fix it

[oiaohm]

Who uses "token device or finger print scanner" on their PCs as root passwords?

https://www.reddit.com/r/linuxquestions/comments/imnmgj/how_can_i_make_my_fingerprint_reader_work/

More people than what you would think.

I'm not sure what you're saying here because I was saying it doesn't want to run gui apps, at least here on my Plasma 5, e.g. dolphin fails to start:

$ pkexec dolphin
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinsta
lling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland
-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

Aborted (core dumped)

There is a solution, but it only works from the command line and fails when executing programmatically:
pkexec env DISPLAY=:0 XAUTHORITY=/run/user/1000/gdm/Xauthority dolphin

And that exactly what should happen. pk at the start of pkexec stands for policykit. You did not create a polkit rule did you.

https://www.freedesktop.org/software/polkit/docs/0.105/pkexec.1.html

You have never read the manual of pkexec or you did not read it completely.

The environment that PROGRAM will run it, will be set to a minimal known and safe environment in order to avoid injecting code through LD_LIBRARY_PATH or similar mechanisms. In addition the PKEXEC_UID environment variable is set to the user id of the process invoking pkexec. As a result, pkexec will not allow you to run X11 applications as another user since the $DISPLAY and $XAUTHORITY environment variables are not set. These two variables will be retained if the org.freedesktop.policykit.exec.allow_gui annotation on an action is set to a nonempty value; this is discouraged, though, and should only be used for legacy programs.

Yes this section of text starts of saying pkexec will not run X11 applications then goes on to say set org.freedesktop.policykit.exec.allow_gui for legacy programs.

https://unix.stackexchange.com/quest...y-using-pkexec There is example here.

It can be done by adding custom actions to policykit. If you want to run gedit as root with pkexec you have to create new file /usr/share/polkit-1/actions/org.freedesktop.policykit.gedit.policy for example:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"> <policyconfig> <action id="org.freedesktop.policykit.pkexec.gedit"> <description>Run gedit program</description> <message>Authentication is required to run the gedit</message> <icon_name>accessories-text-editor</icon_name> <defaults> <allow_any>auth_admin</allow_any> <allow_inactive>auth_admin</allow_inactive> <allow_active>auth_admin</allow_active> </defaults> <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/gedit</annotate> <annotate key="org.freedesktop.policykit.exec.allow_gui">tru e</annotate> </action> </policyconfig> Finally pkexec gedit should work as expected.

Note the two things you added by env will be added if you added a polkit policy for the application that you wish to run as graphical as root with org.freedesktop.policykit.exec.allow_gui set the values will be there. Of course this polkit policy file will not exist for dolphin out box.
lightweight daemon needing graphical is coded wrong.

Yes in future you will not be needing to run dolphin as root ever because some point in future kio will allow higher privillage access with the GUI of the application not as root. Same way gnome files by gvfs allows you to edit root files using admin:/// while files it self is running as your normal user right now.

Do note that I did write "Yes polkit can be a pain in ass to deal with" yes getting your head around what you need to set in polkit policy so everything works is a bit of a learning curve. There are a lot of things people think cannot be done that turn out to be you have not set policy.