What a glorious little bug. They're trying to scan arguments, and have a loop that starts with (effectively) argv[1]. But if argv is NULL, the loop terminates immediately --- with the maximum argument still set to 1, an out-of-bounds dereference to argv[1] that ends up pointing into the environment. Just beautiful.
argv[0] always exists in normal means, it is either physical path of the executable or soft link position. Without accidents like run a program from code and forget about passing argv. That couldn't happen at all. And in fact, most cross platform program or shell even just assume argv[0] is the same as executable path (and don't give you a option to change it, because it is not possible on all platforms).
I did that once, but the target is a shell. Shells relies on argv[0] to determine what it is running as (login shell have prefix on argv[0]). So it end up blew up in a funny way.
After a bit google I realize I need to repeat the file path by myself on *nix. In windows, the spawn equivalent take a long string, anything after file path is argument. So it can't be a bug since day 1.
> In windows, the spawn equivalent take a long string, anything after file path is argument.
The tradeoff being that even reliably getting a Windows program in C to receive a given value in argv[] is awful[1], and the full rules for what happens if you’re unfortunate enough to need to pass through the shell are truly horrendous[2] (as well as, of course, nearly undocumented). Oh, and there is literally no way to pass arguments through in a batch file[3] (i.e. no reliable equivalent to "$@").
The reason is that command lines being dumb strings (as they are in DOS and consequently Windows) means that there are at least two places where command-line parsing needs to happen: in the shell, to detect shell syntax, including simply knowing where the command ends; and in the program (C runtime library startup or equivalent), to separate, unquote, and unescape the string into an arguments array. Thus there are at least two sets of escaping rules in play at the same time, which will inevitably diverge. (In Windows there are something like three and a half, given that executing from a batch file adds an additional layer of textual preprocessing and delayed expansion uses slightly different rules, but that is not inherent in the design choice, it’s just braindamage.)
I actually find this an interesting design problem (and have commented on it before[4]), because while the depths of insanity in the Unix approach (the shell tokenizes and globs) aren’t quite as unfathomable, the touch ./-rf; rm * problem that it implies still feels like something that shouldn’t happen, and I just can’t see an interesting intermediate point between those that wouldn’t substantially complicate the shell-to-entry-point interface.
The fix for this ("if (argc < 1) exit(126)" [1]) is just ... ugh.
Some weeks ago I wanted to run a game; it showed an error when starting that it failed to set real-time priority for the audio thread, resulting in actual audio stuttering.
ALAudio asks rtkit, rtkit asks polkit, and that somehow fails. Why? Who knows. To even figure this out I had to recompile rtkit with some strategic printf() calls in there, because it just doesn't show at all why it failed. Same for polkit.
I never did find out what the problem was. I just gave up after a while.
It's stuff like this why I dislike all these tools: it all works when it works, but when it fails it really makes your life hard. Here, too, it just exits with 126, no message, and good luck to you as developer or user if something goes wrong.
Call me a radical traditionalist unix greybeard, but I really think tools should tell users what goes wrong, even (or perhaps especially) when they're "internal" tools like this, because this it's just really hard to figure out what the problem is. "fprintf(stderr, "too few arguments\n")" is not very hard, it seems to me shrug.
The only way that condition happens is if the program is being exploited. You cannot, for instance, trigger it from a shell. Here, argc is less than 1. There have been multiple attempts to get the kernel to EFAULT when execve() is called this way, because a NULL argv has utility principally as a gadget in shellcode and nowhere else. EFAULT is what FreeBSD and OpenBSD do when you try to execute a program with a NULL argv.
Fault them for not changing the loop, which has clearly busted logic, and adding a guard clause instead. But you can't fault them for not providing a user friendly error to shellcoders. The condition here isn't simply "too few arguments".
Can't you exec() this and run it with zero arguments?
Either way: when in doubt, best to print a message! You're right this specifically probably isn't the biggest issue, but in general it seems to be design with "this should never happen, just exit/deny" in mind, and turns out that in some odd cases those things do happen.
The point of exit codes is that they're straightforward for programmers to extract, rather than error messages, which require the programmer to capture and parse stderr. So, no, I don't think you've rescued this very bad argument.
I don't think this is a bad argument at all. It wouldn't kill anyone to include a brief stderr worthy message along with the exit. Especially when, and correct me if I'm wrong, code 126 is pretty vague here. "Command not executable" doesn't seem even correct to me.
The entire point of Unix exit codes is to communicate enumerated errors to programmers without having them have to intercept stderr and parse unstructured output. But to spot this error, of "I literally don't know how to use execve", all you need to do is look for the nonzero exit code.
I suspect that the person who kicked this subthread off didn't realize that the error can't be triggered from the shell (like, they thought it was "insufficient arguments" and not "malformed input to execve"), and now we're just bikeshedding a justification for being angry at Unix error codes. Seems like not a super valuable discussion to have.
One good reason not to have a user-friendly error message here is that literally no user will ever see it. In fact: it's likely that in the entire history of this program, it has never once been executed in the fashion that would generate this error, except to exploit it.
Again this is indeed a bike-shedding conversation but how hard is it to print an error message along with the error code? Seems harmless enough and just one more line of code.
In case helpful for you or anyone else, you can find out whether polkit would allow a request for an action with pkcheck(1), for instance: "pkcheck --action-id org.freedesktop.RealtimeKit1.acquire-real-time --process $$" and check the exit status.
What is missing in all these complaint threads (and this isn't aimed at you specifically) is the complainers' proposed alternatives. It's very easy to write a glib comment about "sudo already does this" "groups already do this" which indicates only that the person writing the comment doesn't understand the problem that PolKit is trying to solve.
As near as I could figure out RTkit asked Polkit "do I have permissions to set this real-time?", and Polkit said "no". But perhaps I'm wrong; I found it all very hard to debug as mentioned before, and I didn't care that much just to play some game. I don't have the game on my laptop any more; I'll have to try your pkcheck command next time (although that still won't fix anything, but might get me closer; thanks!)
What I lament is not so much that things have changed, but that things have changed in ways I no longer understand or can debug. Back in the Old Days™ you could more or less understand your entire system from a few very basic principles. If something didn't work, you could go in there and usually figure it out on your own.
Not that I have rose-coloured glasses about the Old Days™. I remember having to run that horrible "xfree86 -configure" thing when I was starting out with this whole Linux thing. Clearly, things are better now because the last time I had to look at "configuring X" is so long ago I don't even remember how to do it (or even what that filename was; /etc/x.conf? Or /etc/x11.conf? Not sure).
I don't think it has to be like this. Just because "su" and "sudo" aren't sufficient and the concepts in e.g. Polkit are good doesn't mean the implementation of these concepts also is.
I won't say PolKit's implementation is the best ever. But it exists, and solves real problems, enough so that applications choose to use it and distros choose to ship it.
One thing I can say in PolKit's favour is that it's well documented--which is important for such a critical component.
> works when it works, but when it fails it really makes your life hard. Here, too, it just exits with 126, no message, and good luck to you as developer or user if something goes wrong.
strace
Nowadays I just reach for it immediately. Powerful, total/complete (since syscalls are everything). The typical unix tools all depend on these hard to discover environment things. Other processes, env vars, files here or there, sockets, dbus, signals...
As there seem to be misunderstandings about what polkit is:
It's a way to let user processes communicate with privileged processes while potentially, action dependent also prompting the user for a password.
pkexec on the other hand is separate program bundled with polkit which is kinda which let's you combine polkit with running predefined commands, or easily accidentally any command and IMHO should not exist.
there are various programs which work with polkit (even if they don't necessary require it) including:
- systemd, logind, NetworkManager, udisks, flatpack, fwupd, timedate(setting), and others
It also allows rather flexible configurations about what users can do which actions under which conditions, which can be quite useful for a multi-user server (e.g. GPU server).
While I think a program like polkit is a must have for a modern Linux OS I'm not a fan of it's design.
- pkexec is a bad idea for many more reasons then this vulnerability
- the way it's configured and how it handles caching is prone to accidentally make mistakes with security consequences
- pkexec should not exist, even without the vulnerability it's really easy to mess up using it
- having a embedded language for handling permission scripting, and not inventing your own language or pseudo-language config format is a good. But js? I guess there are simple embedded js interpreters.(1)
(1): Note that it only runs small snippets, so no need to have a JS interpreter with modern features like classes, or an JIT ;=)
Speaking of security though, I'd trust SpiderMonkey much more because it's battle-tested in the most hostile environment imaginable (millions of browser instances loading completely untrusted code 24/7). But in this context we don't execute untrusted code so whatever :)
> pkexec should not exist
Hmm. For things that do want "just a graphical sudo" for whatever reason, it is kinda the perfect answer. Reusing the per-desktop authorization UI that is used for more fine-grained actions for a sudo-like tool is the correct thing to do. No one wants to have more redundant authorization mechanisms and UIs…
Ok, let me correct myself, `pkexec` as a simple GUI sudo should probably exist. But be differently designed.
(I would have to read through the polkit doc again, but there was some massive trap around how polkit configs work and how pkexec _might_ be used, I think related to the "permission caching feature").
> I'd trust SpiderMonkey much more because it's battle-tested in the most hostile environment imaginable
Enough OSes are behind and everyone using spidermonkey is unable to keep up with the porting requirements in the short window of ESR overlap so you can read vulnerabilities for the latest ESR and apply them to everyone. It would be nice if duktape had complete sandboxing, etc, but it has the advantage that hackers have to do all their own research to mount an attack.
sudo/suo/doas do not allow for flexible policy evaluation. They're also useless for GUI applications.
For instance, GNOME Settings uses PolKit to ensure that remote control can only be turned on by an admin who makes the request from an active session on a local console.
Or here's a more interesting example. gvfs uses PolKit to allow processes that are part of an active session on a local console to be able to elevate permissions for editing files (e.g., 'gedit admin:///etc/motd').
Ever since my first encounter with PolicyKit back in the early days of its inclusion in Debian, ages ago, I've had a very bad impression of its implementation quality.
Back then it would segfault randomly for no apparent reason, idle freshly installed fairly minimalist headless fileservers. We immediately blacklisted it from our systems, but were lucky to not actually need anything it brought to the table.
IIRC for quite some time there wasn't even a maintainer, but I think that was pre-polkit rename. Hopefully the situation has improved.
Did they tell the Polkit people about this? Or was it just posted on their website? Or to rephrase it: what are the reasons this wasn't this fixed in 2013?
NB, this was partially fixed in gnulib in 2009:
http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=b06da86eb05ed57e2861061ae5cacf4c7a3686f1
But glib has its own copy of this code, which hasn't been updated since 2008.
Embedded code copies are terrible, people really need to start removing them, or at least learning how to update them.
> pkexec is installed by default on all major Linux distributions (we
exploited Ubuntu, Debian, Fedora, CentOS, and other distributions are
probably also exploitable);
I don't find it on any of the servers I manage, it appears to be installed with graphical desktop only?
Probably, It is used in things like NetworkManager. Which is used by almost all desktop environment.
In these desktop environments. Polkit is used to gating any remote process from accessing network state related functions (or anything that are not supposed to do remotely).
For example, you can use `nmcli` on the desktop or system termional(Alt+f1~f7) to disconnect the network or change to use other pppoe even you are not currently root(not using sudo to elevate the permission).
But if you try to call `nmcli` through ssh? No, No , No, Polkit will gate you from doing so.
So why do it like this instead of simply having PAM add a group (or not) depending on ash service one is logging into, and making authorization decision based on that group?
Groups are not granular enough. `pkaction` lists 315 different actions on the system where I just ran it. You'd need 315 groups to begin to reflect that level of granularity...
Groups are also not dynamic enough. When evaluating these rules, one of the inputs is whether the client requesting the action is a member of no session at all, or an inactive console session, or an active console session. You can't represent these with groups because you can't grant/revoke group membership to a process while it's running. (A process with a group membership can also stash away a setgid executable that can be used by the user to regain access to a group that they've been removed from later on, so it's not even possible to cast-iron-guarantee that access to a group has been revoked without inspecting the filesystem...)
I wouldn't suggest giving those permissions to your user because it opens up the possibility of a denial of service. With those permissions, any program running as your user can spawn lots of realtime threads that can take over the scheduler and lock the system up. This was detailed in the rtkit announcement, and preventing it is the reason rtkit exists: http://lalists.stanford.edu/lad/2009/06/0191.html
Maybe realtime audio is not important to you, and that's fine. But it's never as simple as "delete these things and now I have a secure system", you may be trading off security elsewhere to get that. Please also note that pkexec is not required to use polkit. You can remove pkexec and still have a functioning polkit installation and still use all those other daemons too. For a really secure system you may want to remove all suid binaries anyway and only use polkit or SELinux or something.
Nothing fake about it? That is one of the actions that RealtimeKit allows clients to request:
$ pkaction --action-id org.freedesktop.RealtimeKit1.acquire-high-priority --verbose org.freedesktop.RealtimeKit1.acquire-high-priority:
description: Grant high priority scheduling to a user process
message: Authentication is required to grant an application high priority scheduling
vendor: Lennart Poettering
vendor_url:
icon:
implicit any: no
implicit inactive: yes
implicit active: yes
In the default configuration that will be granted to clients that are part of a local console session, but denied to clients that are not (e.g., batch jobs, SSH). That policy can be further customized by the OS vendor, organization, site, or local admin in quite a flexible way.
Policykit's sole purpose is to provide an abstraction to let modern X server applications press a suspend or power off button. It's the same kind of garbage as DBus. The modern Linux desktop is absurd.
Yes, this is exactly why I don't run any of this crap on my distro. No dbus, no polkit, no systemd, nothing. Computer security is already enough of a nightmare without all this crap added on and linked in to everything.
Some programs can be configured to run without it. Others require patching to remove it. Some patches are trivial, others not so much. I've done a lot of patching, with still more required to get other applications running that I want to use. At some point I'm planning to build a "dummy" dbus library that can be linked against but actually does nothing at all, but I haven't gotten around to it yet.
Has bugs, is way too complex for the given functionality, and is completely unneeded in the first place--yes, get rid of the damn thing. Unless of course you enjoy getting "your" system OWNED and dominated by bad actors.
My custom distro beats the brakes off junkware like Ubuntu and (lol) Windows in startup time and responsiveness, and has all of the functionality I need, with half the code and as a result much fewer gaping security holes.
Computer security is an absolute nightmare these days. Intelligent people should be simplifying things and stripping everything down to the bare minimum, instead of stacking more crud on top of endless crud.
Those who fail to SECURE their systems and workflows will one day in the near future be surprised as shit to find that the entire "cloud" has been hacked and destroyed by worms and their system trashed right along with it. At that time, the world will be divided into two camps: computer owners (me and my kind) and non computer owners (everyone else.)
Who cares? If you don't take computer security seriously, you won't be computing much longer. Before it's over with, mine will be the only opinion still in existence. It's called "natural selection."
>is way too complex for the given functionality, and is completely unneeded in the first place--yes, get rid of the damn thing. Unless of course you enjoy getting "your" system OWNED and dominated by bad actors.
This is a rather nonsense statement. Polkit (or something like it) is needed if you want to have those macOS-style "program A wants to have permission to access privileged resource B" security prompts in the GUI. It's about as complicated as any similar solution needs to be for that use case. Perhaps you find these to be annoying and you disable them so they always succeed, but with that you've effectively given every program permanent suid root access. Definitely simpler, but can you say it's less of a security nightmare? I wouldn't. Yes there are risks of vulnerabilities in any security layer, but without them you've got no security layer at all.
If those checks always fail, you've now lost that functionality to do anything requiring elevated permissions and made your system less useful. You could get it back by installing a suid root tool like sudo/doas but that opens the same hole again that elevates these problems from a crash into a CVE.
I don't want or need popup permission prompts. If something needs to run as root, I run it as root from the console, as God intended. In the process I am assuredly avoiding all sorts of potential security vulnerabilities, such as this polkit code which is not installed on my system. Now get off my lawn.
Computer security really isn't THAT much of a nightmare for an average user. How many people do you know that got hacked lately, for any reason other than not using 2FA, or installing random garbage?
If you don't own cryptocurrency(That is more critical because it can't be reversed), you're probably way more at risk for physical theft than cyber crime.
In fact I think we are more secure than ever before because browser sandboxing actually works worth a crap, unlike 10 or so years ago.
The more you strip out of a system, the more manual work you need to do, and the closer you get to just a fancy version of a pencil. Technically, every line of code is a security risk.
But a lot of things just... are barely worth it when ultra simplified, and you start spending more time than you save at a certain point.
This bug is pretty bad, and I could see distros getting rid of it, but only with plenty of thought and analysis and maybe a replacement. They clearly put it there for a reason. Lots of stuff seems to need it.
And unless you use sandboxing or multiple accounts for different things.... if you have attackers running as your user, you are already screwed.
You're part of the second group I mentioned: the one that won't be computing much longer.
> Computer security really isn't THAT much of a nightmare for an average user.
"Average user" and "common idiot" are one and the same. Common idiots never see danger coming until it's too late.
> How many people do you know that got hacked lately, for any reason other than not using 2FA, or installing random garbage?
It's not about what has happened, it's about what easily CAN happen, and therefore WILL.
By the way, 2fa being forced down everyone's throat is not for your benefit. Notice how they never will allow you to use a voip number for 2fa? How could TPTB track your every move via GPS if you use voip?
> If you don't own cryptocurrency(That is more critical because it can't be reversed), you're probably way more at risk for physical theft than cyber crime.
LOL. Crypto is a scam. Bitcoin is going to crash to zero, and you're going to lose everything. Next TPTB will introduce their own Officially Approved digital currency, which is specially designed so that your account can be locked or restricted or emptied with the click of a mouse button, and so that you cannot possibly ever avoid any taxes.
You've got some tough lessons to learn about how the world works.
Meanwhile my use of physical, hard currency will keep me free and at liberty forever.
> In fact I think we are more secure than ever before because browser sandboxing actually works worth a crap, unlike 10 or so years ago.
If by "secure" you mean "in Google's firm grasp", you are correct. If you really meant "in control over your own computer", no, you are not.
Try patching Chromium to remove all the spyware and malware as I have done, and note how you and your browser are now treated as Enemies of the State by the Big Corp controlled internet.
> The more you strip out of a system, the more manual work you need to do
Freedom isn't free, nor is security.
> But a lot of things just... are barely worth it when ultra simplified, and you start spending more time than you save at a certain point
How would you know? You've never even tried to escape from the Goolag.
My system beats the brakes off yours in virtually every metric, especially speed and security, and has been worth every hour spent working on it.
> if you have attackers running as your user, you are already screwed.
You mean like the attackers you willingly give root access to your machine by allowing them to regularly stream arbitrary binary code to "your" (their) computer, and regular user access via metrics and update checks and every other sort of outgoing network connection on their schedule and not yours, any one of which could trigger a buffer overflow and code injection event? Yes, you are screwed six ways from Sunday.
If the world ever gets bad enough that I have to hide from Google and TPTB, your customized system will probably be contraband. In which case, I wouldn't want something like that, because I... don't want to go to jail, and I am rather certain they could find out if they wanted to.
Probably by machine learning looking for houses with an absence of pings to certain servers and using old fashioned police work from there.
Keeping that scenario from ever happening is a political issue. Perhaps it is in part technical too, but ultimately, people should not have to live like fugitives. For the same reason they shouldn't have to wear a guy fawkes mask in public.
And if someone does need to, they probably don't consider themselves to be free.
I may have never tried to get away from Google, but we did grow up poor enough to not have the latest tech for quite a long time.
It would be nice if it was possible and convenient, but a lot of things are still way behind.
When you add up all the details... it's probably more of a luxury than being rich in the gilded age, and it's accessible even to people like me who don't even make minimum wage when you take into account all the Ubers and Lyfts and crap.
With simple technology, one mistake and it's all gone. It doesn't help you out at all. Remember how this stuff was done 15 years ago? Nobody ever would trust computers for anything important. We all used pens and paper every day.
Every person I know who cares about privacy seems to need tons more analog tech than I do.
Lose your phone? Too bad, there was no Google page with which to track it and remote control it. Lose your wallet? Hope someone turns it in. There was no Tile.
Cooking and need to set a timer? Better wash your hands first and be careful not to forget in the time it takes to do so, or you'll make a mess and transfer germs when you touch the timer.
It would be a LOT of work to set up replacements for all of this while preserving privacy.
These things are only a few minutes per day, but collectively they are a big lifestyle change.
Eventually, open source will catch up. But it is slowed down by the fact that the FOSS community.... likes to shit on such things and doesn't want them to exist at all, and prefers ongoing manual involvement, and shits on most zero conf stuff, because they're so absolutist about security and minimalism.
You don't have Firefox or any browser? How are you posting? W3m? I would imagine that these have an enormous amount of bugs and security issues if parts of basic Linux programs are riddled enough with them by your standards.
That's worked pretty well e.g. for OpenBSD. Their code isn't perfect, but they've evaded lots of bullets simply by removing things they don't deem necessary.
I think I've evaded many bullets exactly the same way.
More code and more complexity -> more bugs, more holes. It's pretty simple.
A bunch of things on a modern desktop linux system depend on it. Disregard what the user you replied to said, as polkit is a system to delegate elevated permission grants from GUI applications.
A GUI sudo if you will, with XML and javascript code for its configuration files.
I'm not near my computer, but I would guess pipewire (as it usually runs within the users session) might rely on it to access the sound hardware without needing to run as root. But just guessing.
The only things on my system that depend on it are pipewire and xorg-x11-drv-intel (which I don't need). It doesn't sound like you should need a GUI sudo with XML and Javascript for audio..
PolicyKit is an application-level toolkit for defining and handling the policy
that allows unprivileged processes to speak to privileged processes, in order to
grant some user the right to perform some tasks in some situations. It is
sometimes referred to as "the sudo of systemd".
Sample uses:
Let the user Hibernate and shutdown the computer.
Let the user manage (Wireless) connections.
Let the user mount/eject a removable media (CD/DVD, USB keys...)
Let the user access devices, like audio, scanner, etc.
We already had a solution for this before: you add the user to the 'audio' group. And SELinux could do this too. But apparently RedHat just wanted another layer (https://lwn.net/Articles/258592/).
"This is better than groups and setgid processes, because it means someone can't log in over ssh and mess with another user at the console." - Because that's what desktop users are really concerned about. We need more complexity because somebody might hax0r my desktop over SSH.
And, wow, they really actually did use XML as their configuration:
So, not only is it superfluous, it also doesn't make the user's life easier, it's super annoying to configure, everything depends on it, and now the thing intended to improve security has caused a security issue.
Creating another group every time and asking the sysadmin to add you to the group when you want a new permission is not an appropriate solution for the desktop. It also isn't fine grained (what if you want to only grant permission to one audio device, then you'll need to create lots of audio groups and keep track of them all) and doesn't handle the case where you want to temporarily grant privileges to some device for just one session. There is more to it than just the issue with ssh, and it's not superfluous. There is a very good reason desktops all use it.
Even though the situation described is strange to the point of having never happened in history you would still need to ask an admin to write policy to implement your interesting audio permission scheme just the same as one would need to ask an admin to add a group or you know automate the process with a gui or integrate the change in groups into updating or software installation.
I am sure that somewhere having an actual programming language available vs list of what can and can't be run with or without a password would enable some additional power in terms of control of the system but I cannot for the life of me imagine a situation where it would be all that useful.
I agree it's not particularly useful for home users, I expect most would go with the defaults provided by their distro and leave it there. This is meant for corporate deployments where sysadmins might need to write more advanced policies.
What sysadmin are desktop users having to ask for permission to use their own hardware? Even in 2001, if you had a laptop, you had access to use all it's hardware. Why wouldn't you?
How many groups do you think there are? There's only so many classes of hardware, so there's only so many groups. About 8 in total. You add the user to all of them at once. It worked just fine before polkit arrived.
Why would you want to temporarily grant privileges to hardware once? Who is trying to prevent the user from using their own hardware?
I detailed this in another comment, the reason desktops use it is to get those macOS-style permission dialogs that pop up when you try to take some privileged action. I don't think any desktop distribution wants to ask users to open a terminal and type "sudo usermod" and then log out and log back in in order to do something like setting the clock or formatting a usb drive. I don't remember this working well at all before polkit arrived either, I remember when device hotplug in Linux was really broken for this reason (and a few others). It's not reasonable to ask desktop users to edit udev rules when plugging in a new device. If it worked well at all it was because you were doing things like having a lot of suid/sgid tools or just running GUI programs as root which is a terrible idea.
>Who is trying to prevent the user from using their own hardware?
I don't understand this question. The functionality here is equivalent to sudo, you type your password to authenticate a certain action. As the sysadmin you can configure some actions to always accept or always deny, if you want.
Yes, polkit does have some overlap with sudo. What it has over sudo is a real API, programs can use it to authenticate an IPC request for an action to a privileged daemon while that daemon is running.
Why isn't the audio device owned by the logged in user? udev could easily do that.
It'd be a problem if more than one user in logged in to the local console, in a multi head environment for example. But those are rare, and already have to solve the same problem for other console related devices such as mice and keyboard.
Sorry but if you keep falling back to the terminal to do things I would say you're not really using a desktop. What's the purpose of pointing this out? Yes, you can do whatever you want in Linux by opening the terminal and typing sudo. I understand the propensity of developers to like this because we spend all day in our xterm windows anyway but this is not the way anyone else expects a desktop to work.
Just to follow this discussion a bit further: If you have a task that /really/ needs elevated privileges you could turn it into a kernel module. That's great for you if you want to do that, but will you tell everyone else to develop kernel modules for every little thing? I don't think I would. I'm happy to give the muggles a better interface.
I have no "desktop" tasks that need elevated privileges. I only use a GUI because I want to run things like a browser and a media player. If I need elevated privileges it's always a one-off job, which means I need a commandline anyway.
There's a bunch of influential people that are bent on making "Linux desktop" be something that competes effectively with Windows and MacOS. Setting aside that I don't think those are particularly desirable objectives in the first place, I simply don't see it happening. Despite their deficiencies, Windows and MacOS work better than Linux desktops.
A lot of the Linux desktop effort seems to really be "Linux laptop" - Linux support for machines that are constantly moving from one hotspot to another, and constantly having storage and other devices plugged in and unplugged. That isn't my use-case. Most of my Linux machines are servers with no GUI. The one with a GUI doesn't travel, and gets something plugged into it maybe once a month.
I realise that my usage pattern isn't universal; I was just correcting the claim that "all desktops use it". You only need one counterexample to refute such a claim.
> There's a bunch of influential people that are bent on making "Linux desktop" be something that competes effectively with Windows and MacOS.
And not necessarily with the interests of Windows or MacOS end users, but more corporate interests.
I think a lot of Windows users for example were and would still be fine with a system that is effectively a single-user desktop. A permission prompt to prevent random apps from spying on you using your microphone and camera is probably a Good Idea for the average user but all this user policy business is just pointless; users themselves should always have access to their own devices anyway, just as they would on old Windows installs where the user was typically the only user and always administrator.
And yeah, I don't like that a few people get to define what exactly constitutes a desktop for everyone. Especially if under the guise of "this is what a modern desktop requires" they're free to turn the platform into a bloated, overcomplicated mess.. exactly the kind of thing I was happy to get away from when I left proprietary operating systems behind two decades ago.
I don't understand what you mean by a few people get to define it. This stuff is used by basically every desktop environment on Linux. You have to either use it or write something very similar to it if you want to have permission prompts that actually work. They all give the option to turn it off but they still have to support it for the average user you described. Unsurprisingly, the requirements for shipping a desktop are really not that different on Linux compared to other operating systems. The users all want the same things.
From what I have seen, the amount of users that want to go back to the Windows 95 style of security are an even fewer people. You can find distros that still ship a desktop from that era but they don't seem to be for much beyond novelty.
Why would I want permission prompts? Most systems are single-user systems; if you're logged in, you're the administrator, even if you haven't yet invoked your superpowers. Arguambly you should have to confirm if you want to do something dodgy; but if all you have to do is say "Yes, thanks for the warning", then you don't need any kits.
Really, I have difficulty imagining this group of Linux users who are constantly hot-laptoping, so that they need multi-user support sprinkled all over the OS. I can see that it's useful in a pair-programming environment, where you might have a lab or workstations with a standard config; but apart from that, how often does someone else log in to a desktop/laptop computer you normally use? Or one you own?
I don't think hotdesking and hotplugging are urgent consumer requirements. I don't think the people producing this stuff are aiming it at consumers.
> or write something very similar to it
Or use what was written before, if it matches your use-case. That worked, for many people. Still does for some.
Please don't speak for everyone. It's exactly this patronizing we-know-better-than-you attitude that makes users hate their corporate software vendors.
> From what I have seen, the amount of users that want to go back to the Windows 95 style of security are an even fewer people.
I knew someone would immediately reply with this straw man as soon as they saw mention of old Windows. I said user policies are pointless for a single-user desktop. It's irrelevant whether dave and samantha can access the audio device in john's session because dave and samantha don't exist on john's personal computer and he sure ain't running an ssh daemon for them.
>Please don't speak for everyone. It's exactly this patronizing we-know-better-than-you attitude that makes users hate their corporate software vendors.
I'm not speaking of corporations here, this is basically every current desktop environment that is shipping on Linux right now. They are all either using polkit or they use something very similar to it because the idea of it (user asks to perform an action, show a prompt) is very straightforward and pretty much universal for GUIs by now. Some of them may be business-oriented but some aren't. If this doesn't fit the definition of "everyone" using desktop Linux then who else are you considering? And just to clarify, I would say using sudo with a fine-grained config is roughly equivalent to polkit, although less convenient for GUI users because it doesn't have pluggable authentication agents.
>I knew someone would immediately reply with this straw man as soon as they saw mention of old Windows. I said user policies are pointless for a single-user desktop.
This itself is a strawman though. Polkit and sudo and such are not strictly about user policies although you can use them for that.
>If I need elevated privileges it's always a one-off job, which means I need a commandline anyway.
This is why polkit actions are the way they are, so you actually have a chance of being able to encode those one-off tasks into permissions for a GUI. It's not implemented for everything that requires root, and it probably won't ever be implemented for all of it but it's a lot better than it used to be. Part of it is improving because desktops like KDE made it easier to plug in new panels to the system settings, another part is that applications started using the higher level D-Bus APIs (like udisks2, timedated, networkmanager, etc) instead of trying to access the raw devices themselves.
>There's a bunch of influential people that are bent on making "Linux desktop" be something that competes effectively with Windows and MacOS. Setting aside that I don't think those are particularly desirable objectives in the first place, I simply don't see it happening. Despite their deficiencies, Windows and MacOS work better than Linux desktops.
I don't disagree with the last part here but, companies like Canonical exist and they get paid to ship this stuff. There are customers out there who want this, and they may very well be the ones paying some money or contributing maintenance towards keeping your browser and media player working on Linux. I don't know any overarching reason why these customers would deploy Linux instead of Windows, you would have to ask them.
>I realise that my usage pattern isn't universal; I was just correcting the claim that "all desktops use it". You only need one counterexample to refute such a claim.
Sorry but I don't think any usage of the terminal is a counterexample. That's just sidestepping the desktop, you could also do that from a VT with no GUI present.
> another part is that applications started using the higher level D-Bus APIs (like udisks2, timedated, networkmanager, etc)
Not the applications that I use! The machine in question doesn't have dbus or systemd. It only has one user. That layer of complexity is of zero value to me, but it's the very devil to get rid of it all.
> Sorry but I don't think any usage of the terminal is a counterexample.
If, on Windows, you have to perform a task for which there is no pre-made GUI app you can install, then you have to run-up powershell or cmd. My case is identical. I specifically referred to one-off tasks.
It's not my use of terminals that is the counterexample; it's the fact that I run a desktop without polkit (or anything-kit).
On Windows, if there has been value in putting those tasks in a GUI in the control panel, they will do it. It's the same deal.
Yes you can technically build a system without dbus or systemd or polkit or gettext or the C library or whatever it is you feel is superfluous. As you've found it is not actually difficult to do that, just tedious and impractical. You aren't gaining anything here by removing things. If you want equivalent functionality you're now tasked with building the equivalents, e.g. Android which is also a single user userspace for Linux without dbus or systemd, but has its own fairly complex set of high level services and IPC system.
> As you've found it is not actually difficult to do that, just tedious and impractical.
That is the opposite of what I have found; I find that it's "the very devil" to remove these components. And my finding is that the presence of these components is tedious and impractical, and that their absence makes my life better.
> You aren't gaining anything here by removing things.
That is condescending.
I've used machines with these services and I've used machines without. I find it's a gain to not have them. Who are you to tell me whether I do or don't gain anything?
FTR I don't have to build anything; there are alternatives, which I use. Unfortunately these new components are more-or-less rivetted-in, which makes it hard to remove them and replace them. Screws are better than rivets.
On my systems, the 'audio' group is empty. The ACL of the audio device (and other devices with the `uaccess` tag) is adjusted by udev when the owner of the active console session changes.
(I don't know if the scheme is able to revoke access to a running process, but it's still a step up from a single, static 'audio' group).
How many Linux users really expect a hacker to 1) be on their local network, 2) find a zero-day exploit in SSH, and 3) want to eavesdrop on them? I'm pretty sure I'd get struck by lightning while attacked by a shark before that ever happened
I feel like this whole thing is driven by corporate interests. It would make sense in a context where a machine has multiple users (or: anyone at work can use their credentials on any workstation), which is not uncommon in a work environment. It seems largely irrelevant for a single-user desktop.
It irritates me that the Linux environment is constantly growing more complex to account for scenarios that are not relevant for me, and it's hard to opt out. That complexity is not zero-cost; I've been hit by many a bug (and have wasted a lot of time working around..) related to things that exist on my system yet serve no real purpose for me.
I guess it's the year of the Linux desktop when it gets corporate enough, and those who want a comfortable free operating system will be looking for alternatives :)
Sigh... Because systemd, dbus, polkit, pulseaudio, rtkit, etc are invasive weeds. Apps now depend on them exclusively so often that you have to provide some shim to replace their ABI if you don't want to use those components. I can't remember the specifics but pipewire probably only casually references it as part of a compatibility layer. In Alpine I'm pretty sure you can run pipewire without polkit but I'd have to check.
Or it could be because those libraries actually do something and users want them? I really don't get these complaints. Is the C library an "invasive weed" because C programs require an ABI compatible C library to run?
They are invasive if they somehow end up on your system even if you don't need them and didn't ask for it.
The C library is something that I actually need, unlike a GUI sudo prompt for.. audio? I don't even know what such a prompt looks like because I've never seen one.
I'm sorry, now I really don't understand. If these libraries shipped with your distro, you asked for them. If they were dependencies of a package you installed, you asked for them. It's bizarre to me that there are hundreds of Linux distros with every combination of packages you could possibly ask for and I still see this complaints. It's very likely you didn't see a prompt because your distro configured it to not require a password. If you want to configure it to require a password, the system lets you do that. This is just another choice you have.
No, I didn't ask for a fucking GUI sudo with xml and javascript and local privilege escalation to root. I asked my computer to do something as basic as play sound, something that worked for decades without GUI sudo. Developers said they want to use pulseaudio for that. Whatever, if it finally plays audio without breaking every week. I don't have time to vet every package in every distro, and I didn't know it depends on a GUI sudo.
> If these libraries shipped with your distro, you asked for them.
If a bomb ships with a package you ordered, you asked for it.
Or maybe not? Maybe I didn't ask for it but a bunch of devs decided that (quoting you) "the users all want" it and I wasn't there to keep tabs on them.
And now that I know better, yes, I am looking for alternative distros because the ones I've been using include too many things I didn't ask for.
>I asked my computer to do something as basic as play sound, something that worked for decades without GUI sudo
Sure, security also was not great for decades. I know what you mean you don't have time to vet packages, very few people have time to do that, that's usually why you'd trust a vendor to do it for you and not keep second guessing their decisions because they published and fixed a CVE.
>I am looking for alternative distros because the ones I've been using include too many things I didn't ask for.
That's great, I wish you luck. Just keep in mind, eventually if you find you want to put a security prompt on something for whatever reason (maybe you find yourself shipping something to a less technically inclined user), I expect you will circle back around to the same solutions. They're there for you to use them. At that point it becomes whether the frustration with XML and Javascript is worth rewriting it with a different configuration format and scripting language. Maybe you also want to take these tools written in C and rewrite it in Go or Rust or something, I don't know. I would not say it's worth it unless you have some really extreme requirements. This doesn't to have the most expressive DSL you can think of it, it just needs to encode some simple logic in a well-understood way.
> that's usually why you'd trust a vendor to do it for you and not keep second guessing their decisions because they published and fixed a CVE.
Yes, I'm inevitably putting some trust in vendors. Unfortunately I'm having a hard time finding vendors (especially Linux vendors) that I can trust to make decisions that I find sensible and more or less in line with my intended usage of the system.
I have some experience with OpenBSD (after using it for more than a decade on a server and a few years on a laptop), and I can say with reasonable confidence that they would have never allowed polkit to be a part of their system in the first place. Similar to how they eventually said no to kerberos and just purged it. Similar to how they've refused things like PAM. Similar to how audio kept working fine with sndio (a very simple library & daemon) while I constantly had to battle the overcomplicated audio subsystem and ever-churning daemons on Linux..
That's the kind of Linux vendor I would like: a vendor who's trying to build something simple, and not something that tries to be maximally flexible and "everything for everyone". A vendor who can make decisions and if needed, build their own thing that suits their goals instead of shipping the same things every other distro ships.
There certainly are hundreds of distros as you say, but most of them offer little more than a different coat of paint, and ship the same third-party packages with more or less the same dependencies as you would have on any other Linux distro. After you've installed the few things you need, it doesn't matter much whether the banner says Arch, Fedora, Ubuntu, or whatever (in fact I run all three right now).
Removing it won’t have a huge amount of value unless you give untrusted people shell access to your system - if your personal user is compromised they will have pretty much obtained the Crown Jewels anyway. Where this exploit is valuable to hackers is situations like escalating from the www user or similar.
I'd guess it's because pipewire needs to access real-time capabilities of the kernel to enable low-latency audio, and those are only accessible as root sadly AFAIK (thus polkit, because pipewire does not run as root so there has to be something to grant the capacity to pw)
[~] compile helper..
[~] maybe get shell now?
The value for environment variable XAUTHORITY contains suscipious content
This incident has been reported.
Adding `GIO_USE_VFS=` to the end of `a_envp` (starting on line 56), fixes that for me on Fedora 34 with polkit-0.117-3. If anybody knows why that makes a difference, I would love to hear.
Same. Seems like the exploit wouldn't work for me. When I modify the XAUTHORITY line in the code, either to remove it or point it to my current XAUTHORITY value, I rightfully get a GUI password prompt before the root shell will open.
Why are they parsing argv by hand instead of using, say, argp_parse()¹? It’s even the seventh commandment of The Ten Commandments for C Programmers²: “Thou shalt study thy libraries and strive not to reinvent them without cause, that thy code may be short and readable and thy days pleasant and productive.”
Also by Henry Spencer, from How to Steal Code³:
“Even widely-available library functions often are not used nearly as much as they should be. A conspicuous example is getopt, for command-line argument parsing. Getopt supplies only quite modest help in parsing the command line, but the standardization and consistency that its use produces is still quite valuable; there are far too many pointless variations in command syntax in the hand-cooked argument parsers in most UNIX programs. Public-domain implementations of getopt have been available for years, and AT&T has published (!) the source for the System V implementation. Yet people continue to write their own argument parsers.”
Now, of course, we have argp_parse(), which also comes included in glibc, and is much better than getopt().
"better" is very subjective. If you just want short options, getopt code is shorter, far more portable and easier to write. Even if you DO want long options, argp is still not portable meaning that unless you only want to support glibc linux, you have to keep a local copy or rewrite or fallback from arpg.
I wonder why it even is a setuid binary since there already is a privileged service it interacts with (through DBus). I think we should replace all setuid binaries with a scheme of having a privileged service that acts on the requests of unprivileged processes. With Unix Domain Sockets and SO_PEERCRED the unprivileged process user can be identified (but less info is available than with a setuid binary). This could even work with sudo but the difference is that the privileged service would not spawn a child process of the unprivileged process but rather hand out the stdin/err/out FDs of the spawned privileged process to the unprivileged process (or vice versa, get stdin/err/out FDs from the unprivileged process and set for the spawned privileged process), again this works with Unix Domain Sockets.
Nope because pkexec already is a privileged process because it is a setuid binary. Being a setuid binary instantly makes it a privileged process, it's not related to whether it's similar to sudo and does authorization. What I'm saying is that the pkexec process itself doesn't need to be setuid, it should be an unprivileged process (also true for the /usr/libexec/polkit-agent-helper-1 helper it uses which is a setuid binary but doesn't really have to be when splitting this up in a daemon process).
Edit: Maybe to make it clear, yes, in theory the polkit project does follow the scheme of a privileged daemon process and unprivileged clients but in practice it doesn't because of the setuid polkit-agent-helper-1 and setuid pkexec programs.
You cannot accomplish sudo without setuid. Note that sudo means gaining privilege in the current context, with all its environment (including inherited file descriptors, the process group, etc.), not doing a privileged action at a distance.
> also true for the /usr/libexec/polkit-agent-helper-1 helper it uses which is a setuid binary but doesn't really have to be
Try making it non-setuid and see what happens.
(It will fail to check your password because most mechanisms for doing so, like the usual pam_unix, are only accessible to root.)
Right, process group and being child process gets lost when following this route. I think it's a compromise that is acceptable in many cases.
> [polkit-agent-helper-1] will fail to check your password because most mechanisms for doing so, like the usual pam_unix, are only accessible to root.)
That's what I mean, the helper itself could be unprivileged and hand the password over to a privileged daemon that does the check.
If you make the interface between unprivileged client and privileged server too complicated, eventually it will be more complicated than the interface of executing a setuid binary and potentially more likely to have bugs
I’ve really come to the conclusion that OS users are merely policy barriers and not security barriers (or at least, not strong barriers). This seems to be the position of Microsoft as well, given their stance on UAC and privilege escalation exploits in general.
I think it’s akin to real-life locks. Keeps good guys out, but not a determined attacker.
It's a safety / performance tradeoff that isn't well-constrained by the language or most tools. That's partially why it's a fragile and dangerous language.
If you're writing a serious kernel in C, you ought to have programmatic debugging assertion constraints for every parameter.
"We discovered a Local Privilege Escalation (from any user to root) in polkit`s pkexec, a SUID-root program that is installed by default on every major Linux distribution:"
I use Linux but do not use a graphics system (X11, Wayland, etc.). When I install, I always start by downloading a rootfs or a bootable image containing a rootfs.
For example, if installing Debian, I might start by downloading boot.img.gz
That would be an interesting argument. It is a bootloader (syslinux), the Linux kernel and an extensive userland, including dpkg and full set of root certificates. TBH, that is almost everything I need. I install a handful of additional programs, some static binaries compiled from personal source code archives, some programs from the Debian repositories, and I am good to go.
Perhaps it would come down to what exactly in the userland defines Debian as Debian. There are certainly differences in the rootfs as I go from one distribution to another.
It would be like arguing that NetBSD install media is not NetBSD. For me, it is absolutely NetBSD, just a smaller version.
