And quite frankly their attitude and lies are reasons for not having (k)dbus in the kernel.

Its a reason to be suspicious and drive closer review, but as a reason not to include it... dangerous territory, bordering on discrimination and thus opening the door for a coup._________________The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king

Except for the kernel where it is a declared policy not to, and for a good reason. This is IMHO the main non-technical reason why kdbus has nothing lost in the kernel: The (almost explicitly stated) intention of the kdbus developers is to violate this kernel policy continuously in the future.

Except for the kernel where it is a declared policy not to, and for a good reason. This is IMHO the main non-technical reason why kdbus has nothing lost in the kernel: The (almost explicitly stated) intention of the kdbus developers is to violate this kernel policy continuously in the future.

Indeed, the whole we can't change the inside of the code and leave the interface (API/ABi) alone is complete and utter BS.

I'm not quite following the grammar, only the sense there ;)

Those guys wouldn't know an ABI guarantee if it slapped them in the face, afaic.

Quote:

And quite frankly their attitude and lies are reasons for not having (k)dbus in the kernel.

Agreed; anyone who thinks provenance is irrelevant, is essentially a nub imo, with no experience of the real-world.

Or we'd all still be stuck on Windows®, dreaming of a better way to use our computers.

grw wrote:

[ Greg-KH] is really cherry-picking an argument. As if it wouldn't be mean to consciously give them an insecure protocol. Or a second-rate one.

Indeed; though he sounds like an affable sort of guy, doesn't he, and who wants to be mean..

That kind of psychobabble is fine^W legal in an advertisement (making people feel socially pressured is practically de-rigeur) but fundamentally flawed when it comes to a technical discussion.

But then, this is a propaganda campaign, carried out over "new" media, aimed at establishing RedHat as equivalent to Microsoft when it comes to buying Linux; not a process aimed at getting the best results for users.
That's the last thing on any of the Poeterring cabal's minds afaic, or we wouldn't have been subjected to so many breakages for so little benefit (I'd count it as negative) over the last 5-7 years.

Yes, you can, but it means that you have to carry on the old API forever. I doesn't seem that this the intention of the kdbus developers (especially since, if I understood correctly, they desire to implement security issues in their first API attempts for compatibility with dbus1).

Yes, you can, but it means that you have to carry on the old API forever. I doesn't seem that this the intention of the kdbus developers (especially since, if I understood correctly, they desire to implement security issues in their first API attempts for compatibility with dbus1).

Yes, they carry the old api of dbus1 for compatibility. @mv, you criticized polkit use regarding dbus some months ago for exactly these flaws? Question for me as a new user of kdbus (thanks to Gentoo early adoption): Would kdbus respect any such an invocation of kdbus with a faked user from another user? @mv, can you tell a testing example?_________________the thread ain't easily find an end

@mv, you criticized polkit use regarding dbus some months ago for exactly these flaws?

No, I criticized polkit by its mere existence: The idea to have a complex daemon running to nihilate UNIX permissions is completely broken. Whether the attack finally succeeds over a dbus race or some other backdoor - such a complex thing with an embeeded interpreter will always have some - plays no role. It is impossible to fix such a fundamentally flawed concept.

While I agree that this might have been kind and humble to do by mv, can you guys now give some explanation to the reading public what that red marked sentence was about?
A big portion of that page is, now that line was removed, incomplete and incomprehensive talk, because the reading public can only be guessing what you people meant at that point, since that "red marked sentence" is mentioned in quite a few places.

EDIT: 2015-08-13 09:10+02:00
I only care for the general public to have easier reading, and not be driven away. It's also fine for me, it not being corrected, as you can see below, mv replied to this post. Just, it's better thinking about future readers when one deletes things. Thanks!
EDIT END

Can some of you correct that incomprehensiveness? (no, not for me, forget me, for the reading public; and no, not in the next post below, but where that red marked sentence is, on page 20, probably, or even 19 --lost the track myself)

Thank you in advance!

Last edited by miroR on Thu Aug 13, 2015 7:13 am; edited 1 time in total

no, only systemd makes use of kdbus_________________The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king

@Naib, you may well have a decisive opinion of things you don't know nothin' about. But don't contradict yourself: How should the only user systemd fake a wrong identity? Such would be a self-deception of systemD but not a security issue.

@mv, I am just thinking about the fake identity case, I get two in my mind:
1. user2user exploit:
UserB fakes identity of UserA and gets able to start something in the session of UserA.
2. system exploit case:
UserA has extended admin rights on a system. UserB has not but fakes UserA identity and is able to issue system commands.

As this is about dbus1 compatibility of kdbus, is this exploitation possible using traditional dbus?_________________the thread ain't easily find an end

In what way was what I wrote wrong?
Right now systemd is the only thing geared up to make use of kdbus. All those nice dbus applications cannot speak via kdbus_________________The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king

As this is about dbus1 compatibility of kdbus, is this exploitation possible using traditional dbus?

I do not spend time looking for exploits, but when I think about the huge list of races which I had collected in a few hours and posted somewhere in this forum some weeks/months ago (which were not only in systmed but in many other consumers of dbus) I would be surprised if such exploits were not possible. Simply, I do not want to spend all of my time looking for bugs and/or hoping that the developers find these always quicker than any hacker: If I wanted this, I could use windows as well. I prefer to have a system for which it is rather unlikely to contain any critical security vulnerability at all. With policykit, it is impossible to have such a system, with classical unix permissions it is not a big deal.

As this is about dbus1 compatibility of kdbus, is this exploitation possible using traditional dbus?

I do not spend time looking for exploits, but when I think about the huge list of races which I had collected in a few hours and posted somewhere in this forum some weeks/months ago (which were not only in systmed but in many other consumers of dbus) I would be surprised if such exploits were not possible. Simply, I do not want to spend all of my time looking for bugs and/or hoping that the developers find these always quicker than any hacker: If I wanted this, I could use windows as well. I prefer to have a system for which it is rather unlikely to contain any critical security vulnerability at all. With policykit, it is impossible to have such a system, with classical unix permissions it is not a big deal.

What we're looking at is a design flaw in security.

It's like having a locked door with an open window next to it because your design specs say that there always has to be an open window next to the lock. You can redesign that lock all you want in an effort to improve it's security. You could even theoretically make the lock impossible to open and yet someone can still just enter through the window.

kdbus, being a completely new IPC method, could have removed the prior design flaw... but instead, they chose to keep it in. Anyone reviewing the code knows full well that it is a fundamental flaw in design, though apparently the kdbus devs weren't insightful enough to see that themselves. Rather than take the time to fix the design now before it becomes widely used, the solution is to just keep it there and hope nobody ever comes along and hops through the open window.

Much of the rest of the systemd/freedesktop.org stack is full of these types of things because it's amateur hour over there. They have an agenda and the agenda has nothing to do with security. The worst part, is they are all intentionally interconnected and linked into code executing in PID1, meaning that open window next to the lock could easily lead right inside your bank vault (because a vault has a lock too). Unfortunately, distro maintainers, in an effort to do as little work as possible, largely jumped on board, leaving us in the situation where these people will have domain over the majority of Linux boxes in the future. It's going to bring the same vulnerabilities that Microsoft brought, where again, security was always an afterthought, and you might as well just mark every kdbussystemd pwned going forward.

With kdbus in the kernel the big Linux companies will sell their customers a special feature: The employees of the customers get a large window of privilege escalation. It is to show: Everyone can be the boss everywhere.
I would like to see this feature in business
But maybe there is just a fool on the hill looking down the valley ..._________________the thread ain't easily find an end

Last edited by ulenrich on Sun Jul 26, 2015 10:37 pm; edited 1 time in total

There seems to be a kdbus USE flag on the kernel now..._________________The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king

Anyway, the real issue for me here is that Andy is reporting all these
actual real problems that happen in practice, and the developer
replies are dismissing them on totally irrelevant grounds ("this
should be equivalent to something entirely different that nobody ever
does" or "well, people could opt out, even if they didn't" yadda yadda
yadda).

For example, the whole "tasks X and Y communicate over shmem" is
irrelevant. Normally, when people write those kinds of applications,
they are just regular applications. If they have issues, nobody else
cares. Andy's concern is about one of X/Y being a system daemon and
tricking it into doing bad things ends up effectively killing the
system - whether the *kernel* is alive or not and did the right thing
is almost entirely immaterial.

So please. When Andy sends a bug report with a exploit that kills his
system, just stop responding with irrelevant theoretical arguments. It
is not appropriate. Instead, acknowledge the problem and work on
fixing it, none of this "but but but it's all the same" crap.

Linus

And yet another person noticing that the (k)dbus devs are just dismissing any and all criticisms.
At this rate, Linus may just decide to have them on the same footing as BFS, which is NOT included in the kernel, but the patches are easy to apply._________________PRIME x570-pro, 3700x, RX 550 & 560
Acer E5-575 (laptop), i3-7100u - i965
---both---
5.5.18 zen kernel, gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon