[HN Gopher] KDE6 release: D-Bus and Polkit Galore
___________________________________________________________________
KDE6 release: D-Bus and Polkit Galore
Author : milliams
Score : 148 points
Date : 2024-04-08 10:52 UTC (12 hours ago)
(HTM) web link (security.opensuse.org)
(TXT) w3m dump (security.opensuse.org)
| binkHN wrote:
| I don't know much about openSUSE, but it's nice to see the
| security effort that goes on before importing a large update like
| KDE6.
| brnt wrote:
| 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 :)
| creshal wrote:
| Complexity addicts come up with more complexity to handle the
| extra complexity of trying to wrap an excessively complex design-
| by-committee excess into another excessively complex framework.
| Yaaay.
| brnt wrote:
| The reviewed helped find the complexity and give pointers on
| how to reduce it, is the way I read it.
| genter wrote:
| How did you get your web browser to work in DOS?
| creshal wrote:
| 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.)
| _factor wrote:
| It's hard to sell enterprise support if your product is
| simple and easy to understand.
| bluGill wrote:
| The problem is everyone's 10% solution is different and so
| the complexity is easier than the sum total of all the
| others you would have.
| creshal wrote:
| 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).
| SSLy wrote:
| Finally some actual feedback. Which alternative IPC +
| capability delegation protocol do you wish linux used
| instead?
| enriquto wrote:
| > 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.
| freedomben wrote:
| > 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.
| gunapologist99 wrote:
| 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.
| freedomben wrote:
| > 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.
| tremon wrote:
| 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.
| freedomben wrote:
| > 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.
| kps wrote:
| 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."
| Scarbutt wrote:
| What do you use as alternatives to xdg-desktop-portal and
| its backends which require rtkit/polkit?
| bandrami wrote:
| 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.)
| lyu07282 wrote:
| 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.
| surajrmal wrote:
| 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.
| 1oooqooq wrote:
| 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.
| milliams wrote:
| 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.
| Cu3PO42 wrote:
| 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.
| kaba0 wrote:
| 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".
| tredre3 wrote:
| > 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".
| DEADMINCE wrote:
| > 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.
| vbezhenar wrote:
| 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.
| DEADMINCE wrote:
| > 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.
|
| [0] https://learn.microsoft.com/en-
| us/archive/blogs/uac/user-acc...
| vbezhenar wrote:
| Why would I do "alt-tab"? Do you think users typically
| type alt-tab when asked for admin permissions? I never
| did that.
|
| It's all security theater.
| DEADMINCE wrote:
| 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.
| asimops wrote:
| 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.
| asimops wrote:
| 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.
| aseipp wrote:
| 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.
|
| In contrast, on Linux, if you put a shell script in the
| users $PATH called 'sudo' that simply captures their
| password, you can immediately use that to elevate
| privileges anytime you want.
|
| 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. Please read up
| on it if you don't know how it works.
| DEADMINCE wrote:
| 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.
| Shared404 wrote:
| > Even the Windows desktop isn't as heavy.
|
| Have you used Windows recently[0]?
|
| 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.
| MSFT_Edging wrote:
| 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.
| not_your_vase wrote:
| 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.
| orhmeh09 wrote:
| Just FYI, XFCE has a dbus dependency, so it might not be what
| you are looking for if that's a problem for you.
| natrys wrote:
| 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).
| sho_hn wrote:
| 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.
| DEADMINCE wrote:
| > 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.
|
| Thank you for all the work you do!
| milliams wrote:
| 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).
| jraph wrote:
| 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.
| DEADMINCE wrote:
| Requiring MySQL for a desktop service running in the
| background honestly seems crazy to me.
| jraph wrote:
| 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.
| redeeman wrote:
| they used mysql embedded... many softwares on windows
| uses sql server embedded, for just specific applications
| bityard wrote:
| 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.)
| tredre3 wrote:
| > Pretty sure that is impossible with Windows.
|
| A fresh Windows 10 install on a system with 4GB of ram will
| idle at around 1GB used. Perhaps your comment is correct in
| regards to Windows 11, though.
|
| KDE6 has been pretty good to me, you should try it! Or wait
| for 6.1.
| dnAGged wrote:
| Why do you think KDE is not configurable?
| DEADMINCE wrote:
| 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.
| fooker wrote:
| Can you give a specific example of what you could do with
| Awesome WM that you can't replicate easily with plasma 5 or
| an available extension?
| xcv123 wrote:
| > Even the Windows desktop isn't as heavy
|
| 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.
| redeeman wrote:
| and probably kde 4.0 or 4.1, not the later releases where
| things were kinda good
| malkia wrote:
| Why was this not done with RAII -
| https://invent.kde.org/frameworks/kauth/-/commit/fc70fb0161c... -
| if there was an exception between here
| QVariantMap args; QDataStream s(&arguments,
| QIODevice::ReadOnly); s >> args;
|
| Then it won't restore the global. Also ... global ugh
| yarg wrote:
| 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.
| asimops wrote:
| 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.
___________________________________________________________________
(page generated 2024-04-08 23:01 UTC)