_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Problems with D-Bus on the Linux desktop
wltr wrote 15 min ago:
Another one censored title.
rendaw wrote 6 hours 38 min ago:
Why is a generic bus protocol even needed?
Using http over unix domain sockets, or even making a simple protocol
over unix domain sockets with a size header + json payloads is trivial
in most languages. Unix domain sockets work with standard linux
permissions, you can access them with curl, you can forward them with
ssh, you can mount them in containers, etc etc. One socket per service.
D-Bus is an overcomplicated mess all over the place. You have services,
interfaces, paths, _and_ methods to classify messages yet messages are
still only partially qualified and rely on one connection per message
flow. There are return message ids, but some services use polling
instead. And even if you have D-Bus you still need to know
application-specific protocol details to make any sense of the
messages. Application protocols leak wire details into messages (i.e.
video access requests duplicate random dbus identifiers in payloads)
which makes handling dbus messages generically for e.g. proxying
impossible anyway.
moggers123 wrote 10 hours 22 min ago:
>Back when I was writing xdg-desktop-portal-hyprland
Bahaha. I could have guessed. My only interaction with D-Bus as a
layman is xdg-desktop-protocol. Is there just something about that
particular use case that makes it so... Obnoxious? I presume all kinds
of applications on my computer are right now busily d-bussing away
without my notice, but getting xdg-desktop-protocol working with
wlroots involved pentagrams and tomes bound in human skin.
jzer0cool wrote 11 hours 2 min ago:
Someone know any technique to watch what sent to the Dbus from running
A. I want to then redo and implement my own A. Welcome any steps I can
take.
jauntywundrkind wrote 11 hours 43 min ago:
this post has killed my interest in hyprland.
dbus is super frustrating to work with: yes!
but what we see here isn't an argument to convince technical people.
it's flaming. with no links, no references, just clipping things out of
context to make everything look as bad as it can.
dbus actually has policies! the gnome developers aren't saying: there
should be no security. they are saying: use the security boundary that
we have in place! use allow lists! deny lists! but like every argument
in this post, there are no hyperlinks, no references, no way to see in
depth what the situation really is: it's a hatchet job, designed not to
inform & illuminate, but to cast a shadow over & to conceal the real
depths of the issues.
this sort of behavior is garbage, and i have no interest in being in an
ecosystem with such fallen, misdirecting, bad behaving deceitfulness.
every one of these complaints bends and conceals the complexity of the
situation, far more than illuminates bad spots.
there's hundreds or thousands of people who are going to join this dark
crusade, going to bandwagon up & break out pitchforks. based off
incredibly incomplete misrepresentations of the situation at large.
this post is such a wicked harm bringer. this deserves quarantine,
needs containment.
notnullorvoid wrote 14 hours 46 min ago:
I was under the impression that the security concerns there are handled
by AppArmor and SELinux (though maybe not granular access control to
secrets). Which all desktop Linux installs should be using one or the
other, because there's much more than just D-Bus that can be a security
risk.
throw7 wrote 15 hours 10 min ago:
I never took d-bus seriously because they said that when dbus was
updated you could not just restart the dbus daemon, you were required
to hard reboot.
seba_dos1 wrote 18 hours 10 min ago:
While there is some valid criticism to be held against D-Bus and its
implementations (there's more than one in common use), this article
never goes there. It appears to be just an incoherent rambling of
someone with poor understanding of how systems work together.
Asooka wrote 19 hours 18 min ago:
One more thing: D-Bus has the concept of generic services which can be
automatically started, e.g. org.freedesktop.FileManager1. When you send
a command to that service, the file manager will be started if it is
not already running. However, there is no mechanism for the user to
select which file manager to start, so if you happen to have both KDE
and GNOME installed you have a 50:50 chance of launching dolphin or
nautilus. See for example: [1] . It truly boggles the mind.
HTML [1]: https://unix.stackexchange.com/questions/778028/set-a-specific...
seba_dos1 wrote 13 hours 26 min ago:
D-Bus has no concept of generic services. People are using D-Bus to
get automatic startup of generic services even though it's not fit
for this purpose. It's quite a different thing.
You could build a viable solution on top of D-Bus though, it's just
that apparently nobody bothered so far.
dolmen wrote 19 hours 18 min ago:
> An important part of adoption will probably be bindings to other
languages. The libraries are all in C++, but since they aren't very big
(by design), making Rust / Go / Python bindings shouldn't be hard for
someone experienced with those languages.
If the the protocol is that clean, make a formal specification for it
that can be used to generate client code.
A binding to C++ is definitely not what I want in my Go program.
candide771 wrote 19 hours 27 min ago:
I think this rant is more about Gnome than about dbus. Yes - there's a
lot of Worse is better ( [1] ) design in there.
And yes the default and in particular the glib implementations are
horrible.
The sdbus implementation is way cleaner.
The claims about "everybody can call everything" are just wrong. There
are bus policies and if you care you define them. That being said - the
desktop people don't care. But that's not a problem of the dbus design.
Look at CORBA or DCOM. You don't really want that either.
HTML [1]: https://en.wikipedia.org/wiki/Worse_is_better
smetannik wrote 19 hours 36 min ago:
Sometimes I feel that it would be easy to just take parts of Android
instead of reinventing the wheel.
pbalau wrote 19 hours 46 min ago:
I think this is missing the main problem with security on a Linux
Desktop, the user. All an attacker has to do is to convince the user to
run InstallSteamWithAllGamesUnlockedForFree.sh You know, the
AnnaKurnikovaSexTape.exe of the windows world.
This is an education problem and no amount of tech is going to fix it.
Even if dbus didn't have this problem, this is my hardware, I'll do
what I want! That's the whole point of Linux.
dijit wrote 18 hours 56 min ago:
nearly everything talks dbus, even browser extensions.
Itâs even more serious than running untrusted shell scripts.
pbalau wrote 17 hours 53 min ago:
That's not the problem. The real problem is that if I convince you
to run my script, it's going to be quite easy to convince you to
give me extra permissions, so I can get to your data. It really
irks me when things like Cargo are doing exactly that, make me run
a sh script. Cargo and the likes, are making running sh scripts way
too common.
juliangmp wrote 15 hours 51 min ago:
I assume you mean rustup, not cargo specifically or am I wrong?
dijit wrote 14 hours 58 min ago:
cargo builds/runs build.rs in the background
r_lee wrote 18 hours 34 min ago:
browser extensions? you mean like Chrome ones etc? never heard of
that being a thing
dijit wrote 18 hours 25 min ago:
plasma integration and gnome-shell integration do, and those are
open source so you can see for yourself.
Itâs also very common for password manager extensions like
1password and bitwarden.
ghusto wrote 19 hours 51 min ago:
> However, the best thing is this: any app on the bus can read all
secrets in the store if the store is unlocked
>> The GNOME project disagrees with this vulnerability report because,
according to their stated security model, untrusted applications must
not be allowed to communicate with the secret service.
I'd like to point out for anyone on the fence that yes, Gnome is run by
clowns in full sized clown shoes.
Spivak wrote 13 hours 37 min ago:
Program running as user can read data owned by user. If this is a
vulnerability then the entire linux userspace is compromised. Can you
believe that applications I run can execute gpg2 and steal all my
secrets?
The dbus process is run by and owned by your user. The only people
that can access it is you and root. There is a system-wide bus but
your secret manager isn't using that one.
It's just this:
HTML [1]: https://xkcd.com/1200/
wpm wrote 12 hours 51 min ago:
Itâs almost as if the user/group/everyone permission model
developed for time sharing mainframes isnât sufficient anymore
for absolutely everything anymore.
mikkupikku wrote 5 hours 5 min ago:
There's precious little evidence of these sort of things being
problems for linux desktop users, in practice.
Spivak wrote 11 hours 45 min ago:
Zero disagreement but GNOME I don't think is the one in a
position to fix this as I'm not aware of any implementation of
the better application level security model that doesn't require
a lot of kernel support.
yxhuvud wrote 10 hours 47 min ago:
For some reason the OS can manage to ask me about what windows
I want to screen share, but not about if i want to share
secrets between apps or not? I don't see how this require
kernel support - it just needs people recognising it as a
problem that is wanting to spend the time actually solving it.
Spivak wrote 2 hours 17 min ago:
I mean kinda yeah. Literally any program running as your user
can connect to dbus, grab your secrets and slurp your home
directory. Flatpak 'solves' this issue by putting the program
in a sandbox that can't talk directly to dbus and proxies the
messages with a filter.
The thing you need the kernel for is to attach meaningful
identities to programs and restrict them without needing to
sandbox them. And there is a ready made solution to this, one
that dbus is already aware of and can use natively. But on
systems where it's available a lot of users immediately
disable itâSELinux.
rcxdude wrote 14 hours 21 min ago:
This is especially amazing given how much of wayland friction is in
the name of security ("Why would we ever standardise a way to
intercept and send keystrokes? it's not secure!")
sigotirandolas wrote 6 hours 45 min ago:
The security model is that applications run in a sandbox (e.g.
Flatpak, snap) and only get D-Bus, Wayland, etc. access via
restricted means (e.g. xdg-dbus-proxy).
The "friction" is that Wayland developers don't want a sandboxed
application with access to the Wayland socket to pwn your machine.
Trying to isolate applications within the same UNIX user is
essentially unfixable since there's ptrace, LD_PRELOAD, /proc/$pid,
.bashrc drop-ins, etc.
The author must know about all of this, as it's mentioned in the
LD_PRELOAD note in the end. In my view, the model he proposes is
security by obscurity (putting hurdles on top of a fundamentally
insecure system).
rnhmjoj wrote 10 hours 3 min ago:
Yes, it's 100% a security theatre. Programs aren't even allowd to
set their own icon because it's not considered secure, I'm not
joking. The reasoning goes something like: what if a malicious
program set its name to "firefox" and uses the firefox icon and
then prompts you for the gmail password, eh?
At the same time a malware can just get all of your passwords
without even asking using d-bus or read all of your files since
it's running as your uid.
dadoum wrote 2 hours 12 min ago:
> Programs aren't even allowd to set their own icon
In GNOME. There is a protocol to set your window icon, and it
will be respected by the Wayland compositors which are
considering that there is value at having custom icons for each
window. GNOME also considers it's confusing to have multiple
windows from the same program with different icons, especially
since the only places those icons could be displayed on GNOME are
in the dock and in the Alt+Tab menu, but you pin apps to the
dock, so those custom icons cannot be displayed there when there
are multiple windows from the same app.
preisschild wrote 5 hours 29 min ago:
> At the same time a malware can just get all of your passwords
without even asking using d-bus or read all of your files since
it's running as your uid.
Thats not exactly true since this requires the application to
have permission to talk to the secrets service (if using Flatpak)
rnhmjoj wrote 5 hours 3 min ago:
Sandboxing on the Linux desktop is far from common and the
flatpak security is kind of a joke [1] [2], unless something
changed recently. For starters, it's the application that has
to ask to be sandboxed, so if I were to make a malicious
flatpak I will just ask for full file system access or d-bus.
[1]
HTML [1]: https://flatkill.org/
HTML [2]: https://hanako.codeberg.page/
akimbostrawman wrote 4 hours 0 min ago:
Flatkill is very out of date and disingenuous. Flathub is
very explicit and obnoxious about such unsafe permissions and
can easily be modified by the user. It's also amusing that
people here claim Wayland is a security theater too while
posting about flatpak being bad because it's vulnerable to
x11 issues.
No security boundary can prevent bad permissions just like in
android.
rnhmjoj wrote 2 hours 21 min ago:
> It's also amusing that people here claim Wayland is a
security theater too while posting about flatpak being bad
because it's vulnerable to x11 issues.
They both create an illusion of safety. We all know that
X.org had no security model and it sucks. Wayland put
restrictions that would make sense if the rest of the
desktop ecosystem was made with security in mind, but it
wasn't. I've heard way too many claims like "Wayland makes
keyloggers impossible" that are technically true but
irrelevant in the real world, because a desktop environment
is not just Wayland.
Flatpack is also misleading and its sanboxing is just not
great, regardless of the problem with X11.
> No security boundary can prevent bad permissions just
like in android.
Good bringing this up: in Android the applications ask the
user for permissions, in flatpak permissions are granted
based on what the developed asked. That's just bad.
preisschild wrote 4 hours 47 min ago:
HTML [1]: https://tesk.page/2021/02/11/response-to-flatkill-or...
skydhash wrote 17 hours 55 min ago:
I always thought as the secret for things that should not be saved
non-encrypted on disk, not for things that should be kept hidden from
other applications. And if that is your threat model, you should look
into virtual machines.
rnhmjoj wrote 9 hours 21 min ago:
There are no excuses, this protocol is just terrible: it could have
been made much much more secure without any kind of virtualisation
or sandboxing.
For example, the kernel could be used[1] to store the secrets in
memory and only authorize the userspace process that created it to
read it; other processes could request access to a secret and only
be given if you accept.
[1]
HTML [1]: https://docs.kernel.org/security/keys/core.html
WD-42 wrote 16 hours 2 min ago:
Thatâs exactly what itâs for. Parent is just being rude for no
reason.
tocariimaa wrote 18 hours 8 min ago:
"works as intended wontfix conversation locked"
Asooka wrote 19 hours 25 min ago:
Fortunately today with AI everyone CAN actually audit all the code
for all the software running on their machine themselves by sending
it to a black box cloud service, thereby running only software they
KNOW they can trust! /s
imiric wrote 19 hours 55 min ago:
> Back when I was writing xdg-desktop-portal-hyprland
Ah, yes, XDG "portals". The reason file selection and screencasting is
broken on every new Linux/Wayland installation I do, forcing me to try
to understand the insane matrix of supported, half-supported, broken,
and unsupported features by the dozen+ different implementations, and
come up with the magic configuration incantation that makes it work on
my system. Brilliant stuff. But it's secure!
> That is why, I've decided to take matters into my own hands. I am
writing a new bus.
Oh, goody. The author quotes xkcd/927 as if anticipating the response,
when it's exactly appropriate for this situation.
> For example, with wayland, when you switch, you abandon X. You cannot
run an X11 session together with a wayland one, simply not how it
works.
Huh? I use niri, and had to install both Xwayland and
xwayland-satellite to get some of my apps working. I have no idea what
either does, and even less interest in figuring it out, but it sure
sounds like some X compatibility layer. Please tell me more about how
much X, and now D-Bus, sucks.
I switched to Wayland a few months ago, and I'm happy that things
mostly work now, but it seems that reinventing the wheel is the M.O. of
developers in the Wayland community. Everyone is tired of everyone
else's shit, has a superiority complex as evidenced by this ranty
article, and has the urge to recreate literally every tool in the
ecosystem that works for their own specific use case. Case in point:
the dozens of tools that start with `hypr`. I guess we can add "tavern"
now to that, whatever the fuck it is.
I'm tired of the state and direction of modern Linux. I wish I could
use OpenBSD and leave this constant churn and bickering behind.
EDIT: Ah, it seems the author agrees with me: [1] They're pointing out
toxic behavior, favoring constructive criticism, and yet engage in the
same behavior they're criticizing. Wild. How we ended up with these
people as leaders in the Linux community is beyond me.
> An important part of actually advancing a product forward is to
cooperate.
100%. Maybe they should heed their own wisdom.
HTML [1]: https://blog.vaxry.net/articles/2024-linuxInfighting
zzo38computer wrote 11 hours 11 min ago:
> Ah, yes, XDG "portals". The reason file selection and screencasting
is broken on every new Linux/Wayland installation I do, forcing me to
try to understand the insane matrix of supported, half-supported,
broken, and unsupported features by the dozen+ different
implementations, and come up with the magic configuration incantation
that makes it work on my system. Brilliant stuff. But it's secure!
Is there some way to avoid such a mess (and other problems with XDG
portals and other XDG stuff) by substituting a .so file, somehow? I
don't really know enough about how it works to know whether or not
such a thing would work. (Maybe it might work for some programs,
depending on which libraries they use for this purpose.)
javier2 wrote 17 hours 21 min ago:
Hmm, screencasting is finally working properly for me now. It was a
loooong road...
1718627440 wrote 20 hours 3 min ago:
> The GNOME project disagrees with this vulnerability report because,
according to their stated security model, untrusted applications must
not be allowed to communicate with the secret service.
> Applications sandboxed via Flatpak only have filtered access to the
session bus.
While I see why they think this is a bad answer it really reminds me of
this: [1] . Also they did not cite the last statement in their quote
and made screenshots, so the quotes are not copyable. Who the hell
does that?
HTML [1]: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=3128...
ottah wrote 16 hours 8 min ago:
Wayland, thow shall not screenshot without root.
D-Bus, YOLo!
1718627440 wrote 15 hours 56 min ago:
I am not a fan of Wayland either, I rather want to be able to run
programs from different users against the same application server.
This works just fine on Xorg.
seba_dos1 wrote 13 hours 32 min ago:
Works just fine on Wayland as well. It's simply a Unix socket
that you can set permissions for, it's even easier than X11 with
its magic cookies.
chasil wrote 20 hours 16 min ago:
As I understand it, systemctl uses D-Bus to send commands to systemd. I
have read that systemd implemented their own D-Bus which is faster than
stand-alone D-Bus.
So this gives me pause:
'Ever seen kwallet or gnome-keyring? Yeah, these things. These are
supposed to be "secret storage" for things like signing keys,
passwords, etc. They can be protected by a password, which means they
are secure... right? No. No, they aren't. These secrets may be
encrypted on disk, which technically prevents them from being stolen if
your laptop is stolen. If you just cringed at that because disk
encryption has been a thing for 20 years now or so, you're not alone.
However, the best thing is this: any app on the bus can read all
secrets in the store if the store is unlocked. No, this is not a
#%&@ing joke. Once you input that password, any app can just read all
of them without you noticing."
So, how does systemd ensure that D-Bus commands cannot originate from
an unprivileged account?
Does systemd's D-Bus implementation use a different security
architecture than stand-alone D-Bus?
I admit that I don't know anything about these mechanisms.
HTML [1]: https://www.reddit.com/r/linux/comments/1lxd0hl/systemctl_vs_b...
tremon wrote 19 hours 27 min ago:
systemd accepts commands from the system bus (i.e. the dbus instance
running as uid 0). User desktops have their own session bus, which
runs as the user.
chasil wrote 19 hours 23 min ago:
Thanks, that makes sense.
Still, for user-level systemd, that means the bus is open to any
binary running with the user's credentials.
This is not any worse than the risk of running ssh-agent, though.
zokier wrote 19 hours 49 min ago:
polkit
wryun wrote 20 hours 18 min ago:
OpenWrt devs had this epiphany many years ago: [1]
#what_s_the_difference_...
(no endorsement implied; in particular, ubus has not much of a security
model, though OpenWrt has an excuse for that)
HTML [1]: https://openwrt.org/docs/techref/ubus
HTML [2]: https://openwrt.org/docs/techref/ubus#what_s_the_difference_be...
0manrho wrote 20 hours 19 min ago:
I sympathize, but also, the XKCD about Standards comes to mind:
HTML [1]: https://xkcd.com/927/
bsoles wrote 20 hours 12 min ago:
> A lot of people quote this xkcd comic for each new implementation.
However, this is not exactly the same.
Well... It is exactly the same.
egorfine wrote 20 hours 24 min ago:
I believe someone from systemd should reimplement d-bus in rust. This
way we can have all the things we hate in a single instance.
klooney wrote 20 hours 11 min ago:
[1] systemd already has
HTML [1]: https://varlink.org/
egorfine wrote 19 hours 51 min ago:
Problem is, varlink has been created to alleviate the pain while
what I'm looking for here is even more suffering. Perhaps add AI
and MCP into the mix. At kernel level with hard dependency on
sudo-rs. And local RPC should be blockchain-based.
phkahler wrote 20 hours 29 min ago:
Put OS calls on the bus. IMHO we need to add permissions to most
user-space APIs so apps don't need to be sandboxed in a VM for
security. Is this what SE Linux is? But I sometimes want permission to
be granted by the user. For example, I don't want programs to be able
to access files unless the user specifies the file - this might be
through direct interaction with a GUI, or if we're really smart/tricky
enabled if a filename comes on the command line typed by the user. I
hope this makes sense, a way to gate system access via normal user
input. Is this a reasonable possibility, or am I dreaming too big?
zzo38computer wrote 11 hours 16 min ago:
I think the way to do should be capability-based security. However,
that is suitable for a new operating system design (and computer
design, too, for some reasons).
For Linux, we can do something else, although something similar may
be possible. However, it seems that seccomp does not allow the
function to send and receive file descriptors, nor to wait for one of
any file descriptors in a set (like the "select" function), etc, so
it is rather limited, and will require another process to proxy all
of these functions. (Wikipedia says seccomp also disables RDTSC; my
own system design would not even have such a thing, because I would
want to restrict all I/O including high-precision timing; but I would
also want to restrict CPUID and stuff like that too.) Capsicum might
be better, at least for BSD (although I don't know if it disables
RDTSC or CPUID).
I had thought of making a sandbox library tha should not require many
changes to the program (although some changes will be needed); this
can be used to specify the permissions needed involving files, popen,
command-line arguments, network functions, timing, etc, and functions
to request input in various character sets, and to request other
things as well such as file names, and the host name and port number
when connecting to internet, etc.
wpm wrote 12 hours 40 min ago:
This is more or less how a lot of it works on macOS via the
âTransparency, Consent, and Controlâ subsystem. Even
non-sandboxed apps cannot just go rooting around my Desktop without
the OS throwing a popup up asking me if itâs ok.
mahkoh wrote 20 hours 31 min ago:
>Back when I was writing xdg-desktop-portal-hyprland, I had to use a
few dbus protocols (xdg portals run on dbus) to implement some of the
communication. If we go to the portal documentation, we can find the
protocols.
>[...]
>None of the apps, I repeat, fucking none followed the spec. [...]
>Fun fact: THIS IS STILL THE CASE! The spec advertises a
"restore_token" string prop on SelectSources and Start, where no app
does this and uses "restore_data" in "options".
Wrong. xdg-desktop-portal has a client API and a compositor API. In the
client API the property is called restore_token [1]. In the compositor
API the property is called restore_data [2]. Clients do not talk
directly to the compositor, they talk to the xdg-desktop-portal
application which then talks to the compositor. It is not surprising
the the properties would not be called the same.
In the documentation the APIs for app developers and desktop developers
are clearly separated on the left hand side [3]. Not only does this
have nothing to do with DBus (it would apply to every API where a
middleware is used to translate messages), it also shows that the
author did not do his due dilligence.
[1] [2]: [1]
HTML [1]: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.free...
HTML [2]: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.free...
HTML [3]: https://flatpak.github.io/xdg-desktop-portal/docs/
Sprocklem wrote 16 hours 25 min ago:
> It is not surprising the the properties would not be called the
same.
It is a bit surprising that xdg-desktop-portal has two very similar
APIs that differ in non-obvious and seemingly-arbitrary ways. I was
also a bit confused about how the two APIs correspond (or donât)
when I first read their documentation.
peanut-walrus wrote 20 hours 32 min ago:
So everyone has wanted "year of the Linux desktop" for a while. This
year, since Microsoft has decided to call open season on their own feet
and Valve has taken a break from swimming in their money pool to make
sure absolutely any piece of software ever written can run on Linux, it
looks like this might actually be happening. I am seeing a massive
influx of new users, driven by distros like Cachy, Nobara, Bazzite. A
lot of them don't have previous Linux experience and are generally not
the most technically savvy users.
This absolutely terrifies me. Linux desktop security is, to put it
politely, nonexistant. And the culture that goes with Linux desktop
users just makes things worse, there's still a lot of BOFH gatekeeping
going on, laughing at the new users when they inevitably mess something
up and worst of all, completely refusing to admit that the Linux
desktop has security issues. Whenever a new user asks what antivirus
they should run, they are usually met with derision and ridicule,
because the (oldschool) Linux users genuinely think their computers are
somehow immune and can never be hacked.
The first cybercriminals to put some development effort into Linux
ransomware/stealers are going to wreak havoc and a lot of people are
going to be in for a rude awakening. The D-Bus issue with secrets in
the article is just one of many many many ways in which Linux desktops
are insecure by design.
There are of course distros out there that take security seriously, but
we are not really seeing new users migrating to Qubes en masse.
Edit: not calling out the distros above in particular, all 3 are doing
very good work and are not really any worse in security than most other
distros.
Dylan16807 wrote 20 hours 17 min ago:
Any windows program you download can steal all your secrets too. The
only operating systems that isolate programs by default are on phones
(and chromebooks).
peanut-walrus wrote 20 hours 9 min ago:
Unless you give it admin permissions, it really can't (admittedly,
a lot of Windows users do run their computers with their admin
account by default). Also, Windows users generally have at least
some kind of anti-malware running, which, while not perfect, does
work well against most spray-and-pray malware out there.
Edit: did some research, I must correct myself, the stealers have
indeed evolved so admin permissions are not required for most
credentials on Windows either.
However, should "strictly speaking, not really worse than Windows"
be the security target we aim for in Linux?
tredre3 wrote 19 hours 39 min ago:
All your data is owned by your user. If you run a program, it
will have access to all your data. Admin or not is irrelevant
here.
The keyring is pretty open on Windows, if you know the key you
can request anything even if stored by another app. There is a
way to lock a secret to a specific app but it's not properly
enforced in most versions of Windows.
The only user data that would require admin privilege is that of
sandboxed Windows Store applications where even the owner can't
access it directly from outside the program and you have to be
admin.
zzo38computer wrote 20 hours 32 min ago:
I do not like D-Bus either, and I do not like JSON either. Some of the
problems are the ones mentioned there, and it has many other problems
as well (one of these is that its use of Unicode can cause problems,
but there is a lot more problems than just that). I do not agree with
the solutions mentioned there either, although they do make some
improvements, there are also some problems.
A better way would be a different operating system design, although
without that, you can still improve it on Linux. I think putting
secrets in the message bus is not really the way to do sandboxing
properly, and I think there should not be a global message bus (it
should be specific to a program; if the program is properly sandboxed
it can be limited what it can access, and possibly they can be declared
by the use of environment variables, although).
There are also problems with the existing sandboxing systems; e.g. some
do not work properly with character sets and might not support such
things as: popen, command-line arguments of the program to restrict
which files can be read/written, etc.
For security for programs running on the same computer communicating
with each other while they are running, cryptographic algorithms are
probaly not the way to do it; the operating system should handle the
security to prevent programs from seeing and/or tampering with
something that it is not supposed to do, so that the communication
between programs is prevented unless it is configured to allow it.
For the data format, I might use DER (or SDER for the fields that are
not required to be in canonical form, since canonical form does not
matter for all fields but for some it might matter).
(The implementation would prevent messages from being sent to or
received from whoever it is not supposed to be allowed to do, by
checking the permissions and/or by just blocking access, forwarding the
messages to proxies that might modify and/or log them, etc; such things
can potentially make the system more versatile.)
mongol wrote 20 hours 33 min ago:
Could not MQTT form the base of a new desktop bus? At least one half of
it. It does not specify everything, but would it not be good
foundation?
0x457 wrote 18 hours 11 min ago:
MQTT solves the transport, which really isn't an issue. It solves
nothing beyond that.
BeetleB wrote 20 hours 36 min ago:
> D-Bus was introduced by GNOME folks about 20 years ago. For software
made only 20 years ago, as opposed to 40 like X, it's surprisingly
almost equally as bad.
I dunno man. Emacs is awesome.
yxhuvud wrote 10 hours 44 min ago:
Plenty of the implementation not so much, however.
Gualdrapo wrote 20 hours 25 min ago:
I don't think they implied that old software is always bad.
anthk wrote 20 hours 36 min ago:
DBUS -> Crappy COM
SystemD -> SVCHost.exe
Iproute 2 -> You like netsh.exe?
Gnome 3, 4 -> Windows 8 wannabe
Mono -> C# road building path
GConf -> Windows Registry; heck, dconf-editor and gconf-editor look
really close.
Can't wait for MMC.exe and GPO editing under Gnome.
viraptor wrote 20 hours 40 min ago:
> This means that when "/usr/bin/firefox" sets a
"passwords:superwebsite.com = animebooba", an app called
"~/Downloads/totally_legit.sh" can not see ...
It will be interesting to see how it treats symlinks in this case. Or
specifically, will this idea break completely for nixos or not.
wpm wrote 12 hours 43 min ago:
Keychain ACLs on macOS use the codesigning requirement of the
executable requesting the secret.
GalaxyNova wrote 20 hours 38 min ago:
My guess is it will keep track of the PID
viraptor wrote 20 hours 31 min ago:
PID changes with every execution. How would it help when preserving
configuration data?
pjmlp wrote 20 hours 46 min ago:
D-Bus is the closest Linux desktop has from XPC, COM, Android IPC.
Maybe it should be treated better, not rebooting it every couple of
times.
The problem is naturally the Linux desktop fragmentation that hinders a
proper full stack approach to application development.
What works for GNOME is useless for KDE, and what works for KDE is
useless for XFCE, which is ignored by Sway and so forth.
bjourne wrote 16 hours 5 min ago:
D-Bus is over 20 years old so a reboot is in order. All this guy's
gripes are not legitimate, but many are. However, upgrading desktop
infrastructure is just as much about influence (clout) and "social"
excellence as it is about technical exellence. A new ipc mechanism
that is not backed by the major players has no chance.
continue-100 wrote 13 hours 41 min ago:
I'd argue vaxry _is_ a major player, what with the rise of
omarchy.org and r/unixporn, popularizing hyprland enough for him to
have enough momentum to publish standards for this new era of TWM
linux desktop.
Conan_Kudo wrote 9 hours 17 min ago:
Being a major player in the Linux desktop community is what
drives success for these sorts of things. And he's not there
right now.
For the most part, there's a large ecosystem split between tiling
window managers and everything else, and the former is super-tiny
in terms of desktop developer reach.
jabl wrote 20 hours 33 min ago:
> What works for GNOME is useless for KDE, and what works for KDE is
useless for XFCE, which is ignored by Sway and so forth.
KDE had their own IPC thingy, DCOP, but it has been replaced with
D-Bus.
pjmlp wrote 19 hours 55 min ago:
Yep, using Linux in various forms since 1995.
tguvot wrote 20 hours 37 min ago:
actually kde has kparts which are somewhat like com.
prior to d-bus kde used to use dcop.
pjmlp wrote 19 hours 52 min ago:
It does, but again only usable by KDE apps.
c-hendricks wrote 20 hours 28 min ago:
God I loved kparts, but wasn't that more the idea that everything
should be embeddable?
> KPart technology is used in kde to reuse GUI components ... By
using kparts in applications developers can spend less time
implementing text editor or command line features, for example and
just use a katepart or a konsolepart instead.
HTML [1]: https://techbase.kde.org/Development/Tutorials/Using_KPart...
Gualdrapo wrote 20 hours 22 min ago:
Yes it is, but since "KDE 5" I've seen less of it. Besides the
obvious example of Konqueror another great example of it was
reKonq, which used Akregator, Okular and Kget to handle RSS and
PDFs respectively (all within the reKonq window).
Now not even Falkon does that.
seba_dos1 wrote 13 hours 45 min ago:
Just from the top of my head that I've noticed as a user:
several apps, such as Dolphin or Yakuake, use konsolepart;
KWrite uses katepart, and Ark uses various parts in its file
preview.
$ ls -1 /usr/lib/qt6/plugins/kf6/parts | wc -l
20
GalaxyNova wrote 20 hours 44 min ago:
The fragmentation is a natural consequence of different use cases
existing.
You can't have your cake and eat it too.
pjmlp wrote 19 hours 54 min ago:
Which is why in the end, WSL 2.0 is the Year of Desktop Linux,
while Android, WebOS and ChromeOS commonality is the Linux kernel,
not userspace.
danans wrote 12 hours 22 min ago:
> ChromeOS commonality is the Linux kernel, not userspace.
ChromeOS has a Linux userspace fully integrated via it's Crostini
VM.
pjmlp wrote 10 hours 28 min ago:
Partially, because not everything actually works, depending on
the Chromebook model.
Great if everything that one wants from their GNU/Linux
experience is a command line and TUI.
Starting a 3D accelerated GUI app? Well, it depends.
danans wrote 1 hour 33 min ago:
> Great if everything that one wants from their GNU/Linux
experience is a command line and TUI.
Regular GUI apps work fine on ChromeOS. There's a flag to
enable the GPU in the VM and with it, 3D accelerated GUI apps
also mostly work. It's not optimized for gaming if that's
what you are referring to though.
supportengineer wrote 20 hours 51 min ago:
> "Everyone has heard about D-Bus"
I have never heard of D-Bus until today.
GalaxyNova wrote 20 hours 52 min ago:
> any app on the bus can read all secrets in the store if the store is
unlocked
Holy shit. I knew conceptually that this was the case but never really
took the time to consider the implications.
Pretty much whenever you unlock your keyring all your secrets are
accessible by any software that can connect to the bus... How is this
acceptable? Are we just supposed to run everything as Flatpak?
mx7zysuj4xew wrote 11 hours 55 min ago:
It's acceptable because flatpak dbus and all its ilk are too opaque
for the average "experienced" user to fully grok. The problems are
there, but the situation is so convoluted that it's hard to build a
mental model unless you truly understand the overall system
architecture
jeroenhd wrote 19 hours 43 min ago:
Funnily enough, my work macOS keychain maimed itself in such a way
that I need to recreate it every time I install an OS update. Every
time I recreate it, the OS spends a few minutes in a state where
every application that needs access to the secrets store requests
access through the keychain's password. Incredibly secure!
Turns out, that's every application, every few minutes, many of them
multiple times. Applications like having access to things like
refresh tokens so they can download your email, or discover passwords
for offering autofill for a website.
I'd welcome many improvements to the Linux status quo, but
applications not needing to ask before accessing the bus is the only
reason it's usable in the first place.
throw_await wrote 20 hours 9 min ago:
keepassxc asks before giving out secrets
XorNot wrote 19 hours 51 min ago:
Most people disable that.
The reality is no one wants to be prompted everytime for a
password. They want it to auto fill.
In complaining about this people are setting the boundary at the
wrong place, and in proposing solutions assuming user behavior
which doesn't exist (they will absolutely click "yes trust random
application I'm busy move along now please").
I do not want to be prompted. I do perhaps want grades of secret
access but even then thats asking a lot - do you want my SSH keys?
Well yeah I probably want to give them to you some app which is
automating things over SSH. It's 5 more versions before you get
updates to ship them all to Russia or wherever after an author hand
over.
bflesch wrote 21 hours 1 min ago:
The problem with dbus is also that all these nice browser extensions
that integrate websites with gnome/kde talk over dbus. These dbus APIs
had several DOS vulnerabilities, some of which could be triggered by
visiting any website. It is unacceptable that my desktop environment
crashes just because something floods the dbus API, even moreso if it
can be triggered by visiting a website.
So if you are a security researcher, dbus is a very worthwhile entry
point if you want to improve some open source software :-)
psanford wrote 14 hours 27 min ago:
What browser extensions? Why would I want websites to integrate with
gnome or kde? What does that even mean?
stefanfisk wrote 13 hours 5 min ago:
Isnât this bad boy installed by default in most Gnome distros?
HTML [1]: https://chromewebstore.google.com/detail/gnome-shell-integ...
airhangerf15 wrote 13 hours 21 min ago:
I'm guessing the poster meant the USB and Bluetooth browser
protocols (which I still find insane how anyone thought those were
a good idea, but it's literally the only way to configure some
keyboards today).
anthk wrote 20 hours 28 min ago:
Not an issue with a standalone VM :D
dijit wrote 19 hours 1 min ago:
Now you have two problems.
anthk wrote 6 hours 46 min ago:
s,VM,WM, sorry. No, not two problems; I can always spawn whatever
tool requiring dbus
with dbus-launch while keeping my window manager aside.
antiloper wrote 21 hours 3 min ago:
Raises the obvious question of why not using the wayland protocol (on
another socket, not on the compositor socket). It has mature
implementations in many languages, an IDL with compilers, and every GUI
application is already going to link to libwayland anyway.
(Or perhaps even COM)
bayindirh wrote 18 hours 57 min ago:
vaxry has a beef with Drew Devault, who called him out and exposed
his behavior when not writing code.
Considering a sizeable part of Wayland's low-level stuff is written
by Drew back in the day, vaxry won't touch anything written by Drew.
This "protocol" effort is to further decouple Hyprland from Wayland
infrastructure.
Like everything, this effort is again driven by ego and spite.
wolvesechoes wrote 8 hours 31 min ago:
Peak FOSS experience
grimblee wrote 11 hours 24 min ago:
Now that's the info I missed, I knew the hyperland devs have a bad
reputation so I was wondering what was not being said , thank you
good sir.
TuringNYC wrote 21 hours 4 min ago:
For a second, I thought this was about Deutche Bank's central markets
messaging bus, also called D-Bus. So many memories...
senko wrote 21 hours 7 min ago:
A gold standard behaviour for when you want to replace a disfunctional
tool/system and will require buy-in from a wide community, is to behave
like Charlie Marsh did with ruff and uv.
He didn't barge in guns blazing proclaiming "pip is a disgrace" and
"it's a fuckin joke". He wrote a tool that was much better and
encourage others to try it. Within a year or so, it snowballed into an
unstoppable change.
This project currently has a bunch of C++ files, no docs, no tests, no
roadmap on how it might replace d-bus, nothing. And as another
commenter pointed out, starting a new system service in 2025, yelling
about security, and doing this in an unsafe language doesn't inspire
confidence.
Lennart Poettering, Theo de Raadt and Linus Torvalds may get away with
talking like this, but if you seriosly want to bring a wide community
on board (without which the entire thing is a non-starter), look to
Charlie instead.
Oh, and also, if you think D-Bus is bad, consider yourself lucky you
didn't need to use the thing it replaced - CORBA.
p_l wrote 15 hours 14 min ago:
At this point I would like CORBA back.
tosti wrote 6 hours 38 min ago:
Yes! And always put the network first. Some kind of "network object
model environment" is needed where servives can be somewhere on
your network.
It just needs a catchy name.
parsimoniousplb wrote 13 hours 55 min ago:
That would be Cap'n Proto RPC
javier2 wrote 17 hours 42 min ago:
Aint that the truth. D-Bus isnt that terribly shit either, we just
need to solve this SecretManager issue...
Asooka wrote 19 hours 7 min ago:
Similarly I wish open-source devs who wish to extend and improve
existing tech take a page out of Microsoft and do their Embrace,
Extend, Extinguish tactic. Like: "Here is my new D-Bus
implementation, it has a couple of extra bells and whistles, which I
need for my project, and is faster. Oh I have added more security,
you don't have to use it right now, but some services will require
it. ... Security is now mandatory. ... The protocol is now called
Wire and if you need D-Bus, you can run this legacy translation
layer. ... The legacy translation layer is no longer installed by
default, but will be maintained for those who need it. ... It has
been 30 years since anybody has needed D-Bus, we are no longer
maintaining the translation layer."
Which is kind of what OP is doing, but less directly inflammatory. I
wish him all the luck regardless.
GalaxyNova wrote 20 hours 50 min ago:
> This project currently has a bunch of C++ files, no docs, no tests
I think the more important thing is the protocol itself, rather than
the specific implementation. As the author notes the current D-bus
standards are substandard at best.
forty wrote 20 hours 18 min ago:
I think one of the point from your parent comment is that something
that works for people is a powerful way of making things happen,
much more powerful than rants or theory or protocols. I also
noticed that with cryptography algorithms/protocol for example:
design the most amazing algorithm - no one is going to use it ever
if there is no great reference implementation people can use.
senko wrote 20 hours 29 min ago:
I can get on board with that if there's a protocol spec - at least
a draft or something more tangible than "it's a tavern".
I just see a bunch of undocumented C++ code here.
Terr_ wrote 21 hours 10 min ago:
> Ever seen kwallet or gnome-keyring? Yeah, these things. These are
supposed to be "secret storage" for things like signing keys,
passwords, etc. They can be protected by a password, which means they
are secure... right? [...] any app on the bus can read all secrets in
the store if the store is unlocked.
Well, TIL. Looks like the default GUI for that is `seahorse`, so let's
see what I've got on a relatively fresh installation... Looks like
mostly Chromium stuff where there's a key that unlocks something more
application-specific (e.g. for Discord) and an access token for my
JetBrains account.
So no plaintext passwords per se, but now I wonder what a malicious app
might uncover if it pursued the local Chromium stuff.
XorNot wrote 20 hours 7 min ago:
Where do you think those secrets are going to be stored otherwise and
how are you planning to authenticate to them?
If you're not entering a password at some point, then they're in
memory and available to all anyway. If no system prompts or notifies
you access is happening, then it's irrelevant what software
machinations might be governing this.
pseudalopex wrote 18 hours 47 min ago:
> If you're not entering a password at some point, then they're in
memory and available to all anyway.
They entered a password to log in probably. And Linux had a setting
to restrict ptrace since years.
Terr_ wrote 19 hours 42 min ago:
When Important Banking App stores a secret to my "keyring", I would
never have expected that the "secret" would be trivially available
to all other programs that run.
Imagine if it worked that way for browsers, and every website with
a saved-password got to see all the other saved passwords...
skydhash wrote 17 hours 50 min ago:
Why is your banking app entering a secret to your keyring? That
would be like writing your safe code in a paper and let it hang
onto a physical keyring.
Terr_ wrote 17 hours 17 min ago:
The problem isn't what's on the keyring, the (reported) problem
is that it can be arbitrarily inspected in full by any program.
Doors should not be able to enumerate and copy all the keys
that aren't meant for them.
> Why is your banking app entering a secret to your keyring?
What is any "keyring" for if not to carry things you keep
secret and exclusive?
The problem here is leakage between purposes. I don't care if
the banking app is just storing my logon name for convenience,
even that should never be scrapeable by Linux BonziBuddy. [0]
> That would be like writing your safe code in a paper and let
it hang onto a physical keyring.
Why even put any regular keys onto such a horribly flawed
keyring either? There's no real difference between (A) seeing
combination-lock numbers versus (B) seeing the shape of a key
that is trivial to reconstruct. [1] [0] [1]
HTML [1]: https://en.wikipedia.org/wiki/BonziBuddy
HTML [2]: https://en.wikipedia.org/wiki/Bitting_(key)
skydhash wrote 16 hours 9 min ago:
Unix already have a security model for this: User and Groups.
You could create a new user called `banking`. And used that
exclusively for any banking activities. Especially with the
X11 model where you just have to type `startx` and not have
to launch a bazillion software to keep a DE happy.
Terr_ wrote 15 hours 4 min ago:
Have you actually tried that approach, with an individual
user for all your programs?
In fact, I was attempting that kind of thing just this
week, namely trying to run Spotify (distributed as a snap)
as separate user in a visible window. Maybe it's possible,
but it's certainly not trivial or turnkey.
ItsHarper wrote 40 min ago:
That's what Android does. Desktop Linux should make this
easier.
jeroenhd wrote 19 hours 51 min ago:
On platforms like Android, iOS, and macOS, secrets are easily
stored encrypted with no access to the key unless you exploit the
kernel. On Windows, a similar feature is opt-in, but compatibility
makes it a little less reliable.
iOS and macOS combine sandboxing with their Secure Element. Android
uses TEE or a secure element-like piece of hardware. Windows uses a
hypervisor + the (f)TPM.
Nothing Linux can't do, it's basically glueing together a small
early boot KVM VM + TPM + secure boot together with an API. Setting
up your own secure boot keys to make it run relatively seamless is
a pain on many consumer devices, though.
XorNot wrote 19 hours 21 min ago:
All of that is about protecting secrets at rest on the device. It
is of no protection at all if an application simply asks the
secure-whatever for them and then proceeds to email them all to
someone else.
The secrets in the keyring of my secure boot protected, full disk
encrypted laptop are exactly as secure until I boot it up and
unlock the keyring for Dbus.
jeroenhd wrote 6 hours 47 min ago:
Android apps can never exfiltrate each other's secrets using
the secret manager. Even while the apps are running. Same goes
for iOS apps. You can maybe trick them into leaking their
session tokens using weird browser exploits, but it's entirely
up to the app developer to make that happen.
Windows' Credential Guard ( [1] ) is explicitly designed
against the "dump all secrets while the system is running"
approach.
Even Mimikatz requires exploiting design vulnerabilities and
requires administrator access.
If you can break the kernel and all the safeguards the kernel
has against secret exfiltration, you may be able to decrypt
data from other applications, but it's not like on Linux
enviroments where any application running as any standard user
can dump the entire credential database by just asking.
HTML [1]: https://learn.microsoft.com/en-us/windows/security/ide...
wpm wrote 12 hours 54 min ago:
Keychain access can be limited with ACLs, enforced with code
signing signatures as well on iOS and more so on macOS where
the âkeychainâ can still be the older file based type.
There are secrets I cannot export from my system keychain
without disabling SIP on my Mac.
magicalhippo wrote 17 hours 14 min ago:
> It is of no protection at all if an application simply asks
the secure-whatever for them and then proceeds to email them
all to someone else.
On Windows the application can specify some extra entropy/salt,
and the secret is not decryptable without it[1]. So it's a tad
more difficult to exfiltrate than simply asking for it.
[1]
HTML [1]: https://learn.microsoft.com/en-us/windows/win32/api/dp...
XorNot wrote 16 hours 0 min ago:
Which is still protecting secrets at rest.
What are people not getting about this? The point of a shared
keyring is to enable applications to share secrets. My git
tokens are shared between git, my IDE, various scripts etc.
This discussion highlights the exact issue: people don't even
understand what problem or use case they are actually
solving.
pseudalopex wrote 18 hours 47 min ago:
You believe any Android or iOS app can exfiltrate all stored
secrets?
debo_ wrote 21 hours 11 min ago:
This is so close to a jwz post that if the stylesheet mimicked his
website's, I'd believe it was him.
shevy-java wrote 21 hours 11 min ago:
> D-Bus was introduced by GNOME folks about 20 years ago. For software
made only 20 years ago, as opposed to 40 like X, it's surprisingly
almost equally as bad.
That's not a surprise. The author of systemd, for instance, is working
for Microsoft. Suddenly all those changes to the Linux ecosystem make a
lot of sense. It became a corporate commodity, from A to Z. And when
that is your objective, it kind of makes sense to have a unified
system, even if it is crap.
bflesch wrote 20 hours 57 min ago:
I'm vocal critic of microsoft but systemd/wayland was one of the best
things to happen to linux. If you can improve upon it, then feel free
to implement a better solution.
ptx wrote 19 hours 36 min ago:
A solution to what? Aside from details of the implementation, one
can also disagree with the framing of the problem and scope of the
solution. Sure, we're free to implement an alternative solution for
doing DNS resolution and IPC and logging and time synchronization
and job scheduling and service monitoring and ... but should there
be a single solution to all of these things at once?
array_key_first wrote 11 hours 38 min ago:
It's literally not a single solution. systemd isn't a piece of
software, it's, like, 20 pieces of software.
People who think the init system is doing all of this have just
not done even the bare minimum amount of research on the topic.
Although, granted, the naming might not help.
kasabali wrote 7 hours 49 min ago:
Who said anything about an init system?
array_key_first wrote 41 min ago:
When people talk about systemd being a big ole monolith
against the unix philosophy this is usually what they mean.
And it's just not true. Like, theres no argument to be had
because systemd is many pieces of software that do one thing.
ptx wrote 8 hours 22 min ago:
Right, I guess I shouldn't have edited out my preemptive
response to this: Of course the solution is internally composed
of different parts. Most things are. People of course
understand that those internal parts could be switched out for
new parts that perform the same role in the overall solution,
but that doesn't help when the disagreement is about the scope
and purpose of the entire solution.
array_key_first wrote 40 min ago:
Right, what I'm saying is there IS no entire solution. It's
just project naming conventions.
Like, systemd-boot has literally nothing to do with systemd.
Nothing at all. It just uses the project name. Which is
confusing, sure.
bflesch wrote 19 hours 18 min ago:
All of the things you mention are interdependent, as resource and
service management is the core of it all. I'm convinced that they
set out to design somethign that has a scope which is as small as
possible, but then noticed that interfacing with
legacy-but-established open source software was extremely
difficult.
I'm very thankful for systemd covering more and more bases
because the "common" alternatives for many problems might be
stable but they are often really bad to configure, maintain and
debug - the ergonomics in non-default use cases have a lot of
potential for improvement. And what can you do if the maintainer
is not responsive to the kind of improvements you would need to
make the software ready for the next decades? Many times I have
forked things and tried to refactor their technical debt so a new
feature can be implemented without making it an even bigger hack,
and after that you just want to delete it all and start from
scratch with a "proper" setup.
So I can understand the perspective of the systemd developers and
the pain they had to go through simply on a technical level, not
even thinking about the huge flamewars on mailing lists with some
people.
Open source has big social dynamics, and a certain type of person
is attracted to being "leader" or maintainer even though they are
not as technical as I would wish them to be. I've had the painful
experience with having to explain security vulnerabilities to
some of them and my idealistic illusion of open source project
governance received a good grounding in reality.
On top of this imo the documentation of systemd is really good.
awesome_dude wrote 21 hours 8 min ago:
Wherever they might be working now.. isn't really relevant to the
project
> Lennart Poettering and Kay Sievers, the software engineers then
working for Red Hat who initially developed systemd,[2] started a
project to replace Linux's conventional System V init in 2010.[16]
HTML [1]: https://en.wikipedia.org/wiki/Systemd#History
the_why_of_y wrote 18 hours 29 min ago:
> Lennart Poettering and Kay Sievers, the software engineers then
working for Red Hat who initially developed systemd
This is wrong, Kay Sievers was working for Novell/SuSE at that
time, see
HTML [1]: https://0pointer.de/blog/projects/systemd.html#faqs
awesome_dude wrote 17 hours 17 min ago:
A note about this conversation. and your improvements has been
added to the "talk" page - Can I recommend that you make the
appropriate change to the actual page?
(Mostly because 1) I don't think that the talk page will be paid
any attention during the next... millenia.. and 2) I think that
you should make the change because you knew that it was
incorrect, and have receipts)
amelius wrote 21 hours 16 min ago:
D-bus breaks a very basic expectation.
That when you can open a basic X11 application like xeyes or xterm, you
can open any X11 application.
D-bus breaks this.
And it makes my Linux system feel like yet another case of
"microservice failure".
jalapenog wrote 20 hours 51 min ago:
I donât think Iâve ever seen a well behaved D-Bus enabled
application, NetworkManager being particularly psychotic.
bitwize wrote 17 hours 21 min ago:
I'm trying a distro with Connman instead of NetworkMangler. It's
the same deal. I could not for the life of me get it to connect or
even see my cellphone's wifi tethering hotspot.
I shutdown the connman service and removed it from the auto startup
sequence. I manually edited frickin' wpa_supplicant.conf to put my
cellphone network there. Worked first time and every time
thereafter.
The founding document of GNOME is called "Let's Make Unix Not Suck"
by which the authors (primarily Miguel de Icaza) meant "Let's Make
Unix Almost Exactly Like Windows". D-Bus is just the latest in a
series of attempts to bring Microsoft's janky, kind of an object
model to the realm of Unix's small do-one-thing C programs plumbed
together with file descriptors, pipes, and network sockets. Except
somehow, they added even more problems on top of the ones COM
already had!
At least when Steve Jobs tried to retrofit Smalltalk style OOP onto
the Unix model, he had the foresight to bring much of Smalltalk (in
the form of Objective-C) along with.
viraptor wrote 20 hours 55 min ago:
Are you really thinking of dbus here? It's not in the normal binary
loading path. And afterwards, it's not any different from other
libraries which may or may not stop the app from functioning for many
reasons.
csdreamer7 wrote 21 hours 11 min ago:
> That when you can open a basic X11 application like xeyes or xterm,
you can open any X11 application.
I have never heard of that. Even if it was true (and sounds like
another security issue); X11 is almost gone for most people. Why
should anyone care?
mx7zysuj4xew wrote 12 hours 0 min ago:
Listen in most discussions bringing up security is a good way for
you to shut the conversation down, but in the case of IPC anyone
who cares enough will be knowledgeable enough to see it for the red
herring it is
ambicapter wrote 21 hours 4 min ago:
I'm not sure why you would need to have "heard of that". If I was
getting Linux to work on my computer as many people have, and got
xeyes or xterm to work, I would expect other X11 apps to work as
well.
pmontra wrote 21 hours 5 min ago:
It is almost gone for me too, except that I can't adjust brightness
on my laptop with Wayland. I can with X11. It's a long story but
that's the TL;DR of it. So until all of that almost goes away, it's
full X11 at least for some people like me.
esseph wrote 21 hours 0 min ago:
I had the same problem until an updated fixed it
amelius wrote 20 hours 35 min ago:
There are still many of those kinds of issues left.
foresto wrote 15 hours 50 min ago:
I was surprised to learn that Wayland still doesn't offer
control of keyboard LEDs like Scroll Lock, so unprivileged
programs that use those LEDs cannot be ported to Wayland.
Even if I didn't depend on such a program myself, I would
find it strange that Wayland gives the compositor
responsibility for only part of the keyboard: its keys, but
not its indicator lights.
pmontra wrote 5 hours 46 min ago:
After all they started by locking down everything and then
they are creating all the openings that real world programs
need to do what people use computers for. It's probably a
better approach that starting with everything open and
attempting to lock down, but it takes a long time and some
of us will be locked out by some hardware / software
mismatch. In my case it seems that Noveau can't talk
properly with the backlight control of my card. Neither X11
can with those new kernel and driver but at least it can
use gamma correction to simulate a darker screen. Wayland
does not have gamma correction or it doesn't work as it
should, I can't remember.
shevy-java wrote 21 hours 10 min ago:
It is not true that X11 is gone. I use it. Many other people use it
too.
Can you show where you got the impression that "X11 is gone"?
esseph wrote 21 hours 1 min ago:
X11 has been replaced by Wayland as the default on the vast
majority of workstations. Servers wouldn't have it anyway.
It's "gone" for roughly 80% of the people using Linux on the
desktop.
(It's often still installable, it's just no longer the default
and has been marked as deprecated / unmaintained.)
chasil wrote 20 hours 6 min ago:
I am using OpenBSD on an x86-64 desktop, and X is still very
much the supported graphics environment.
That said, there is interest in Wayland in these circles.
HTML [1]: https://www.openbsd.org/papers/eurobsdcon2023-matthieu...
dvtkrlbs wrote 5 hours 41 min ago:
I mean the discussion is about Linux though no and even if we
extend the umbrella with the BSD folks still I don't think
wayland drops below %80
0x457 wrote 18 hours 5 min ago:
Supported by whom? Xorg, the server, no longer maintained.
Also, OpenBSD users already a tiny fraction of users...if
every single OpenBSD desktop switches to Linux and Wayland,
not a single metric will change significantly.
bitwize wrote 15 hours 23 min ago:
OpenBSD maintains its own Xorg fork, called Xenocara.
chasil wrote 17 hours 33 min ago:
OpenBSD also maintains OpenSSH, which has enormous market
penetration.
Their ssh supports the -X and -Y options to run remote X
applications.
Let me know when those go Wayland-specific and are able to
encompass the new protocol.
Until then, get comfortable in a small and discardable
minority.
Conan_Kudo wrote 9 hours 3 min ago:
The `-X` and `-Y` options were a mistake to integrate
into `ssh(1)`, it makes an assumption that everybody uses
an Athena/X11 type system. That said, you can combine
waypipe with ssh to do the same thing (ie. `waypipe ssh`
will give you the same effect as `ssh -X`).
chasil wrote 3 hours 34 min ago:
Until those options are integrated into OpenSSH itself,
Wayland remains in the minority.
esseph wrote 1 hour 56 min ago:
I'm not sure this statement makes any sense.
m4rtink wrote 20 hours 41 min ago:
The waypipe toole comes quite close to X forwarding on Wayland.
:-)
bigstrat2003 wrote 20 hours 42 min ago:
Are there hard numbers to back up the 80% thing? I don't know
one way or the other, I'm just skeptical because I still have
applications which don't work correctly under Wayland
(Discord), and if I have such problems it wouldn't surprise me
if others do too.
esseph wrote 12 hours 46 min ago:
It's the default for most of the parent/child distros.
Wayland Only (default, installed):
* Fedora
* Ubuntu
* openSUSE
* Arch Linux
* Pop!_OS
Wayland (default)
* Debian
* SUSE
I use Discord on Wayland every day and have for at least 3
years. Both AMD 9060 and NVIDIA 4060 (and an AMD RX 580).
The distro you use can have a huge impact on your OOTB
experience.
amelius wrote 20 hours 42 min ago:
I often read the advice that if something does not work on
Linux, then switch from Wayland to X11.
Also, 20% is quite a big userbase. What you are saying is like
saying that Firefox is "gone" because "percentage".
Trust me, X11 is not gone.
(written from a browser that runs in a VNC session that uses
the X11 protocol under the hood)
esseph wrote 16 hours 41 min ago:
"I often read the advice that if something does not work on
Chrome in the US Govt, try IE6." - This was still true as of
last year.
"Trust me, IE6 is not gone" - me
bitwize wrote 18 hours 46 min ago:
X is deprecated. Its maintainers do not want to maintain it.
They want you to use Wayland instead.
The major DEs have removed their X code paths, or will in the
next year. The toolkits will follow suit. X is a dead end for
new and non-legacy software.
oblio wrote 16 hours 57 min ago:
It's a dead end that allows me to have HiDPI (aka a 4k
display) on Ubuntu 24.04 and use the VMWare GUI and
OnlyOffice.
Wayland was launched 18 years ago and it still can't handle
mainstream apps in common scenarios.
oblio wrote 10 hours 33 min ago:
Downvote all you want, I'm telling you what I see. I had
to fall back to X...
AshamedCaptain wrote 21 hours 18 min ago:
Can't you guys stop reinventing the wheel every other day? I hate D-Bus
like everyone else, even though at least it did bring project Utopia
and all such crap. But even if I think it sucks I stay with it for the
simple reason that the more alternatives you create the more you annoy
other users WAY MORE than any benefit you bring them. D-Bus has been
used everywhere from LG TVs to automotives, so at least it f*cking
works.
Does it miss a spec? Write one.
Do you really want your secretsd or whatever to only be able to reply
to whomever stored the secret? Make clients store a cookie or
something and only reply if they prove ownership of it. But I have to
ask : what the hell is your threat model here? The attacker is just
going to ptrace firefox and read all the secrets anyway. Or read its
files in $XDG_CONFIG_DIR. You are just moving around who has the
ultimate responsibility, and that looks like security theater. In
addition, I _want_ other programs to be able to read secrets (e.g.
keyring administrators, .netrc-style shared secrets, etc.)
Do you hate a{sv}? If you propose JSON as alternative, you are going to
make me laugh.
Etc. Etc.
wolvesechoes wrote 8 hours 32 min ago:
> Can't you guys stop reinventing the wheel every other day?
No, Linux desktop is just an opportunity for a bunch of special
snowflakes to enact their "vision", force their niche requirements on
other 99.999% of users or create fiefdoms, where they can feel good
and safe.
javier2 wrote 17 hours 50 min ago:
Perhaps the SecretManager deserves some extra attention, but I
concur. We worked long enough on this, please dont split whats left
of the linux desktop...
Hizonner wrote 19 hours 8 min ago:
I don't recall asking for any "bus" in the first place.
Lammy wrote 20 hours 20 min ago:
> Does it miss a spec? Write one.
FreeDesktop-dot-Org would not accept one from the author if he did:
[1] 2
HTML [1]: https://blog.vaxry.net/articles/2024-fdo-and-redhat
HTML [2]: https://blog.vaxry.net/articles/2024-fdo-and-redhat2
themafia wrote 20 hours 27 min ago:
d-bus often fails to work properly, at least on my machine, where
systemd is not in use.
it already annoys me.
an alternative would be welcome.
agumonkey wrote 20 hours 35 min ago:
I may be naive, but why not adopt the browsers api development model.
90% shared core apis, experimental ones, for a few years it seems
that every group can work on its code without breaking things for
user much while new ideas coming regularly.
smaudet wrote 20 hours 57 min ago:
I've never had much luck with it either. A lot of the same pain
points as the author.
As for it being used everywhere, sure, we had some bad SOAP stuff
being used everywhere at one time, but that's not a good thing...
Regarding secrets etc.. on the one hand, yeah it's not much to worry
about people with access to your machine reading stuff on your
machine, buut*, it's kinda dumb to have stuff encrypted and left
around for a public unsecured protocol. The solution would be, for
apps that need security, don't use dbus.
If the API was less loosey goosey (self documentating, not so open
ended, less awkward), I agree it's fine for applications at the same
level of trust to all access the same thing.
The problem is more random scripts off the internet using browser
apis to read stuff out of local storage containers. Forcing local
containers to explicitly allow such access, and yes, using a non-dbus
protocol, would be a preferred method, while not requiring overly
complex authentication schemes locally...
Otherwise the main change I would have made would be to explicitly
allow applications to access the bus, vs just a random app having
access by virtue of running in memory...
torginus wrote 21 hours 0 min ago:
I am puzzled by this comment - hasn't been an explicit goal for the
Linux desktop (pushed esp by the Gnome/Fedora folks) to have
applications run in a sandbox? That's literally what stuff like
Flatpak xdg-desktop-portal and Wayland isolation are built around.
And maybe its time for a reinvention anyway? IPC and efficient and
portable formats are very mature nowadays, with protobuf, flatbuffers
etc. and the general model of the internet is based around service
location, and stuff talking to each other.
I'm kida curious why they didn't go with Unix Sockets in the first
place, with named pipes in memory carrying the message transport.
seba_dos1 wrote 13 hours 18 min ago:
> hasn't been an explicit goal for the Linux desktop (pushed esp by
the Gnome/Fedora folks) to have applications run in a sandbox?
Yes, and the article's author forgot to tell you that their rant
doesn't apply to applications running in a sandbox, as their D-Bus
access is filtered.
blablabla123 wrote 21 hours 4 min ago:
This is the first time I hear that anyone hates D-Bus. I always saw
it as a global API Bus that Apps can register to and which enables
some sort of interoperability and automation. After all it can even
be used from Bash. What is bad about this?
The security aspect seems also a bit funny to me. After all the
average Desktop has most data in the home directory, so every
application can read everything. That's not the fault of D-Bus.
Also I'm puzzled that Polkit hasn't been mentioned even once.
mx7zysuj4xew wrote 12 hours 5 min ago:
The reason you do t hear much about it is because it's not an often
discussed topic. Nonetheless the hate is there.
Dbus is a godawful mess. Imagine the windows registry, except it
can only be inspected at runtime, contains executable binaries and
is exceptionally fragile
craftkiller wrote 16 hours 37 min ago:
> The security aspect seems also a bit funny to me. After all the
average Desktop has most data in the home directory, so every
application can read everything. That's not the fault of D-Bus.
Those secret stores (gnome-keyring/kwallet) store the secrets
encrypted on disk, so every application can read the encrypted
secrets but only the secret store has the encryption key to decrypt
them. This is held in memory, not on disk.
dolmen wrote 19 hours 9 min ago:
Check varlink, an alternative to D-Bus defined in the SystemD
world.
HTML [1]: https://media.ccc.de/v/all-systems-go-2024-276-varlink-now...
ahartmetz wrote 17 hours 56 min ago:
Nah, fuck that one in particular. DBus was too type-unsafe? Why
not use JSON then, right? Right?!
throw_await wrote 20 hours 4 min ago:
The architecture is fundamentally broken when you are using
multiple window managers / desktop environments
HTML [1]: https://github.com/dunst-project/dunst/issues/363
vanviegen wrote 20 hours 5 min ago:
> The security aspect seems also a bit funny to me. After all the
average Desktop has most data in the home directory, so every
application can read everything.
The world is moving towards sandboxed applications (through flatpak
and friends) more and more. As per the OP, this is one of the
things holding sandboxing back.
LtWorf wrote 18 hours 36 min ago:
There's sandbox escapes daily since decades. It doesn't work.
akimbostrawman wrote 3 hours 43 min ago:
>There's lock picking daily since centuries. It doesn't work
LtWorf wrote 1 hour 31 min ago:
It takes time to pick one lock and twice as much to pick two.
It takes the same time to escape 1 or 10000000 sandboxes.
senko wrote 21 hours 6 min ago:
> Do you hate a{sv}? If you propose JSON as alternative,
Obviously, the components should talk using MCP.
skissane wrote 17 hours 27 min ago:
You may be joking but I think seriously that may be a decent idea.
The universal RPC/automation mechanism which everybody
implements-whatever its warts may be-is superior to a
better-designed one which few actually end up supporting. You
donât need an LLM to call MCP tools, thereâs nothing stopping
you from calling MCP tools from any programming language.
antiloper wrote 21 hours 7 min ago:
> Make clients store a cookie or something and only reply if they
prove ownership of it
Unix domain socket authentication is stronger and doesn't require
storing cookies on the client side.
> what the hell is your threat model here? The attacker is just going
to ptrace firefox and read all the secrets anyway.
Which is why you can (and people do, e.g. flatpak) run applications
where ptrace or global filesystem access is blocked. Which is why
portals exist and why there shouldn't be a "get all secrets via dbus"
escape hatch.
> I _want_ other programs to be able to read secrets (e.g. keyring
administrators, .netrc-style shared secrets, etc.)
Then don't use it? Secure defaults matter for most users.
> Do you hate a{sv}? If you propose JSON as alternative, you are
going to make me laugh.
Find the *kwargs here: [1] Etc. etc. This isn't the 90s anymore.
HTML [1]: https://wayland.app/protocols/xdg-shell
crest wrote 19 hours 0 min ago:
The funny/sad detail is that the 80s (at the latest) already solved
the problem. Have a look as XDR and Sun RPC. It has both strongly
typed APIs and versioning built in. You would have to come up with
your authentication mechanism for applications e.g. have them send
a cookie file (descriptor).
AshamedCaptain wrote 21 hours 4 min ago:
> Unix domain socket authentication is stronger and doesn't require
storing cookies on the client side.
And pointless here, since everything runs under the same uid. You
need to authenticate this is the same browser that stored this
secret, not that this is the same uid (useless), or the same pid,
or any other concept that unix domain socket authentication
understands.
> Which is why you can (and people do, e.g. flatpak) run
applications where ptrace or global filesystem access is blocked.
Which is why portals exist and why there shouldn't be a "get all
secrets via dbus" escape hatch.
In which case they do not connect to the same D-Bus "bus", and the
problem is again non-existent. See how flatpak sandoxing does it.
> Then don't use it? Secure defaults matter for most users.
Right until they notice they can no longer view the keyring
contents, or any other stupid limitation most desktop users
couldn't care about.
In fact, if you do not need a shared secrets service, and your
applications are containerized... why do you need a secrets IPC at
all? Just let each program store its secrets in some of its
supposedly private storage...
> Find the *kwargs here: [1] Much better to have a million
non-extendable protocols competing with each other. To this day
there are two protocols (at least) for exposing the address of the
DbusMenu service of a surface, one for gnome-shell and one for
kwin. So much for the uglyness of X atoms. And this has nothing
really to do with the design of the IPC mechanism itself...
HTML [1]: https://wayland.app/protocols/xdg-shell
ghusto wrote 19 hours 45 min ago:
> In fact, if you do not need a shared secrets service, and your
applications are containerized... why do you need a secrets IPC
at all? Just let each program store its secrets in some of its
supposedly private storage...
If I store my secrets in KWallet, which purports to _storage for
secrets_, I absolutely do not expect every application on the
desktop to have access to those secrets, whether I want to share
them or not.
I can't believe you're suggesting this is sanely defensible.
array_key_first wrote 11 hours 45 min ago:
It's literally how it's always worked, and not just on Linux -
this is standard across desktop operating systems. Except
MacOS, and very recently
Kwallet is for encryption at rest, so an attacker can't read
your secrets if they steal your computer. It IS NOT protection
from your own applications running as the same user.
That's just not how Linux desktop works. It's a desktop
operating system, it's not iOS. All apps running as your user
have your users permissions.
Is it an outdated security model? Yes, enter sandboxing and
newer kernel features. If you're not doing that though then you
won't get that.
Just run your shit in flatpak, problem solved. Or better yet,
don't install malware and only download trusted open source
software from trusted repositories.
AshamedCaptain wrote 16 hours 48 min ago:
KWallet has never provided any security guarantee, so I dunno
what is your surprise here. Its entire premise is
centralization and sharing (i.e. not having to type each
individual password over and over in each program).
jchw wrote 20 hours 38 min ago:
> And pointless here, since everything runs under the same uid.
You need to authenticate this is the same browser that stored
this secret, not that this is the same uid (useless), or the same
pid, or any other concept that unix domain socket authentication
understands.
I disagree. With UNIX domain sockets it is absolutely possible to
determine the PID of the process that you are talking to and use
pidfd to validate where it is coming from. Would be entirely
possible to use this for policy.
> In fact, if you do not need a shared secrets service, and your
applications are containerized... why do you need a secrets IPC
at all? Just let each program store its secrets in some of its
supposedly private storage...
And how exactly does the app container service store something
encrypted securely on disk? That's literally the point of a
secrets service on a modern desktop. It usually gets keymatter in
the form of a user password carried to it from PAM, in order to
allow on-disk encryption without needing separate keyring
passwords. (And yeah, sure, this could use TPM or something else
to avoid the passwords, but the point is literally no different,
it shouldn't be each application's job individually to manage
their own way of getting secure storage, that's a recipe for data
loss and confusion.)
> Much better to have a million non-extendable protocols
competing with each other. To this day there are two protocols
(at least) for exposing the address of the DbusMenu service of a
surface, one for gnome-shell and one for kwin. So much for the
uglyness of X atoms. And this has nothing really to do with the
design of the IPC mechanism itself...
That's a problem that occurs because the protocols have multiple
distinct implementations. Most of the dbus services don't have to
deal with that problem at all. (And the ones that do, tend to
have problems like this. There are plenty of weird
incompatibilities with different XDG desktop portal
implementations.)
I'm pretty sure the point of bringing up xdg-shell is because the
new bus is inspired by the Wayland protocol. For all of the
incessant bitching about Wayland online, Wayland protocols are
only about 1000x nicer to use than dbus. You can actually do
decent code generation for it without having to have like 5
competing ways to extend the XML to add basic things like struct
member annotations (and then have things like Qt's own DBus code
generator unable to actually handle any real DBus service
definitions. Try throwing the systemd one at it, doesn't fucking
work. The code doesn't even compile.)
foresto wrote 16 hours 31 min ago:
> determine the PID of the process that you are talking to and
use pidfd to validate where it is coming from.
The pidfd_open() man page doesn't list many things that can be
done with a pidfd. What sort of validation do you have in mind?
I would love to have a reasonably snoop-proof secret storage
service whose security model works with normal programs (as
opposed to requiring Flatpaks or the like).
jchw wrote 11 hours 36 min ago:
My reasoning behind the pidfd thing would just be as a way to
try to avoid race conditions, though on second thought maybe
it's not needed. I think you can take your pick on how
exactly to validate the executable. My thought was to go
(using /proc/.../exe) check that the file is root owned (and
in a root owned directory structure) and then use its
absolute path as a key. Seems like it would be a decent start
that would get you somewhere on any OS.
I think it would also be feasible to add code signatures if
we wanted to, though this would add additional challenges. As
I noted elsewhere any scheme that wants to provide a true
security boundary here would need to deal with potential
bypasses like passing LD_PRELOAD. Still, I think that it has
to be taken one step at a time.
AshamedCaptain wrote 16 hours 54 min ago:
> With UNIX domain sockets it is absolutely possible to
determine the PID of the process that you are talking to and
use pidfd to validate where it is coming from.
Validate what? You're just moving the responsibility to
whatever answer you give here. If you say "validate the exec
name is firefox-bin" then the next person who comes in will say
"I hate $your_new_fangled_ipc, you can make it dump all your
secrets by renaming your exec to firefox-bin". (This is just an
example).
> And how exactly does the app container service store
something encrypted securely on disk? That's literally the
point of a secrets service on a modern desktop.
The more I think of it, the less sense this makes. If you
already have a system where applications cannot read each
other's data, what is the point of secret service? What is the
security advantage?
If you want to encrypt with TPM, fingerprint, or anything else,
that's encryption, which is separate from storage (you can
encrypt the password with say a PCR but the application gets to
store the encrypted password in any way they want).
Password encryption in the desktop keyrings are for the
situation for when every application can read each other's data
files easily (again, as in the desktop). In which case, it may
make sense to use encryption so that such data is not
(trivially) accessible from any other application (otherwise
[1] applies) .
If your applications are already running sandboxed, a keyring
sounds to me like useless complexity? Just make each
application store its data into its sandbox. What's the threat
vector here, that super-user-that-can-escape-sandbox can read
into the sandboxes and extract the password?
> You can actually do decent code generation for it without
having to have like 5 competing ways to extend the XML to add
basic things like struct member annotations (and then have
things like Qt's own DBus code generator unable to actually
handle any real DBus service definitions. Try throwing the
systemd one at it, doesn't fucking work. The code doesn't even
compile.)
Yes sure, another problem resulting from the lack of
standarization. But my point was -- standarize (write a spec),
instead of adding more to the problem by creating yet another
competing standard which will obviously NOT solve the problem
of lack of standarization.
HTML [1]: https://developer.pidgin.im/wiki/PlainTextPasswords
jchw wrote 11 hours 51 min ago:
> Validate what? You're just moving the responsibility to
whatever answer you give here. If you say "validate the exec
name is firefox-bin" then the next person who comes in will
say "I hate $your_new_fangled_ipc, you can make it dump all
your secrets by renaming your exec to firefox-bin". (This is
just an example).
I'm genuinely kind of surprised people are tripping up on
this. Obviously, what you validate is up to you, but you can.
Why stick to just the base name? Why not the absolute path?
Bonus points for ensuring it's a root owned file in root
owned paths. You could special case Flatpak, or specific
mount points, or go crazy and add signatures to binaries if
you want. The policy would obviously vary strongly depending
on the system, but if you were dealing with a secure booted
system with dm-verity, or something similar, well then this
mechanism should be fairly watertight. It's not really the
end of the world if there are systems with different security
characteristics here.
You can really get creative.
(It is worth noting, though, that this could be bypassed
various ways trivially, like with LD_PRELOAD, so to be a true
security boundary it would need more thought. Still, this
could definitely be made improved numerous ways.)
> The more I think of it, the less sense this makes. If you
already have a system where applications cannot read each
other's data, what is the point of secret service? What is
the security advantage?
Well, the obvious initial benefit is the same thing that
DPAPI has had for ages, which is that it's encrypted on-disk.
Of course that's good because it minimizes the number of
components that will see the raw secret and ensures that even
other privileged processes can't just read user secrets.
Defense in depth suggests that it is a feature, not a
problem, if multiple security mechanisms overlap. Bonus
points if they'd both be sufficient enough to prevent attacks
on their own.
An additional case worth considering is when the home folder
is stored elsewhere over a network filesystem, as in some
more enterprise use cases.
> If you want to encrypt with TPM, fingerprint, or anything
else, that's encryption, which is separate from storage (you
can encrypt the password with say a PCR but the application
gets to store the encrypted password in any way they want).
It would be ill-advised to have each application deal with
how to encrypt user data. They can store keymatter in the
keyring instead of the data itself if they want to handle
storage themselves. (I'm pretty sure this is actually being
done in some use cases.)
> Password encryption in the desktop keyrings are for the
situation for when every application can read each other's
data files easily (again, as in the desktop). In which case,
it may make sense to use encryption so that such data is not
(trivially) accessible from any other application (otherwise
[1] applies) .
That page exists to explain why they don't bother, but part
of that is that there just isn't an option. If there actually
was an option, well, it would be different.
> If your applications are already running sandboxed, a
keyring sounds to me like useless complexity? Just make each
application store its data into its sandbox. What's the
threat vector here, that super-user-that-can-escape-sandbox
can read into the sandboxes and extract the password?
The threat vector is whatever you want it to be, there are
plenty of things this could be useful for. The reality is
that Linux desktops do not run all programs under a sandbox
and we're not really headed in a direction where we will do
that, either. This is probably in part because on Linux most
of the programs you run are inherently somewhat vetted by
your distribution and considered "trusted" (even if they are
subject to MAC like SELinux or AppArmor, like in SuSE) so
adding a sandbox feels somewhat superfluous and may be
inconvenient (i.e. file access in Bottles is a good example.)
But, even in a world where all desktop apps are running in
bubblewrap, it's still nice to have extra layers of defense
that compliment each other. And even if something or someone
does manage to access your decrypted home folder data, it's
nice if the most sensitive bits are protected.
> Yes sure, another problem resulting from the lack of
standarization. But my point was -- standarize (write a
spec), instead of adding more to the problem by creating yet
another competing standard which will obviously NOT solve the
problem of lack of standarization.
The reason why people don't bother doing this (in my
estimation) is because DBus is demoralizing to work on. DBus
isn't a mess because of one or a couple of issues, it is a
mess because from the ground up, it was and is riddled with
many, many shortcomings.
And therein lies the rub: if you would like to have influence
in how these problems get solved, you are more than welcome
to go try to improve the DBus situation yourself. You don't
have to, of course, but if you're not interested in
contributing to solving this problem, I don't see why anyone
should be all that concerned about your opinion on how it
should be fixed.
HTML [1]: https://developer.pidgin.im/wiki/PlainTextPasswords
AshamedCaptain wrote 5 hours 22 min ago:
> I'm genuinely kind of surprised people are tripping up on
this. Obviously, what you validate is up to you, but you
can. Why stick to just the base name? Why not the absolute
path? Bonus points for ensuring it's a root owned file in
root owned paths.
Because you do not get it: this is not Android. There is no
fixed UIDs. There is no fixed absolute paths. The binaries
are not always root-owned. There is no central signing
authority (thank god!). You really do not get it:
_anything_ you could validate from a PID would be
absolutely pointless in desktop Linux.
> You could special case Flatpak, or specific mount points,
or go crazy and add signatures to binaries if you want.
Or, if you are assuming Flatpak, you could simply do not
allow access to the session bus and instead allow access
only to a filtered bus that only allows talking to
whichever services Flatpak provides. Which is how Flatpak
does it and you sideline the entire problem of having to
authenticate clients on the bus, which is a nightmare. The
entire process tree descending from original Flatpak
session gets access to this bus and only to this bus.
> hat even other privileged processes can't just read user
secrets. Defense in depth suggests that it is a feature,
not a problem, if multiple security mechanisms overlap.
Bonus points if they'd both be sufficient enough to prevent
attacks on their own.
I really do not see the point of this. Of course I want
privileged processes to be able to see my passwords; this
is _my_ desktop.
I do not see why you'd have your "sandboxes apps" store
their private data but then have another storage that is
"more secure" for whatever your definition of secure is.
You'd just put the data in the "more secure" storage to
begin with.
What you're describing is not another layer of security, it
is just pointless complication. As I said, the more I think
of it, the less reason I see for a secret service which
does not really share secrets.
You reach stupid conclusions like having to design a
key-value DB server that only returns values to the process
that inserted them in the first place, like what TFA is
doing. Why? Just why??? Have multiple totally separate,
private instances! And you already have one storage for
that: the app's private storage. Why do you even need IPC
for this?
> It would be ill-advised to have each application deal
with how to encrypt user data.
Why? You do not put the reason why not. Every application
does this _today_, and no IPC has ever been needed for this
(e.g. openSSL is a library, not a service).
> The reality is that Linux desktops do not run all
programs under a sandbox and we're not really headed in a
direction where we will do that, either.
In which case, my entire remark does not apply and there is
some (minor) benefit to a keyring.
> DBus isn't a mess because of one or a couple of issues,
it is a mess because from the ground up, it was and is
riddled with many, many shortcomings.
This is a circular argument. D-Bus is a mess because it is
a mess. Even if I would agree, it is a pointless argument.
> you would like to have influence in how these problems
get solved, you are more than welcome to go try to improve
the DBus situation yourself. You don't have to, of course,
but if you're not interested in contributing to solving
this problem, I don't see why anyone should be all that
concerned about your opinion on how it should be fixed.
I am answering to a guy that says that D-Bus sucks then
proceeds to create an alternative instead of fixing it. I
have not only contributed to D-Bus through decades, I am
also part of the reason it is used in some commercial
deployments outside traditional desktop Linux (or was a
decade ago). My opinion is still as important as his, or
yours, which is : nothing at all.
torginus wrote 20 hours 56 min ago:
Since docker, we know how to do pretty good isolation (some of
the tech is shared by Flatpak etc. sandboxes) - just put stuff
into different namespaces with some auth api allowing processes
to 'mount' the necessary stuff.
The closer you stick to the kernel security model, the more
likely your app will be safe and performant, and the less likely
other devs will reject it in favor of their hand rolled stuff.
shevy-java wrote 21 hours 11 min ago:
How does it work exactly? I mean, the premise here is:
"it f*cking works"
Can we objectify this claim made here?
publicdebates wrote 21 hours 20 min ago:
I wonder if the design of D-Bus has anything to do with a principle I
notice a lot, where the most meritorious solution never rises to the
top for any given problem, but rather one apparently chosen by absolute
randomness. For example, I wonder how many repos on github have
legitimately created a 100% better framework than React, but the author
simply can't get the word out for whatever reason, so the project
remains accidentally anonymous. Maybe D-Bus has something similar?
sam_lowry_ wrote 4 hours 55 min ago:
D-Bus has the weight of Redhat behind it.
It's just politics, really.
twic wrote 9 hours 47 min ago:
Part of what's going on is that all of this stuff is developed by
volunteers. If only one person, or three people or whatever, are
actually willing to give up hundreds of thousands of hours of their
own time to work on something, then those people get to make the
decisions about what gets done. There's very little supervision from
any kind of "upper management" to catch bad decisions.
On top of that, there's adverse selection here. Who gives up
thousands of hours to work on some obscure corner of the Linux
desktop? People with quite unusual thought processes.
tguvot wrote 13 hours 48 min ago:
iirc it was developed as freedesktop project in order to create
standard desktop bus to be used by everybody, as back in a day kde
had it's own bus and gnome had another one.
abenga wrote 19 hours 56 min ago:
Most of the time, there is usually no "most meritorious", just
something that is elsewhere on the "trade-off space" than the person
speaking would like. I usually dismiss everybody who so snidely and
arrogantly dismisses results of other people's work(e.g. the OP
article), like there was some _obviously_ correct solution that the
people who worked on the widely accepted solution were too stupid or
malicious to choose. They could not possibly have had other
priorities or doing their best to get something working acceptably in
a complex ecosystem with no central control, no! They are just dumber
than you (or just plain malicious).
supportengineer wrote 20 hours 49 min ago:
There is definitely an elite cabal with its thumb on the scale here.
sph wrote 6 hours 3 min ago:
The deep state forcing everybody to use GNOME smh my head
baobun wrote 6 hours 7 min ago:
And the prevalance of D-Bus is part of it...? Spill the beans!
jiggawatts wrote 21 hours 0 min ago:
HTML [1]: https://en.wikipedia.org/wiki/Worse_is_better
bawolff wrote 21 hours 0 min ago:
> the most meritorious solution never rises to the top for any given
problem, but rather one apparently chosen by absolute randomness.
Respectfully, i think that mostly happens when people reviewing the
solution space don't understand the problem fully. Often the
requirements differ from what people think they are, and as a result
the winner seems random because they don't understand the actual
requirements.
volf_ wrote 21 hours 7 min ago:
The world is filled with "good enough" solutions. If it has 80% of
the functionally needed, it will be good enough for most use cases.
> the most meritorious solution never rises to the top
You know why? Because it was the best solution at the time that
covered everything they needed. You can only complain about it
because the initial problem was solved and people were able to move
on to something else.
Does it work for what we need it to do? Yes? Ok. Now that we have
settled this problem, we can continue on developing.
Meritocracy is only relevant to someone who has ideas but no desire
or ability to actually structure the idea in such a way that would
work in the world we find ourselves in today.
> Maybe D-Bus has something similar?
So you just commented here to say nothing but "dbus sucks because it
isn't the best. I wonder if there are better options?".
bigfatkitten wrote 21 hours 15 min ago:
D-Bus came to prominence because of its association with GNOME, which
has in turn has remained relevant mostly because of its association
with Red Hat.
Conan_Kudo wrote 9 hours 13 min ago:
No, it remained relevant because Ubuntu based every stack for their
desktop on GNOME technologies (except the aborted Unity 8).
Y_Y wrote 21 hours 17 min ago:
Worse is better, but meta, because the worst way of choosing is what
wins
_flux wrote 21 hours 20 min ago:
From the style of this article I expected that [1] and [2] would have
documentation, specification and perhaps a bunch of tests, but they're
not really there (other than smoke tests).
Those would have been a great starting point as well! But maybe we'll
see them later.
HTML [1]: https://github.com/hyprwm/hyprwire
HTML [2]: https://github.com/hyprwm/hyprtavern
Oxodao wrote 7 hours 45 min ago:
tbf they stated in their article that those are not there YET
multiple time. We'll wait and see once they're done
wpm wrote 12 hours 59 min ago:
I believe the sole author is doing finals for their last year of
university at the moment.
charcircuit wrote 21 hours 21 min ago:
>I've decided to take matters into my own hands. I am writing a new
bus.
Why not reuse Binder which has been to deployed to billions of devices,
being a core part of a serious OS, with many many more developers who
understand it compared to dbus.
You would probably want to write your own service manager, but you can
reuse hardened stuff that already exist.
rendaw wrote 6 hours 48 min ago:
Is Binder better than D-Bus? How so?
jabl wrote 20 hours 38 min ago:
Yes! Make something built on top of binder, and use something with
orders of magnitude more users and developer resources behind it..
> hardened stuff that already exist.
To make it even more hardened(?), Google recently contributed and got
merged a Rust implementation of binder for the Linux kernel (and
they're apparently planning to eventually remove the old C
implementation). [1]
HTML [1]: https://lwn.net/Articles/953116/
HTML [2]: https://lore.kernel.org/rust-for-linux/20231101-rust-binder-...
AshamedCaptain wrote 21 hours 7 min ago:
There are few implementations of the Binder userspace outside of
Android.
aryonoco wrote 13 hours 27 min ago:
Not widely known but the original Binder, OpenBinder, was not even
for Linux or Android It was developed for BeOS.
OpenBinder was one of the few pieces of code which was open sourced
in Be Incâs dying days just before it was acquired by Palm.
Many of the principal Be developers who worked on OpenBinder,
Dianne Hackborn, Jean-Baptiste Queru, et al then moved from Palm to
Danger, which was developing Android and which was later acquired
by Google.
And the rest, as they say, is history.
pseudalopex wrote 20 hours 48 min ago:
How many implementations existed of their new bus?
AshamedCaptain wrote 20 hours 46 min ago:
Considering that any new implementation of Binder userspace would
realistically also be incompatible with Android Binder, what
would really be the gain here? You'd basically have yet another
wire protocol that nobody else uses but now also depends on
having a obscure Linux feature enabled.
nextaccountic wrote 20 hours 37 min ago:
Just use Android's implementation
ChocolateGod wrote 19 hours 35 min ago:
Isn't that tightly tied to the Android permission and app
model, which is radically different from generic Linux.
kllrnohj wrote 20 hours 38 min ago:
Why would it need to be a new implementation? AOSP is like...
right there, and it's not like libbinder has crazy
dependencies.
> also depends on having a obscure Linux feature enabled
An extremely widely used and battle hardened Linux feature,
though, with corporate sponsorship and active development. With
the only real reason it's obscure on desktop linux at all is
because upstream blocked it for a long time. If desktop linux
embraced it, it certainly wouldn't be obscure anymore, now
would it?
AshamedCaptain wrote 20 hours 35 min ago:
Most of binder is in outright Java. Libbinder_ndk is a subset
that is unlikely to please anybody. The other libbinder
(openbinder) is dead since 2006ish. I actually used this last
one in certain commercial product.
> An extremely widely used and battle hardened Linux feature,
though, with corporate sponsorship and active development.
Compared to _unix sockets_ , which is the other transport
used by almost every other local IPC mechanism, and also what
D-Bus uses, there is just no contest. Even Android uses unix
sockets more than Binder.
kllrnohj wrote 20 hours 28 min ago:
> Most of binder is in outright Java
None of binder is in Java. The Java binder code is just JNI
bindings to the native implementation.
Things like permission manager are in Java, but that's not
part of binder. It's just a service published on binder,
and one that wouldn't translate to current desktop Linux
anyway.
> Compared to _unix sockets_ , which is the other transport
used by almost every other local IPC mechanism, and what
both D-Bus, TFA's proposal, and literally any other
reasonable desktop IPC proposal out there, there is just no
contest.
unix sockets are not an equivalent, which is why protocols
are bolted on top to turn it into dbus, etc...
EDIT:
> The other libbinder (openbinder) is dead since 2006ish.
The libbinder I meant is the one in AOSP hence why I said
"AOSP is right there": [1] That one is very definitely not
dead since 2006ish.
HTML [1]: https://cs.android.com/android/platform/superproje...
AshamedCaptain wrote 17 hours 2 min ago:
"None of binder is in Java" is too strong a statement:
[1] This libbinder is still way too Java-centric. It can
be used from outside, and even slightly reminds me of
openbinder (e.g. sp<> [2] ) but it doesn't really change
the picture much. You have something which smells Java
from a mile, and has a lot of other Android-isms to boot,
so still likely requires to reinvent a lot of the wheel
to actually use it for most desktop programs.
Even the use of C++ is likely to frown many people. (Not
me).
HTML [1]: https://android.googlesource.com/platform/framew...
HTML [2]: https://cs.android.com/android/platform/superpro...
p_l wrote 15 hours 17 min ago:
The C++ origin of Binder is annoying, but unlike
original Binder[1] easily workable around especially
given the exact format of messages is left up for
implementation to decide outside few standard bits
[1] BeOS, the docs still match what is in Android :D
AshamedCaptain wrote 5 hours 37 min ago:
Not entirely , you need to agree on some constraints
for wire protocol since the kernel ends up doing
reference counting on objects sent through it.
charcircuit wrote 15 hours 46 min ago:
That is a java version of a class from libbinder.
Having Java and native versions of classes is a common
pattern for things meant to be used from both.
HTML [1]: https://cs.android.com/android/platform/superp...
AshamedCaptain wrote 5 hours 31 min ago:
No, it is not. It is the Java class which has native
methods that call into the C++ version, as someone
said above. But it is still primarily a Java class.
kllrnohj wrote 3 hours 28 min ago:
dbus-java exists, does that magically turn dbus
into being primarily implemented in Java?
No, of course not, that'd be absurd. Same thing
with Parcel & Binder. Java bindings existing does
not change the simple fact that binder itself does
not have any Java in it. It's regularly used in
processes with zero Java at all, this isn't a
hypothetical it's a basic reality. That's why
binder is used for HALs and similar low-level
systems.
bee_rider wrote 21 hours 15 min ago:
Which OS? I didnât get many results for BSD binder. Then I figured
maybe you were joking about the âseriousâ part, so I tried
windows binder, iOS binder, didnât see muchâ¦
charcircuit wrote 21 hours 12 min ago:
Binder is the primary way apps talk to the various OS services on
Android. [1]
HTML [1]: https://source.android.com/docs/core/architecture/ipc/bind...
HTML [2]: https://www.kernel.org/doc/html/latest/admin-guide/binderf...
pjmlp wrote 9 hours 35 min ago:
Including drivers, as since Project Treble, starting with Android
8 all new drivers are required to be userspace, talking with the
kernel via Android IPC (aka Binder).
Traditional Linux drivers are considered legacy in Android.
schmichael wrote 21 hours 14 min ago:
HTML [1]: https://source.android.com/docs/core/architecture/ipc/bind...
zb3 wrote 21 hours 19 min ago:
Binder will come to linux desktop soon... together with Android :)
anon-3988 wrote 10 hours 58 min ago:
Is there any plans by some DE to replace D-bus with Binder?
jasonjayr wrote 21 hours 22 min ago:
Could this bus offer a dbus-compatibility 'firewall/translator' d-bus
socket per each app (provided they use the d-bus environment variables
correctly)? That might speed adoption if it is able to be a drop-in
default, instead of needing to run 2 busses.
ginko wrote 21 hours 28 min ago:
I was bracing for the proposed replacement being integrated in systemd.
0x457 wrote 18 hours 2 min ago:
I wouldn't hate it. I used to hate systemd, but today it's one of my
favorite linux things.
Narishma wrote 19 hours 23 min ago:
Written in Rust with an MIT license for good measure.
0x457 wrote 18 hours 1 min ago:
You mean this?
HTML [1]: https://rust-for-linux.com/android-binder-driver
cyberax wrote 20 hours 54 min ago:
It already has one: Varlink ( [1] ). For pretty much the reasons
outlined by the topic starter.
HTML [1]: https://varlink.org/
shevy-java wrote 21 hours 9 min ago:
It may soon happen. :)
systemd-bus 2.0
112233 wrote 21 hours 16 min ago:
which of them? :)
I was actually looking forward to bus1, such a nice design.
Instead, we are getting varlink it seems. yuk. "json json eggs bacon
and json"
riskable wrote 21 hours 20 min ago:
systemd-busdd (pronounced, "busted")
DIR <- back to front page