the actual end user security could get the same love.
the privilege escalation dialog is mostly a windows 10 copy, but just shows: allow dbus.something.something"? the name is always meaningless and have no parameters. and there's zero way to get more information. windows at least shows the binary or PowerShell command plus the arguments.
I agree, it always feels strange putting my root password into a box that just popped up. True, it's only ever been in direct connection with a command line program I'm running, but there's nothing hard linking the terminal with the GUI window.
I think that either the terminal program should print something like a PIN which is repeated in the window to cross-check, or the window should be able to use some restricted window manager feature (like Windows' fullscreen greying out thing) to prove that it's not just a random Qt/GTK window from an attacker's script.
The problem is that in a sense it is just some random Qt/Gtk window. I have recently written my own PolKit agent. It runs purely in userspace without any special privileges. An attacker could kill your legitimate PolKit agent, register itself as your agent, even act as one, and also steal your password the next time you do actually authenticate something. In that sense a PIN linking the command line to the agent window doesn't save you.
I agree this situation needs improving, the problem just runs much, much deeper.
On the other hand: if an attacker placed a modified sudo that steals your password in ~/.local/bin, it would also be Game Over. Much of the current security model breaks as soon as the attacker has code execution.
EDIT: I'd also like to highlight this:
> or the window should be able to use some restricted window manager feature (like Windows' fullscreen greying out thing) to prove
Your Wayland compositor also runs in userspace. Even if it is supposed to check that some calls come from euid 0, an attacker may be able to circumvent them if the attacker runs in the same context as the compositor. Again, the security problem runs very deep.
As much as I love linux, it is very painful to accept the state of “security”, this is beyond criminal. Especially that many people just put their head into the sand.
The age-old xkcd about linux being secure only about your video card driver is still true to this age, with no clear sign of improvement.
Also, frankly I don’t understand why there is no more cross-pollination between android and linux userspace - the former has actually solved this issue properly.
I’m afraid the answer is that “it is not written in c”.
> I’m afraid the answer is that “it is not written in c”.
I don't think it has anything to do with it. Android's security comes from design, not language. Each application runs under its own UID and not all applications can draw arbitrary content on your screen, for example.
Those things could be on the Linux Desktop. And maybe flatpak will bring it to us. But for now I can already hear the screeching about "freedom" and "the Unix philosophy".
> the window should be able to use some restricted window manager feature (like Windows' fullscreen greying out thing)
No FOSS desktop is even close to offering this. The windows 'greying out thing' is an entirely separate desktop instance, for example. A lot of security consideration was put into designing it. I don't think any FOSS desktop is working on anything even remotely similar, which is a shame.
What prevents any random Windows application to make a screenshot and apply "greying out" filter to it? I mean, I launch a game and it puts full-screen image of whatever it wants. It doesn't take any special permissions to make a screenshot either.
The only true security feature I remember was implemented in Windows many years ago. After you got security prompt, you would need to press Ctrl+Alt+Delete and type password there. Supposedly only Windows itself could handle that combination.
Nothing will prevent that. The question is, what would you do with the stolen credentials in terms of privilege escalation? Suppose we are in a situation where the UAC is on and asks for every action on the secure desktop. Even if you were to authenticate with the stolen credentials, you would end up in an unprivileged session due to UAC's token filtering mechanisms. If you were then to request elevation, the UAC would prompt the user on the secure desktop, which you cannot control from within the user session. It is therefore not enough to imitate the prompt. You also need to convince the user to accept the real prompt.
If you write a piece of malware that spoofs the secure desktop prompt, then you can steal the users password or whatever. But that does not grant you higher privileges. Only the secure desktop can grant your process higher privileges. The password only authenticates you. It does not authorize you. So now your malware tries to use the credentials it stole to perform a restricted task afterword, but it will not have the proper privileges (elevated security token), so the user will get forced into the UAC prompt on the Secure Desktop. You cannot stop this from happening once you attempt to do it. The exact scenario you are describing, spoofing the secure desktop prompt, was literally the basics of the UAC prompt thought up over 15 years ago. It's like the 101 example.
In contrast, on Linux, if you put a shell script in the users $PATH called 'sudo' that simply captures their password, you can (assuming the default PAM configuration) immediately use that to elevate privileges anytime you want with absolutely no intervention whatsoever. Because the password not only authenticates you, it authorizes you as well.
> What prevents any random Windows application to make a screenshot and apply "greying out" filter to it? I mean, I launch a game and it puts full-screen image of whatever it wants. It doesn't take any special permissions to make a screenshot either.
Because you would be able to alt+tab to other tasks, and that application would be able to still execute code as it was able to before. It's not any kind of security 'behind the scenes'.
> The only true security feature I remember was implemented in Windows many years ago.
Or perhaps you didn't realize all the engineering that was taking place behind just what you see. This[0] blog post gives a good overview of some of the security architecture that went into making that elevation prompt.
Honestly, MS has been leading the pack in OS security for some time. They are leagues ahead of MacOS and Linux.
It isn't security theater at all. Did you read the link?
You wouldn't be able to switch to another application is the point. What you suggest greying out, would easily allow other applications to hijack that prompt or replace it with their own.
That's a large part of what 'Secure Desktop' aims to prevent, and it succeeds at doing so.
That's not the point they were trying to make. They were asking what would prevent malware from imitating the UAC prompt to steal administrator privileges.
> If the policy setting is set to Prompt for credentials, malware imitating the credential prompt might be able to gather the credentials from the user. However, the malware doesn't gain elevated privilege and the system has other protections that mitigate malware from taking control of the user interface even with a harvested password.
So just knowing the credentials is not enough, they have to be used in the right context (the secure desktop).
It must be nice to get such a review of your code and design, and it looks like KDE appreciated it (probably they expected it, hence the early reach out). Kumbaya but non sarcastic :)
I'm positively surprised someone is looking at all so deeply into potential desktop local privescs, I just assumed the extreme complexity of your average default plasma desktop vs. the relative few users, meant it is probably full of vulnerabilities just not worth the effort of finding them.
These sorts of articles reaffirms to me that there is a dire need to switch to capability based security models. Managing the security with the set of tools we have available in the legacy model leaves lots of room for error.
The update doesn't seem too bad - but I did (initially) make the mistake of calling zypper from within KDE, which leads to a crash and leaves the system in an invalid state.
(ctrl+alt+f4 from the login screen allows you to get to a command line without starting KDE, and that allows for the upgrade to complete.)
I do think that this shouldn't be allowed; zypper should exit gracefully and inform the user how to safely perform the upgrade.
Why could zipper not update the stuff on disk, then prompt you to logout/login to load the new binaries? Windows and MacOS afaik don't require you to change to a tty to update the GUI.
I hesitate to use the word 'bloat', but ever since DKE4 with that Avahi service or whatever it was, that's the impression I've had of KDE. It almost feels like a separate OS on top of an OS.
I guess it's just not for me. About a year ago I discovered AwesomeWM and just how flexible and configurable it is - I can truly have a 100% completely customized desktop down to every detail.
Even without that though I'd probably opt for something like XFCE if I wanted something with a desktop and taskbar. There's just no good reason a desktop has to be as heavy as more popular options. Even the Windows desktop isn't as heavy.
KDE is definitely lighter than Windows, in both mental load and RAM usage. At least as of late Windows 10 and early Windows 11, which were the last times I used it with any regularity.
I'll stick with sway though for now, and I'm excited for the new Cosmic version coming soon.
[0] Recently is relative of course. It's been a while for me.
If you haven't revisited it since those days, Plasma 5 eventually achieved a reputation for being relatively light-weight - a default session was, at some points (maybe still is), lighter than XFce, getting it design wins on lower-powered ARM devices like the Pinebook at the time.
This was the result of projects like Plasma Mobile, and also the community intentionally focusing on hardware vendors and embedded as a growth area (as now seen with deployments like the Steam Deck or Mercedes-Benz cars).
Criticism of KDE 4 as bloated is well-taken, but we've since done quite a lot to repent :-) Disclaimer: I'm a KDE contributor.
> If you haven't revisited it since those days, Plasma 5 eventually achieved a reputation for being relatively light-weight - a default session was, at some points (maybe still is), lighter than XFce
That is very interesting! I will definitely give it another look. Is it still running that service that started with 'a'? What was the reason for that? I always found that so frustrating. I remember fighting with it to try and kill it or disable it way back in the day.
> Criticism of KDE 4 as bloated is well-taken, but we've since done quite a lot to repent :-) Disclaimer: I'm a KDE contributor.
I think you're thinking of "Akonadi", a service used for calendars, contacts, emails, RSS etc. It famously originally came with a MySQL server dependency (though I think that it might now work with SQLite).
I just checked, Akonadi still uses MySQL on Plasma 6. But you can probably disable it (in settings > background services > Account manager (translated from French so possibly not accurate)) if you don't use any PIM feature of KDE (contacts, mails). Now, it's quite idle, so one wouldn't need to worry about it I think.
Baloo, Nepomuk's successor, has also improved a lot and file indexing can be disabled, or folders excluded from indexing.
And I agree about Plasma being lightweight: that's what I run on a 12 year old tablet which has 1GB of RAM because it has been the only touch-friendly DE that was lightweight enough for years. Now, we have Plasma mobile and Phosh that might do the job better.
Apparently one can switch databases and use PostgreSQL or SQLite instead.
Not sure why SQLite is not the default. Maybe they expect several applications to write to the DB concurrently and expect that SQLite might cause perf issues. Though there's nothing in the doc about this.
Why? I mean, if there is a single, even slightly heavy db running for a desktop environment that would seem fine. Of course each service having its own is an overkill.
I moved to i3 then to Xmonad after years of Gnome, I felt similar, just too much junk.
Recently I set up a few new laptops and decided to try KDE as a "base layer" for various utilities I need, as its easier to install the DE and get the utilities as deps than download them all myself.
The annoying truth about tiling WMs that I ignored for years is man it takes so much time to get set up exactly how you like it. I could drop in my xmonad setup like I've done on other machines, but I want to try one of the wayland offerings and just the time commitment is making me put it off.
That being said, the most recent KDE plasma desktop is extremely snappy and polished feeling. More so than the windows desktop, and I feel like its 85% as smooth as say MacOS. I've yet to test battery life compared to a bare bones suckless tiling setup, but I'm still getting very good battery life without it.
I have not tried KDE 6 yet, but I have been running KDE 5 on Debian for about 1.5 years and with few exceptions, I find it to be fast, relatively bloat-free, and almost infinitely configurable.
On my systems, it uses something like 1.2 GB of memory out of the box. Meaning you have a _very_ usable machine even with only 4 GB of RAM, as long as you can avoid the temptation to run Electron apps. Pretty sure that is impossible with Windows.
I've tried basically every Linux DE and WM since I first started using Linux in 1996, and basically haven't been happier with the overall experience than I am now. Which scares me a little bit, because every time I get comfortable with a DE, someone decides to throw it all out and rewrite the thing from scratch. (GNOME 2->3, KDE 3->4, etc.)
I don't think they are comparable anyway, plasma is a desktop environment not a window manager. I mean plasma5 has an incredible amount of features, and it's extensible by Qt/QML widgets that are very easy to write. Sure you can say you don't really need its features, like it's bluetooth integration, its audio mixer, multihead display settings, notifications with individually configurable alerts, per-application or window customization, integrated screenshot and screen recording, MTP/NFS/SMB/etc. integration, file content fts, etc. etc.
And I'm sure you could achieve all of it somehow in awesomewm/i3wm/etc. but to me it just feels like a waste of time and a bad user experience. Perhaps I'm just getting old and rather focus on more interesting things than the configuration files of my window manager.
Disclaimer: I've been using Linux on the desktop exclusively since before Windows XP.
LOL. No. Try Window 11 then try KDE 5 or 6. No comparison.
You are comparing KDE4, a 10 year old release which was not well optimized.
KDE has become more efficient while Windows has become more bogged down and bloated with ads and telemetry and crapware. It is unusable before running a debloating script.
I don't know about Windows 11, but Windows 10 is still very snappy on old hardware with low ram. Windows has a lot of issues but desktop responsiveness isn't typically one of them.
No ads on my windows 10. Yes you have to configure it a bit after install, but once you do it can be pretty lean. I ran it on a machine with no more than 4gb for a few years and it was fine, clean and fast.
I feel you. I have become a sway and xmonad user on my machines after years of riding KDE. I was daily driving Neon (the official KDE distro) for about 2 years before I have had enough of the bloat and the general direction of the desktop env. I have a more and more stronger feeling that most of these projects are developed without an actual usecase. Which is fine of course, OSS is about scratching your own itch, not other's... but nowadays it's almost a sin to mention that something is buggy/unusable.
On the flip side, AwesomeWM or Xmonad users like us are stuck with Xorg for the foreseeable future. Maybe not a problem for here and now, but a concern in the long term for sure. Shame that the barrier to entry to creating an independent WM for Wayland is so high that very few exist yet and none that can substitute those two (yes I am aware of Sway).
I don't, but it, nor any DE like it come close to customizability when compared with AwesomeWM. It's not just about settings are available, I can hook into and change whatever functions I like, add custom code easily, replace every single aspect of the interface, etc.
Polkit is entirely redundant (dbus has its own permission system, not that you need it) and it's trivial to build a linux desktop without it. (None of my systems have it installed, e.g.)
Dbus is harder to replace, since the complexity addicts at Redhat and KDE decreed it to be The Default Linux IPC, but realistically, most programmers who think they need could do with a solution 10% as complex and 10x as fast. (dbus-broker is a step in the right direction, but not radical enough.)
Some of it is… impressive. “These side effects are also in some sense shortcomings of the D-Bus configuration scheme, since developers of a specific D-Bus service don’t expect that their configuration file has a global influence.”
DBus is really quite a magical place, I'm sure if you actually dig through how open source projects use it, you'll find that the vast majority of projects don't really interact with most of its features and just do the bare minimum the protocol forces them to declare (object paths vs object class hierarchies, dbus perms vs polkit perms, ...), or they're stuff that sounded like a good idea 20 years ago and hasn't been for 15 (defining its own data serialization layer, incompatible to everything else).
> Which alternative IPC + capability delegation protocol do you wish linux used instead?
Why "alternative"? Aren't file-based operations good enough? A program reads and writes data to files/devices, which it can or cannot do according to the permissions that it sees. From the point of view of the program, nothing else is needed beyond fopen,fread and fwrite. If finer control is needed, it's not for the program to implement, but for the OS to expose. An improvement to the dbus+polkit mess would be something that programs don't link to, something that is entirely invisible to programs beyond the possibility to open certain files at runtime.
> Why "alternative"? Aren't file-based operations good enough?
For some things yes, for other things no. If you're just making a basic config, yeah writing to a text file can be sufficient. Though, that requires defining a protocol/standard and following that. You could use a socket, but similarly that requires a protocol, possibly at multiple levels in the stack. Besides adding unnecessary overhead, that also loses all the OS-level information such as which user/privilege level is the caller running as? Now suppose you need it to be highly and quickly reactive (or what we used to call "event driven"). Suppose you also need to impose authentication and access controls. You could use the built-in file stuff for authn/authz, but not really event driven and most solutions to that are slow and bolted-on, and there's no pre-defined schema (so back to protocol defining). You could use socket but no built-in authn/authz.
I rejoice in simplicity, and strongly prefer it when possible. But limiting only to simple solutions means there's a lot of stuff you can't do, and when you need to do those things, this is not great.
And if you have to learn and use multiple solutions based on the level of complexity of the use case, then it may be simple from the dev's point of view, but it's certainly not from the operator's point of view.
But if we look at the operations that dbus is actually used for, they don't seem to be as complex as all of the capabilities that dbus provides.
It's like saying your init should basically be another entire operating system instead of just a service orchestrator; by reducing the API surface area, we not only increase security and decrease footprint, we also end up with composability and replaceable layers because other components might even be simpler but with the same API.
By defining this as a huge, complex problem that needs to be solved, the solution area naturally has to be much larger and encompass a far greater API and provide a lot more capabilities instead of the minimum capabilities to accomplish the far more limited goal.
Growing the problem domain and thus the solution is always a huge temptation but ultimately results in the opposite of modularization and good system design.
> But if we look at the operations that dbus is actually used for, they don't seem to be as complex as all of the capabilities that dbus provides.
I'm not sure this is true, certainly not for desktop users of Gnome and KDE. Just NetworkManager makes extensive use of D-Bus, and if you are writing an application that needs to care about (read or write) the state of the network, D-Bus is very useful and offers some powerful functionality.
On my Fedora machine I jsut ran `busctl list | wc -l` and got 175 (meaning 174 buses available), so it is being used quite extensively. Watching `sudo busctl monitor org.freedesktop.NetworkManager` is fascinating. I'm certain that there are applications using it that aren't using the full capabilities, but if it already needs to be in place, I don't think it adds complexity to use it for simple situations where a file might be sufficient. In fact I think somewhat the opposite. If everything were in D-Bus, there's only one place to look and you learn how to use it once and it's immediately useful for many things. If every application is using a homegrown/custom/bespoke IPC solution, you have to get into the details for every single thing. That sounds a lot more complex to me.
But that said, I bet we probably agree more than we disagree. If the application just needs to take in some configuration at runtime and doesn't need IPC, then using D-Bus is overkill and a bit cringey. I would much, much prefer a config file. If there's runtime changes though, that's where D-Bus starts to make sense to me.
I'm not sure what use case you're thinking of here. All requirements that you list are bread and butter for filesystem-based operations.
- which user/privilege level is the caller running as?
the kernel already knows this. Which file-based operation doesn't know the privilege level of the caller?
- highly and quickly reactive (or what we used to call "event driven")
inotify/fsnotify?
- impose authentication and access controls
built-in to the filesystem, or use SO_PEERCRED on sockets?
- and there's no pre-defined schema
What do you mean with "schema" here? Are you saying that /proc and /sys have no pre-defined schema?
AFAIK, the only thing that files cannot do by default is data broadcast: if you have multiple readers on a file or socket, only one of them will receive the data written. For that, you would need to keep track of the number of readers and give each (passive) listener its own connection.
> What do you mean with "schema" here? Are you saying that /proc and /sys have no pre-defined schema?
If all you're doing is reading/writing kernel stuff, then those will be sufficient. But if you're building a user-space service or daemon that will read/write to/from other user-space processes, then /proc and /sys don't help. If you want to use files you will have to agree and standardize on a format. For example, use YAML? ok, but which properties are mandatory, which are optional? What will their hierarchy look like? Even what is (are) the file name(s)? How do you handle adding/removing properties, maintaining backward compatibilty?
> inotify/fsnotify?
You can get a lot done with inotify and fsnotify, but there's a lot of overhead involved too. It is also somewhat fragile, some might say "hacky". It's certainly not something I would want to build on top of for a production important service. If you want a reliable Pub-Sub, (so for example, your new application1 wants to subscribe to a number of different types of events/notifications about network changes from Network Manager) you have to hope that NetworkManager is writing that to files, find out which files it is, register a watch on them, read them when they change, parse the data (and have to agree on a data format or "schema" with NetworkManager), and do your thing. Now want to send something back to Network Manager based on what you read? Gotta write to a file, and hope that NetworkManager is already coded to watch that file with inotify/fsnotify, and already agrees with the data format (or "schema"). When you control both sides it's not hard, but when both sides are completely independent with their own goals/priorities and preferences, it can get hairy. These are largely problems that go away with something like D-Bus.
Honestly just a wrapper that makes it easy for programmers to have RPC over unix sockets (spawn multiple with different ACLs for fine-grained permissions, if you really need to - but usually you don't. cap delegation is overrated).
And then pick any popular serialization library that is already supported in all languages and stick with it.
JSON would be nice for the easy users, but you do wany to exchsnge binary data over IPC, so that would maybe be a bit too simpld. I don't have any strong preferences when it comes to binary serialization/rpc protocols, though.
I can't speak for polkit, but in the absence of rtkit the gid/uid limits set in limits.conf work just fine even over a portal. I honestly never understood what was allegedly gained by moving that logic from one place to another. (For that matter the analogy with polkit and group permissions works for a lot of things.)
Wayland and snaps/flatpaks were more overly complicated mistakes, the alternative will be to go back to drawing board and not come back until there's a solution less stupid.
the privilege escalation dialog is mostly a windows 10 copy, but just shows: allow dbus.something.something"? the name is always meaningless and have no parameters. and there's zero way to get more information. windows at least shows the binary or PowerShell command plus the arguments.