View previous topic :: View next topic |
Author |
Message |
Naib Watchman
Joined: 21 May 2004 Posts: 6069 Location: Removed by Neddy
|
Posted: Fri Jul 17, 2015 9:52 am Post subject: |
|
|
Anon-E-moose wrote: |
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. _________________ #define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0; |
|
Back to top |
|
|
gwr Apprentice
Joined: 19 Nov 2014 Posts: 194
|
Posted: Fri Jul 17, 2015 11:18 am Post subject: |
|
|
From here: http://article.gmane.org/gmane.linux.kernel/1993918
Quote: | I wish we could, but we can't break programs that are currently running
today, that would be pretty mean.
thanks,
greg k-h |
This 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.
This "once crap, always crap" argument is bogus. Software migrates to new APIs every day. In fact, they expect hundreds of maintainers and developers to migrate to systemd every day. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Fri Jul 17, 2015 11:31 am Post subject: |
|
|
gwr wrote: | Software migrates to new APIs every day. |
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. |
|
Back to top |
|
|
gwr Apprentice
Joined: 19 Nov 2014 Posts: 194
|
Posted: Fri Jul 17, 2015 11:39 am Post subject: |
|
|
mv wrote: | gwr wrote: | Software migrates to new APIs every day. |
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. |
You can make new APIs without changing old ones. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Fri Jul 17, 2015 1:54 pm Post subject: |
|
|
Anon-E-moose wrote: | 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. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Fri Jul 17, 2015 4:49 pm Post subject: |
|
|
gwr wrote: | You can make new APIs without changing old ones |
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). |
|
Back to top |
|
|
ulenrich Veteran
Joined: 10 Oct 2010 Posts: 1483
|
Posted: Sat Jul 25, 2015 7:12 pm Post subject: |
|
|
mv wrote: | gwr wrote: | You can make new APIs without changing old ones |
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? |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Sat Jul 25, 2015 9:15 pm Post subject: |
|
|
ulenrich wrote: | @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. |
|
Back to top |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Sun Jul 26, 2015 12:46 am Post subject: |
|
|
There is a red marked sentence point in this forum thread, which is incomprehensible, at around:
(this same topic)
https://forums.gentoo.org/viewtopic-t-1004624-start-475.html#7769446
mv wrote: | ulenrich wrote: | your red marked sentence is insinuating a motivation |
Yeah, it was too aggressive. It is now removed. |
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
And you are suggested as:
Ignorant Guru's Blog wrote: | a good read for catching up on the sensationalized push to put kdbus into the kernel |
and rightly so, it's really worth it, from places such as:
[IgnorantGuru's Blog]
kdbus: systemd’s Kid Cousin Come To Stay (No, Not PID 1, In Your Kernel, Silly)
[[ same address as in the quote ]]
https://igurublog.wordpress.com/2015/05/04/kdbus-systemds-kid-cousin-come-to-stay/
(find the link under: "This Gentoo forum thread").
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 |
|
Back to top |
|
|
Perfect Gentleman Veteran
Joined: 18 May 2014 Posts: 1256
|
Posted: Sun Jul 26, 2015 4:18 am Post subject: |
|
|
i've enabled kdbus in kernel. may i disable/uninstall dbus? |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Sun Jul 26, 2015 6:27 am Post subject: |
|
|
miroR wrote: | There is a red marked sentence point in this forum thread, which is incomprehensible |
I removed the sentence for a reason. It contributed no new facts and does not help to understand something better. I do not want to repeat it. |
|
Back to top |
|
|
tclover Guru
Joined: 10 Apr 2011 Posts: 516
|
Posted: Sun Jul 26, 2015 8:46 am Post subject: |
|
|
Perfect Gentleman wrote: | i've enabled kdbus in kernel. may i disable/uninstall dbus? |
Do whatever you want with those crap bus and open new threads when appropriate for support (to avoid spamming and trolling here.) -- This is *not* a support thread in case you did not notice.
Thanks. _________________ home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6069 Location: Removed by Neddy
|
Posted: Sun Jul 26, 2015 9:01 am Post subject: |
|
|
Perfect Gentleman wrote: | i've enabled kdbus in kernel. may i disable/uninstall dbus? | no, only systemd makes use of kdbus _________________ #define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0; |
|
Back to top |
|
|
ulenrich Veteran
Joined: 10 Oct 2010 Posts: 1483
|
Posted: Sun Jul 26, 2015 1:00 pm Post subject: |
|
|
Naib wrote: | Perfect Gentleman wrote: | i've enabled kdbus in kernel. may i disable/uninstall dbus? | no, only systemd makes use of kdbus | @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? |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6069 Location: Removed by Neddy
|
Posted: Sun Jul 26, 2015 1:58 pm Post subject: |
|
|
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 _________________ #define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0; |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Sun Jul 26, 2015 2:10 pm Post subject: |
|
|
ulenrich wrote: | 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. |
|
Back to top |
|
|
saellaven l33t
Joined: 23 Jul 2006 Posts: 655
|
Posted: Sun Jul 26, 2015 3:37 pm Post subject: |
|
|
mv wrote: | ulenrich wrote: | 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. |
|
Back to top |
|
|
ulenrich Veteran
Joined: 10 Oct 2010 Posts: 1483
|
Posted: Sun Jul 26, 2015 10:15 pm Post subject: |
|
|
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 ...
Last edited by ulenrich on Sun Jul 26, 2015 10:37 pm; edited 1 time in total |
|
Back to top |
|
|
ct85711 Veteran
Joined: 27 Sep 2005 Posts: 1791
|
Posted: Sun Jul 26, 2015 10:26 pm Post subject: |
|
|
They will probably call this a race condition requiring polkit to monitor the kernel that's monitoring everything else (including polkit). |
|
Back to top |
|
|
gwr Apprentice
Joined: 19 Nov 2014 Posts: 194
|
Posted: Tue Jul 28, 2015 3:10 pm Post subject: |
|
|
ct85711 wrote: | They will probably call this a race condition requiring polkit to monitor the kernel that's monitoring everything else (including polkit). |
Mexican standoff. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6069 Location: Removed by Neddy
|
Posted: Thu Aug 06, 2015 7:27 pm Post subject: |
|
|
There seems to be a kdbus USE flag on the kernel now... _________________ #define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0; |
|
Back to top |
|
|
baaann Guru
Joined: 23 Jan 2006 Posts: 558 Location: uk
|
Posted: Fri Aug 07, 2015 8:36 pm Post subject: |
|
|
Naib wrote: | There seems to be a kdbus USE flag on the kernel now... |
Mike Pagano is following the Gentoo philosophy of offering choice and adds a disclaimer
Quote: | NOTE: This is not some kind of Gentoo endorsement of kdbus. Nor is it a Mike Pagano endorsement of kdbus |
|
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sun Aug 09, 2015 8:35 am Post subject: |
|
|
I thought Gentoo wasn't about choice any more, and Linux has never been about choice, or at least that's what I swore I read at least a few times on the developer ML.
Apparently it's about choice when Poeterring et al's work is up for inclusion, and thereafter it's not; or something.
Note: I'm fine with the option. I just wish the last sentence didn't describe so much of what I see happening. |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6200 Location: Dallas area
|
Posted: Mon Aug 10, 2015 10:14 am Post subject: |
|
|
They've been back up since the 1st of the month (some problem on their end)
Edit to add: It was working fine for the last few days, but it seems a little flaky today. *shrugs* _________________ UM780, 6.12 zen kernel, gcc 13, openrc, wayland |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6200 Location: Dallas area
|
Posted: Mon Aug 10, 2015 8:15 pm Post subject: |
|
|
From the "kdbus: to merge or not to merge?" thread on lkml. https://lkml.org/lkml/2015/8/10/693
Quote: | 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. _________________ UM780, 6.12 zen kernel, gcc 13, openrc, wayland |
|
Back to top |
|
|
|