[solved] gksu (gksudo) issues plus other comments

[patday8472]

I have a hunch why my upgrade & why my clean installs of Xubuntu & Linux mint Xfce didn't work very well. I believe there are some programs that need gksu that I use. One might be even be a proprietary display driver.

I have seen people mentioned the gksu (gksudo) is unsecure. How is it unsecure? I am the only one using the computer. My login is protected by a password.

As for as using the admin option, that doesn't really work with leafpad or thunar. For example, this is how I use gksudo. gksudo thunar /etc/apt then I right click on sources.list and open it with leafpad.

If I do this with admin option it opens up thunar weirdly. Then I open a source list file and its blank.

Now, to what I am wanting to know. Does mint upgrades 18.3 to 19.0 to 19.1 honor the hold package request or should I use synaptic to do that? I really don't want to switch to opensuse or fedora.

Sample

Code: Select all

sudo apt-mark hold gksu

I am little confused on whats going on with the current xfce fedora spin.

I am not sure what this means:

Although this spin failed to compose for the final release, this test compose contains fixes over the final content to allow for a successful compose and should meet most users' needs. You can verify the test compose image with a dedicated CHECKSUM file for 64-bit and 32-bit images.

Thank you for your help.

Just a note, I am back to using 18.3 (I make backups using a 3rd party program).

[altair4]

I do not know the answer to your question but while you wait for someone who does:

For example, this is how I use gksudo. gksudo thunar /etc/apt then I right click on sources.list and open it with leafpad.

*** Substitute pkexec for gksudo:

Code: Select all

pkexec thunar

Right click on /etc/apt/sources.list and select open with text editor.

pkexec.png

[patday8472]

altair4 Thank you. I didn't realize there was another gksu/gksudo item.

I have an easy way to restore. is there a way I can get fool a programs to use pkexec instead of gksu at or before drivers load? The program will think it is using gksu or gksudo but it will really be using pkexec.

I would still like to know why gksu/gksudo is unsecure?

Just out of curiosity, does the hold via terminal or lock via synaptic package manager work for the 18.3 to 19.0 to 19.1 upgrade?

[trytip]

gksu not being secure is debatable. i still use it in arch linux and works fine, but it's from a user repo and not the official repos. arch elitists would spit fire on you if they learn you still use gksu and to that i say, e'hem it's my damm computer.

it's actually very easy to edit a pkexec policy to use no password for root actions so in that aspect pkexec is less secure than gksu. gksu is considered security risk because it hasn't been updated in a while or maintained. but we all use software that hasn't been updated especially on ubuntu

take for instance the vidalia control center for tor network. it's not maintained and most new distros don't have it in the repos. mageia6 has taken the software re-written with QT instead of GTK placed it in their official repos and is available to users

you can trick your system to think gksu is installed but only for terminal commands by adding this to the .bashrc file at the bottom. gui application won't be able to use it unless you physically create a dummy file to act as gksu but in some instances it doesn't work so i don't bother. i never used gksudo always gksu for me

Code: Select all

alias gksu=pkexec
alias pkexec='pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY'

[patday8472]

trytip I thought gksu and gksudo are the same thing. I though gksudo was an alias of gksu.

For example from the terminal, I always used gksudo thunar /etc/apt

[trytip]

trytip I thought gksu and gksudo are the same thing. I though gksudo was an alias of gksu.

For example from the terminal, I always used gksudo thunar /etc/apt

on systems that gksu is physically installed your gksudo command works fine. my comment above is for new linux versions where gksu is not physically available like linux mint 19

with the .bashrc alterations to add an alias for gksu, gksudo is not added. if you have that option to use gksudo it means gksu is installed. dpkg -l gksu* will give you info if it's installed with an ii

[smurphos]

Debian decided to remove it originally following this report from chap who was the lead of Ubuntu Gnome when is was a separate flavour.
https://bugs.debian.org/cgi-bin/bugrepo ... bug=867236

I guess this is the security vulnerability that was never fixed it's the only one I can find filed against gksu - https://nvd.nist.gov/vuln/detail/CVE-2014-2886

Plenty of workarounds - the xenial debs are freely available and install just fine in Mint 19 and trytip, gm10 etc have all posted ways to wrap pkexec in an alias or a small user script so you still have a gksu or gksudo command available.

[redlined]

Debian decided to remove it originally following this report from chap who was the lead of Ubuntu Gnome when is was a separate flavour.
https://bugs.debian.org/cgi-bin/bugrepo ... bug=867236

gksu has been deprecated for years. The intent of gksu is to allow
running apps with elevated privileges but the way to do that is for
the app developer to use PolicyKit to request elevated privileges for
the specific actions that need done instead of for the whole app to
run as root.

ahhhhhh, now I get the concept and the issue!

I guess this is the security vulnerability that was never fixed it's the only one I can find filed against gksu - https://nvd.nist.gov/vuln/detail/CVE-2014-2886

when sudo-mode is not enabled, uses " (double quote) characters in a gksu-run-helper argument, which allows attackers to execute arbitrary commands in certain situations involving an untrusted substring within this argument, as demonstrated by an untrusted filename encountered during installation of a VirtualBox extension pack.

and privilege escalation issues on an unpatched security vulnerability with a network access vector sounds like a reasonable enough reason for me to leave it be, letting it rest in piece(s), in the bit bucket where it has remained for more than 5 years.

[patday8472]

when sudo-mode is not enabled, uses " (double quote) characters in a gksu-run-helper argument, which allows attackers to execute arbitrary commands in certain situations involving an untrusted substring within this argument, as demonstrated by an untrusted filename encountered during installation of a VirtualBox extension pack.

I am not quite sure what the above quote means. You would still have to have access to the computer itself for the attack to work correct? It also couldn't be done remotely?

As far my Gksu issue itself. I got it installed thanks to another poster.

I am still curious about what does this mean (see quote below) for the xfce fedora spin?

Although this spin failed to compose for the final release, this test compose contains fixes over the final content to allow for a successful compose and should meet most users' needs. You can verify the test compose image with a dedicated CHECKSUM file for 64-bit and 32-bit images.

[redlined]

when sudo-mode is not enabled, uses " (double quote) characters in a gksu-run-helper argument, which allows attackers to execute arbitrary commands in certain situations involving an untrusted substring within this argument, as demonstrated by an untrusted filename encountered during installation of a VirtualBox extension pack.

I am not quite sure what the above quote means. You would still have to have access to the computer itself for the attack to work correct? It also couldn't be done remotely?

What I understand of it is enough reason for me to avoid it and use the more modern approach for elevated privileges using sudo/su/pkexec/admin:/// to get done what I need/want locally.

As far as can it be/it couldn't be done remotely question/statement, yes, it appears to be vulnerable to remote exploit.

Drilling down from the CVE page here:
https://nvd.nist.gov/vuln/detail/CVE-2014-2886

I see two pieces of info that caution me, one is what CWE-264 means:
https://cwe.mitre.org/data/definitions/264.html

CWE CATEGORY: Permissions, Privileges, and Access Controls
Category ID: 264
+ Summary
Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.

and

Base Score: 6.8 MEDIUM
Vector: (AV:N/AC:M/Au:N/C:P/I:P/A:P) (V2 legend)
Impact Subscore: 6.4
Exploitability Subscore: 8.6

Access Vector (AV): Network

V2 legend is a link to: https://www.first.org/cvss/v2/guide
which explains the codes in vector as well "access vector: network" as:

Network (N) A vulnerability exploitable with network access means the vulnerable software is bound to the network stack and the attacker does not require local network access or local access. Such a vulnerability is often termed "remotely exploitable". An example of a network attack is an RPC buffer overflow.

the CVE also includes these links, which I would consider first to help decide if I wanted to use the vulnerable software/service at all:

http://savannah.nongnu.org/bugs/?40023
https://community.rapid7.com/community/ ... n-via-gksu (Exploit) <---this is marked as so in the CVE
https://launchpad.net/bugs/1186676
https://security.gentoo.org/glsa/201812-10

As far my Gksu issue itself. I got it installed thanks to another poster.
I am still curious about what does this mean (see quote below) for the xfce fedora spin?

Although this spin failed to compose for the final release, this test compose contains fixes over the final content to allow for a successful compose and should meet most users' needs. You can verify the test compose image with a dedicated CHECKSUM file for 64-bit and 32-bit images.

Not sure what that means either! where did you get that quote from?

edit to add:
the gentoo link above confirms it is still exploitable (at least version used by gentoo) and verified very recently:
https://security.gentoo.org/glsa/201812-10

Release Date December 30, 2018
Latest Revision December 30, 2018: 1
Severity normal
Exploitable remote

and their advice?
no workaround, simply uninstall it

Resolution
Gentoo has discontinued support for GKSu and recommends that users unmerge the package

I imagine it is similar to why Debian pulled it, affecting Mint. My due diligence is done on the matter, I'm convinced it is unsafe and replacements are sufficient. I do hope this helps you make an appropriately informed decision as well!

[patday8472]

Well if that the case. Then Debian/arch needs to backport pkexec or lxqt-sudo for gksu & gksudo for older & newer versions. Then they could program an alias for people who got into the habit of using gksu(gksudo) and for application, & scripts that still depend on it. They need to modify pkexec or lxqt-sudo to work when either an application/script calls for it or when the user calls for it.

I also believe there is a driver on both computers that might depend on gksu(gksudo). Linux mint xfce 19.1 clean install with gksu/gksudo hasn't crashed yet.

I also read pkexec is really not secure. Is it possible to get the mdm & mdm themes to work without using gksudo/gksu? As I said before I was able to install both gksu(gksudo) & mdm themes but had a few issues which was resolved thanks to a poster.

As far as being secure, are you telling me with gksu installed is no more safer than using windows 7 sp1 & Windows 10?

redlined
Before I got gksu working & before I found out about pkexec, I was looking for another xfce version that works like gksu/gksudo fedora and Opensuse xfce came to mind. I just recently found out about lxqt-sudo. I quoted the text from the actual download page. The page is titled "Download Fedora 29 Xfce Desktop" I didn't download load it because the info confused me.

[Flemur]

I downloaded

Code: Select all

gksu_2.0.2-9ubuntu1_amd64.deb

and use that (just search that full file name to get it).

"pkexec" calls me naughty person and wants to "report" me ....

[MtnDewManiac]

I do not know the answer to your question but while you wait for someone who does:

For example, this is how I use gksudo. gksudo thunar /etc/apt then I right click on sources.list and open it with leafpad.

*** Substitute pkexec for gksudo:

Code: Select all

pkexec thunar

Right click on /etc/apt/sources.list and select open with text editor.
pkexec.png

Can't you just run Thunar normally and then choose the "Open Folder as Root" option from its right-click menu if you temporarily want elevated privileges with your file manager? I thought that was what the option was for.

Regards,
MDM

[zcot]

Why not just give root a password, unlock the root login from login screen and you're done. -you can forget about the pain, never even typing sudo or variant front-end command again.

sudo has its reasoning and any of the variety of graphical front-end variations the same, so why go through so much hassle when the goal is "easy".. -just straightly eliminate the bleeding and be root. Problem solved!

[patday8472]

Why not just give root a password, unlock the root login from login screen and you're done. -you can forget about the pain, never even typing sudo or variant front-end command again.

sudo has its reasoning and any of the variety of graphical front-end variations the same, so why go through so much hassle when the goal is "easy".. -just straightly eliminate the bleeding and be root. Problem solved!

Why would you give that advice? Being in root all the time is dangerous.

[altair4]

Is this thread still alive?

There's 3 ways to handle this situation from a design standpoint:

[1] The KDE way.

If I as an ordinary user wants to edit a system file I would access the file and edit away. But when I go to save it I am confronted with this:

KDE.png

This is sorta kinda the way MacOS does things. The user isn't expected to know nothin' about no kdesu or polkit or pkexec or anything else. He tries to do something that requires elevated privileges and is prompted for credentials.

[2] The Xubuntu way.

Xubuntu took the time and trouble to replace gksu with pkexec for BOTH their file manager and default text editor. So if I ran gksu mousepad /some-system-file in the past I would run pkexec mousepad /some-system-file now.

The design flaw here is that the user may not be aware that gksu went to Linux heaven and has never heard of pkexec. When he issues a gksu mousepad he is told that Command 'gksu' not found ... Instead of Try pkexec instead ...

[3] THe gvfs way of the admin:/// thing and all the rest of the options listed in this thread.

My cardiologist recommends not using KDE in my case but it seems that is the right way to do things if the objective is to minimize support quesitons in forums.

[patday8472]

I think it was personally a mistake to remove gksu.

Just for info wayland doesn't conflict with gksu/gsudo on Xubuntu

Some people like MDM themes. I liked Spacerace login-theme.

I don't know how displayer drivers work behind the scene. Doesn't display drivers depend on root access? Also, could the two dell computers require gksu without me even knowing? I have been testing Xubuntu 18.04 with gksu & mdm themes. So far no crashes.

The only issue I am having is the mouse is a little two sensitive in Xubuntu I know about the adjustment control. I am not asking for help on this.

altair4

I believe opensuse gui root privilege works like KDE (Even if kde is not installed). I don't think it would be possible to install mdm themes though.

[smurphos]

I don't know how displayer drivers work behind the scene. Doesn't display drivers depend on root access? Also, could the two dell computers require gksu without me even knowing? I have been testing Xubuntu 18.04 with gksu & mdm themes. So far no crashes.

The only reason MDM needs gksu is because the exec line in it's settings app's desktop file uses gksu, and therfore gksu is declared as a dependency in the control file in the deb package. Both those things could be worked-around in various ways without installing gksu. That's just the easiest option.

Other than updating translations MDM development ceased in December 2016 - about 18 months before the gksu/pkexec debate became relevant for Mint users. It's just old software with old dependencies.

gksu does nothing special other than provide a GUI to input password rather than using a terminal and calls sudo / su with a specific set of parameters to stop files in your $HOME getting owned by root when you elevate your users privileges.

[zcot]

be root. Problem solved!

Why would you give that advice? Being in root all the time is dangerous.

I would not give that as advice actually, but it was the question of it. It just feels like the goal is convenience overall, and above progress and security which probably are not a factor. -or do I mistake that?

If the pc has no banking, purchases, nothing work-related, there's offsite backups, if there's nothing really important that's not public-ready on the machine then really even basic security is a non issue anyway I guess in which case "danger" isn't even an issue.

Once the decision goes from "how likely is it that I will be hit with that specific known gksudo exploit", to "ahh, we have no risk, it's a non issue", then using root full time isn't a step away.

It looks like there's 2 directions.. either accept and move forward in whatever ways are possible, which didn't seem like it's happening, or go moving backward, in which case the very easiest thing is to just run as root which actually makes all parts of all of this numerous levels of easier.

[redlined]

be root. Problem solved!

Why would you give that advice? Being in root all the time is dangerous.

I would not give that as advice actually, but it was the question of it. It just feels like the goal is convenience overall, and above progress and security which probably are not a factor. -or do I mistake that?

If the pc has no banking, purchases, nothing work-related, there's offsite backups, if there's nothing really important that's not public-ready on the machine then really even basic security is a non issue anyway I guess in which case "danger" isn't even an issue.

Once the decision goes from "how likely is it that I will be hit with that specific known gksudo exploit", to "ahh, we have no risk, it's a non issue", then using root full time isn't a step away.

It looks like there's 2 directions.. either accept and move forward in whatever ways are possible, which didn't seem like it's happening, or go moving backward, in which case the very easiest thing is to just run as root which actually makes all parts of all of this numerous levels of easier.

well said zcot!

ps. bolded text in quote I added for emphasis and what I also consider the decision really is all about, and since gksu/gksudo is deprecated due to a remotely exploitable network accessible vulnerability, definitely makes for the argument to 'why not just run as root always'...