Why do we need d-bus?

I consider devel/gvfs an annoyance.
Indeed. Even PCManFM drags it in for something as trivial as the recycle bin functionality. For a light file manager use-case, the author made an error here. For our virtual desktop system I ripped it out and patched in my own solution. Purposely not following the freedesktop specifications.
 
I'm running a FreeBSD desktop for several months now. I have DBUS disabled on my package builds and other than this little hiccup I have yet to encounter any problems/disadvantages:


But I guess this is also highly subjective & depending on your "workloads" or "workflows". I know there are several people here that want to have "the full KDE" experience - that's something I'm simply not after so I can't speak for those situations.
 
We used to run hald/dbus combo on FreeBSD 10+ years ago to achieve input on X11. It was the only way.
freedesktop.org is not Linuxisms. freedesktop.org is XDG.

I ran Windowmaker+compton+gnome2-session combo as a lightweight but fully featured in terms of desktop integration and composition, back in late 2000s on my company allocated laptops that were like single core 2.0GHz 4GB ram machines with some cheapass mobile nvidia.

Dbus is not your performance culprit. You can do this as an exercise or for a very tight embedded system. But you're not getting extra "optimized desktop" because you remove dbus from all software.
 
Dbus is not your performance culprit. You can do this as an exercise or for a very tight embedded system. But you're not getting extra "optimized desktop" because you remove dbus from all software.
Just because it doesn't peg the CPU doesn't mean it doesn't slow things down, and my main concern is security anyway.
 
Certainly if one does "without dbus" whole desktop build and it's operational, the board and the community will benefit from that kind of a procedure.

Regarding your main concern

The most serious vulnerability was discovered 10 years ago and it allowed information disclosure and denial of service. A local exploit without any privilege escalation consequence.

I believe that this discussion is moot. It was an official handbook procedure to enable dbus in rc.conf for FreeBSD for several consecutive releases in order to have operational X11 desktop.

What is the security status of all the installed non-dbus applications? Have they gone under such a scrutiny that dbus seen in last 15 years as integral component of *nix desktop? Has that scrutiny resulted in less than impressive (from hacking standpoint) CVE log? What spawns in your processes during your entire runtime, has everything been CVE checked in such a manner that dbus is left as the Pedro and the most suspicious component?

Again I'm not trying to demotivate anyone but show my viewpoint. You need to find a sweet spot between security and functionality. You need to take a good look at things and set aside those that do not concern you.
 
freedesktop.org is not Linuxisms. freedesktop.org is XDG.
I consider "free"desktop the exact meaning of linuxisms
it's a project started by redhat , and redhat is the purest form of linuxism and THE thing that twisted linux to what we see now and if you want to say that "free"desktop is only "standards" , no look at thir Wikipedia page and the projects that they host(hosting is a kind of supporting right?)
and I don't know if they count as linuxisms but things like
SYSTEMD and GNOME stand out
and for the second sentence, what's the point? XDG is the pervious name of "free"desktop
again if it was only about the standards out of all there is I don't want redhat to tell what are them and "Promote" them
Dbus is not your performance culprit. You can do this as an exercise or for a very tight embedded system. But you're not getting extra "optimized desktop" because you remove dbus from all software.
actually it dose with a extra deamon not running and millions of lines of code not being executed around the thousands of pakages it really improves the speed of everything. also it's not about only the speed it's about having a extra and totally unnecessary out . with bloat you have a extra surface for attack a extra chance of a crash and a extra chance of unexpected behavior and etc
 
freedesktop.org is not Linuxisms. freedesktop.org is XDG.
Not Linuxisms exactly but these days they attract the same kinds of weird decisions. Something about "graphics" and "desktop experience" seems to attract heaviness and bloat bad software.

Granted, they have a lot of pressure on them from many different angles but why do I need to get involved with that? Just go against the standards and get on with my life ;)
 
actually it dose with a extra deamon not running and millions of lines of code not being executed around the thousands of pakages it really improves the speed of everything. also it's not about only the speed it's about having a extra and totally unnecessary out . with bloat you have a extra surface for attack a extra chance of a crash and a extra chance of unexpected behavior and etc

This is generalization. Like I said I don't care about d-bus but it was in official FreeBSD procedure 10 years ago.
Why those "millions of lines of code" did not affect our desktop experience then. You also run a full kernel with "billions of lines of code" but the majority of code paths you will never ever execute.

FWIW if dbus were brokerless none would even bother.
 
This is generalization. Like I said I don't care about d-bus but it was in official FreeBSD procedure 10 years ago.
Kind of. It was more because Xorg kept flapping about trying to decide on hald or other bad ideas.
Many of us just added:

Code:
Option "AutoAddDevices" "false"

To their xorg.conf and kept hald and dbus junk off the machines until this bug was fixed a release or two later.
 
Kind of. It was more because Xorg kept flapping about trying to decide on hald or other bad ideas.
Many of us just added:

Code:
Option "AutoAddDevices" "false"

To their xorg.conf and kept hald and dbus junk off the machines until this bug was fixed a release or two later.

AFAIR that option did not work for laptop usage, you'd need to restart the server if you plugged in external mouse or keyb.

For release or two we used to use this thing. Again I don't care about it but I don't see is as red herring either.

As far as I'm concerned dbus is not an unsafe piece or software, or a resource hog, or a wallgarden component or Linux specific in any way.

What people are simply wrong about is the security component. There is 10 times more chance you're going to find an malformed input exploit in some x11-fm obscure piece of software than in dbus.

Since I don't care either way I do not wish to pursue this discussion apart from saying that no-one here has conviced me that a security tight desktop should come without dbus.
 
Regarding your main concern

The most serious vulnerability was discovered 10 years ago and it allowed information disclosure and denial of service. A local exploit without any privilege escalation consequence.
It's a bad design implemented to work around the Unix permissions model. No Dbus bug here, and still results in a privilege escalation:

Back to performance, you might want to read upthread:
 
AFAIR that option did not work for laptop usage, you'd need to restart the server if you plugged in external mouse or keyb.
Fair enough; though I do use a laptop daily and it still worked well enough for me. Admittedly i do not ever plug in an external mouse or keyboard. *My* laptop comes with both inbuilt ;)

malformed input exploit in some x11-fm obscure piece of software
no-one here has conviced me that a security tight desktop should come without dbus.
Exactly right. A security tight desktop should probably come without *any* GUI capabilities and especially not a graphical file manager. So dbus has limited use at that point anyway.
 
A security tight desktop should probably come without *any* GUI capabilities and especially not a graphical file manager.
You only have real security if the computer in question doesn't have a connection to the internet.
index.jpeg
 
I'm running tons alot of services on address 127.0.0.1 without nat.
But in fact my only connection to the dangerous external world is when i use firefox.
 
You only have real security if the computer in question doesn't have a connection to the internet.
Very true. In many ways I do keep GUI and internet access mutually exclusive. In particular I would never connect Windows to the raw network. It always sits on an isolated network with something like a Raspberry Pi running a SOCKS5 proxy for Firefox to view web pages. It solves so many issues. Projects such as PiHole are even developed to capture that niche for "normal" security conscientious users.

I just wish I could keep web browsers offline. They are the biggest scum!
 
Could you please explain how did you isolate the networks?
Pretty much by simply not connecting them to the wider world.

Code:
Isolated PC ------------------- Raspberry Pi ================== Main internet
                            |
Isolated Laptop -------------

The Raspberry Pi is not set to route packets, there is no NAT. It is impossible for data to come in or out between networks. Instead it runs a SOCKS5h proxy, HTTP Proxy and SSH for application layer routing. The best thing is that this contains the brokenness of even Windows software because unless you specifically tell them, they can't implicitly know about these proxies and so cannot perform their inbuilt malware related tasks like "auto updates".

* I actually use an old Thinkpad but a Raspberry Pi is probably less wasteful of energy.
 
Hi kpedersen,

thank you very much for your answer. If I understand correctly, even if one connected another computer/network between the "Raspberry Pi" and the "Main internet" running a firewall, that should prevent any connectivity between the networks, correct?

I am asking because I have only a single public internet address and need Windows 10 machine to connect to Internet from time to time.

Kindest regards,

M
 
even if one connected another computer/network between the "Raspberry Pi" and the "Main internet" running a firewall, that should prevent any connectivity between the networks, correct?
Yes, that should be fine. The rest of the world / network "looking in" will only see the Raspberry Pi and packets coming and going from it. They won't even know the Windows PC behind it exists. Likewise the Windows PC and the software running on it won't even know it is connected to the internet. Only SOCKS/proxy enabled software can be instructed to communicate with the Pi.

It isn't really a "professional" solution. However Windows isn't really a "professional" operating system.
 
Hi kpedersen,
Yes, that should be fine. The rest of the world / network "looking in" will only see the Raspberry Pi and packets coming and going from it. They won't even know the Windows PC behind it exists. Likewise the Windows PC and the software running on it won't even know it is connected to the internet. Only SOCKS/proxy enabled software can be instructed to communicate with the Pi.
Thank you once again for confirming.
It isn't really a "professional" solution. However Windows isn't really a "professional" operating system.
Well, professionals have access to hardware (firewalls), which I cannot afford; perhaps more public addresses to isolate the networks at the Internet interface, etc.

But, unless you can suggest an improvement reachable by non-professionals, I will try to implement this. As it appears impossible to buy Raspberry Pi at this time, I - like you - will re-purpose an older laptop.

Kindest regards,

M
 
... Instead it runs a SOCKS5h proxy, HTTP Proxy and ...
Which means that a web browser on the "Isolated PC" can download and execute malware. Unless you make sure the web browser on that PC is completely feature- and stateless. And that malware can communicate freely with the outside world, using the http protocol.

A few years ago, someone published something (was it an RFC?) for running TCP/IP over http. I think was meant as a joke (like the old "TCP/IP over carrier pigeon" RFC), but people have now demonstrated running real malware that communicates solely via http.

You want isolated? Cut the cable. And station a marine with a machine gun at the entrance to your computer room.
 
Top