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

[cl333r]

https://www.reddit.com/r/linuxquesti...t_reader_work/

More people than what you would think.



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.../pkexec.1.html

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


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.



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.

What you wrote is reasonable and generally I agree.
A few points though:
- you can actually run dolphin (and probably other apps too) without a polkit policy, you just add the env vars as mentioned before (proof attached as screenshot). It's just this approach doesn't work when executing it not from bash but from my app from QProcess. Potentially I could workaround this by launching bash to launch pkexec to launch bla-bla, but it's too much fuckery for doing a simple thing.
- Implied from above - fuck pkexec and fuck the morons who created it. This type of approach is ideal for Linux's usual task like on the server side, but for me it's not. Right now the app runs OOTB - the user doesn't have to do anything, while otherwise I'd have to tell the user to do admin stuff - which is what every normal user does not want to do nor should he care about it. Getting anyone to download/compile an unknown file browser is enough of an uphill battle in itself.
- The file browser will work fine even for those few who use fingers or ass-chicks to identify themselves, it's just they won't be able to use this little feature which neither dolphin nor nautilus have anyway.


Edit: The uploaded thumbnail was apparently downscaled by phoronix to the point you can't see anything. Great.

[ssokolow]

It's just this approach doesn't work when executing it not from bash but from my app from QProcess.

That sounds odd. Would you mind sharing the source for your attempt to use QProcess?

fuck pkexec and fuck the morons who created it.

I think you mean "fuck the default pkexec config and fuck the morons who created it". Fundamentally, pkexec itself is no different than sudo when it comes to profile-based environment variable resetting.

[cl333r]

That sounds odd. Would you mind sharing the source for your attempt to use QProcess?

TL;DR: No, I just have far more motivation working on my file browser than fixing pkexec.

I don't have it because when I saw that it doesn't work I removed that code and use now sudo which works fine and since I have no motivation to help improve pkexec (not that anyone asked for, or would accept it, or that I'm qualified for it, or that the stars are properly aligned) - I can't list it. But if you know Qt you can try on your own and see if it works.

Edit: So, with QProcess you basically have to replicate:
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY /path/to/exe

which in my case is:
pkexec env DISPLAY=:0 XAUTHORITY=/run/user/1000/gdm/Xauthority dolphin (or my own I/O daemon)

[ssokolow]

Edit: So, with QProcess you basically have to replicate:
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY /path/to/exe

which in my case is:
pkexec env DISPLAY=:0 XAUTHORITY=/run/user/1000/gdm/Xauthority dolphin (or my own I/O daemon)

Since it's quicker than spinning up a temporary C++ project, here's how you do it using PyQt5:

import os, sys
from PyQt5.QtCore import QCoreApplication, QProcess

app = QCoreApplication(sys.argv)
proc = QProcess(app)
proc.finished.connect(lambda code, status: app.quit())
proc.start("pkexec", [
"env",
"DISPLAY=" + os.environ.get("DISPLAY', ""),
"XAUTHORITY=" + os.environ.get("XAUTHORITY', ""),
"dolphin"])

sys.exit(app.exec_())

That fires up a Dolphin running as root just fine on my system.

[oiaohm]

What you wrote is reasonable and generally I agree.
A few points though:
- you can actually run dolphin (and probably other apps too) without a polkit policy, you just add the env vars as mentioned before (proof attached as screenshot). It's just this approach doesn't work when executing it not from bash but from my app from QProcess. Potentially I could workaround this by launching bash to launch pkexec to launch bla-bla, but it's too much fuckery for doing a simple thing.

Except using env todo work around is not officially supported. The officially supported is create policy file. It is permitted in future for pkexec to set the environment vars that you are setting as blocked when you don't have org.freedesktop.policykit.exec.allow_gui value set in policy.

- Implied from above - fuck pkexec and fuck the morons who created it. This type of approach is ideal for Linux's usual task like on the server side, but for me it's not. Right now the app runs OOTB - the user doesn't have to do anything, while otherwise I'd have to tell the user to do admin stuff - which is what every normal user does not want to do nor should he care about it. Getting anyone to download/compile an unknown file browser is enough of an uphill battle in itself.

This is going to be a uphill battle.

TL;DR: No, I just have far more motivation working on my file browser than fixing pkexec.

I don't have it because when I saw that it doesn't work I removed that code and use now sudo which works fine and since I have no motivation to help improve pkexec (not that anyone asked for, or would accept it, or that I'm qualified for it, or that the stars are properly aligned) - I can't list it. But if you know Qt you can try on your own and see if it works.

Edit: So, with QProcess you basically have to replicate:
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY /path/to/exe

which in my case is:
pkexec env DISPLAY=:0 XAUTHORITY=/run/user/1000/gdm/Xauthority dolphin (or my own I/O daemon)

The problem here is what works now is not promised to work into the future.

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.

Do note the org.freedesktop.policykit.exec.allow_gui says for legacy programs and is discouraged. Yes it perfectly valid for the Xwayland(the X11 server) under wayland to have whitelist of accepted applications to run not as the user. And if you are not on that list play dead even if you give the application the correct DISPLAY and XAUTHORITY.

Gnome with gvfs (that files uses) and kio that doplhin users is going the route of the I/O deamon. As in GUI runs as user and I/O deamon that is not graphical does the higher privilege actions over dbus protected by polkit.

You serous-ally want to run the least code as root going forwards.

cl333r did you miss "this is discouraged" or did fail to ask why. Code malfunctioning as root can do lot more damage than code malfunctioning as a normal user. So if your file browser has to run the graphical parts as root to perform root actions it is truly a insecure file manager.

Please be aware the Linux/freebsd root user is like the Windows System user. Guess what under windows you don't run anything directly as the windows system user. The Windows adminstrators user has restrictions the Linux/freebsd root user does not have.

[cl333r]

You serous-ally want to run the least code as root going forwards.

cl333r did you miss "this is discouraged" or did fail to ask why. Code malfunctioning as root can do lot more damage than code malfunctioning as a normal user. So if your file browser has to run the graphical parts as root to perform root actions it is truly a insecure file manager.

No that's not how it works at all.
Currently it produces 3 binaries: cornus (the GUI file browser with tabs and shit), cornus_io (the I/O daemon with user privilege, starts once and exits on pc shutdown) and cornus_r (I/O daemon only for root privileged I/O that starts when root I/O is needed and exits right after the 1st received I/O command batch is executed).
In case you're curious (under development):

https://github.com/f35f22fan/Cornus

[cl333r]

Since it's quicker than spinning up a temporary C++ project, here's how you do it using PyQt5:

import os, sys
from PyQt5.QtCore import QCoreApplication, QProcess

app = QCoreApplication(sys.argv)
proc = QProcess(app)
proc.finished.connect(lambda code, status: app.quit())
proc.start("pkexec", [
"env",
"DISPLAY=" + os.environ.get("DISPLAY', ""),
"XAUTHORITY=" + os.environ.get("XAUTHORITY', ""),
"dolphin"])

sys.exit(app.exec_())

That fires up a Dolphin running as root just fine on my system.

Yeah, must have done something wrong, but staying with sudo because it's already implemented and works and because by having my own password asking dialog I can also add a combo box to give the user a choice what to do with existing files if any: 1) to overwrite them, 2) to skip or 3) to auto rename them.

You know what's weird, sudo executes the process as root even if I give it the wrong password! What's going on? Is sudo remembering this app and somehow skipping password checking?

The main logic is at https://github.com/f35f22fan/Cornus/blob/main/App.cpp
at App::WaitForRootDaemon(), specifically this:

QProcess *process = new QProcess();
process->setProgram(QLatin1String("sudo"));
QStringList args;
args << QLatin1String("-S");
args << app_to_execute;
args << hash_str;
process->setArguments(args);

process->start();
if (process->waitForStarted())
{
    QByteArray pass_ba = pass.toLocal8Bit();
   mtl_info("pass_ba: \"%s\"", pass_ba.data());
   process->write(pass_ba);
   process->waitForBytesWritten();
   process->closeWriteChannel();
} else {
   mtl_trace("process.waitForStarted() failed");
}

...Or maybe I inserted my password by hand somewhere in the app and .. somehow it's being substituted.. it's weird.

[ssokolow]

You know what's weird, sudo executes the process as root even if I give it the wrong password! What's going on? Is sudo remembering this app and somehow skipping password checking?

Every distro I remember using had a default sudo configuration which caches the credentials for a little while. I believe the default sudo upstream specifies is 15 minutes and the timestamp_type and timestamp_timeout settings (documented in man 5 sudoers) control the scoping (eg. user account vs. a specific terminal session) and duration for the cached credentials.

You can experience it by running something like sudo ls twice in a row and the intent is to minimize the need to sudo into a root-privileged shell and do more than necessary with elevated privileges or risk leaving a privileged shell open indefinitely.

sudo -k or sudo --reset-timestamp will invalidate the cached credentials immediately while sudo -v or sudo --validate will create or update the cache as if you'd asked to run a command without requiring a command to run.

[oiaohm]

No that's not how it works at all.
Currently it produces 3 binaries: cornus (the GUI file browser with tabs and shit), cornus_io (the I/O daemon with user privilege, starts once and exits on pc shutdown) and cornus_r (I/O daemon only for root privileged I/O that starts when root I/O is needed and exits right after the 1st received I/O command batch is executed).
In case you're curious (under development):
https://github.com/f35f22fan/Cornus

The so called I/O deamon contains GUI interface calls this is error. This is what is resulting in you need to pass X11 though and this results in nice strange bugs like if someone uses your application over ssh X11 remote at times.

https://develop.kde.org/docs/d-bus/dbus_autostart_services/

Lot of what you are doing is what dbus is designed todo but this would mean you would have to install your application.

Yeah, must have done something wrong, but staying with sudo because it's already implemented and works and because by having my own password asking dialog I can also add a combo box to give the user a choice what to do with existing files if any: 1) to overwrite them, 2) to skip or 3) to auto rename them.

You know what's weird, sudo executes the process as root even if I give it the wrong password! What's going on? Is sudo remembering this app and somehow skipping password checking?

The main logic is at https://github.com/f35f22fan/Cornus/blob/main/App.cpp
at App::WaitForRootDaemon(), specifically this:

QProcess *process = new QProcess();
process->setProgram(QLatin1String("sudo"));
QStringList args;
args << QLatin1String("-S");
args << app_to_execute;
args << hash_str;
process->setArguments(args);

process->start();
if (process->waitForStarted())
{
QByteArray pass_ba = pass.toLocal8Bit();
mtl_info("pass_ba: \"%s\"", pass_ba.data());
process->write(pass_ba);
process->waitForBytesWritten();
process->closeWriteChannel();
} else {
mtl_trace("process.waitForStarted() failed");
}

...Or maybe I inserted my password by hand somewhere in the app and .. somehow it's being substituted.. it's weird.

You are lucky that it works. sudo can be configured to drop DISPLAY and XAUTHORITY out the environment settings as well just on the system you are using it configured to leave those alone. Also you are presuming the user is in the sudo users group. Debian and Ubuntu and all other distribution installs people can do installs where their user is not in the sudo group in that case sudo does not work at all. pkexec is smart enough to ask user for root password in those case and not straight error out as sudo does..

Yes this code is bad. Your application should never ask user for a system password if do you are doing the wrong thing.

Not only can polkit with dbus and sudo and su cache credentials they also can be configured under particular cases by the user not to ask the user for credentials at all or be asking for credentials that are not a password.

polkit and its authentication agents are designed to handle all cases. This is why pkexec is a way better idea than sudo even if it a pain in but. Yes a dbus service is a better idea again. Yes a dbus service can check the application that is calling it and the polkit policy can list a limit number of applications that can use a dbus interface.

[cl333r]

The so called I/O deamon contains GUI interface calls this is error. This is what is resulting in you need to pass X11 though and this results in nice strange bugs like if someone uses your application over ssh X11 remote at times.

https://develop.kde.org/docs/d-bus/dbus_autostart_services/

Lot of what you are doing is what dbus is designed todo but this would mean you would have to install your application.



You are lucky that it works. sudo can be configured to drop DISPLAY and XAUTHORITY out the environment settings as well just on the system you are using it configured to leave those alone. Also you are presuming the user is in the sudo users group. Debian and Ubuntu and all other distribution installs people can do installs where their user is not in the sudo group in that case sudo does not work at all. pkexec is smart enough to ask user for root password in those case and not straight error out as sudo does..

Yes this code is bad. Your application should never ask user for a system password if do you are doing the wrong thing.

Not only can polkit with dbus and sudo and su cache credentials they also can be configured under particular cases by the user not to ask the user for credentials at all or be asking for credentials that are not a password.

polkit and its authentication agents are designed to handle all cases. This is why pkexec is a way better idea than sudo even if it a pain in but. Yes a dbus service is a better idea again. Yes a dbus service can check the application that is calling it and the polkit policy can list a limit number of applications that can use a dbus interface.

When did you sleep last time? Just curious.