AMD Radeon Linux Gaming Performance At Parity Between KDE Plasma 6.0 X11 vs. Wayland

[mSparks]

Again Not read zero comment.

Not surprised.
we established already the only reason you are here is to push your malicious wayland agenda. Why would anyone expect you even try and read anything...

[oiaohm]

Not surprised.
we established already the only reason you are here is to push your malicious wayland agenda. Why would anyone expect you even try and read anything...

O you want answer.
Heck might as well answer it with read

https://www.x.org/releases/X11R6.8.0/doc/Xsecurity.7.html

MIT-KERBEROS-5 Kerberos reads tickets from the cache pointed to by the KRB5CCNAME environment variable, so does not use any data from the .Xauthority file. An entry with no data must still exist to tell clients that MIT-KERBEROS-5 is available.

Existence of Xauthority with data says you are using brute forcible MIT-MAGIC-COOKIE-1 or brute forcible XDM-AUTHORIZATION-1 locally when on Linux. Basically no body uses SUN-DES-1 on a Linux system because you need Solaris so that works..

Remember how you said "X11/Xauthority" that does not apply if you are using MIT-KERBEROS-5. So this is just mSparks attempting to move the goal posts. mSparks you already stated with the "X11/Xauthority" that you were not talking about MIT-KERBEROS-5.

https://datatracker.ietf.org/doc/rfc2942/

The selection of the random session key in the Kerberos V5
authenticator is critical, since this key will be used for encrypting
the telnet data stream if encryption is enabled. It is strongly
advised that the random key selection be done using cryptographic
techniques that involve the Kerberos ticket's session key. For
example, using the current time, encrypting it with the ticket
session key, and then correcting for key parity is a strong way to
generate a subsession key, since the ticket session key is assumed to
be never disclosed to an attacker.

https://www.prosec-networks.com/en/blog/kerberos-attacks/

Turns out Kerberos in general and MIT-KERBEROS-5 more so is not rock solid particularly if things are done wrong.

mSparks find where using MIT-KERBEROS-5 with x.org X11 server equals encrypted protection on the Kerberos operations. The shock horror it does not. This is another case of bugger me I am running around with my pants around my ankles. Basically every option in Xsecurity is broken or does not work on Linux.

MIT KERBEROS some what good if implemented right. Problem here we are talking about x.org X11 server here where basically nothing related to security is implemented right. mSparks I don't need to defeat the theory good MIT Kerberos with x.org X11 server you only have to defeat the broken mess x.org X11 server implements that plaintext lots of things that are recommend encrypted making Kerberos attacks simpler.

Even using MIT Kerberos you still need todo attack surface and attack time mitigations. Yes not doing these things you come open to kerberos attack methods.

See mSparks is here with another so called magical bullet. When it comes to security there is no such thing as magic bullet this is why Attack surface area is important and reducing this attack surface area when ever practical is important. Yes even using MIT Kerberos locally it still would be ideal to use the OS provided file system protections over sockets.

Good question if the user logged into their account locally using MIT Kerberos why when application running by that user connecting to own X11 server or Wayland compositor of the same user locally should this be spending processing time talking to MIT Kerberos servers.

Kerberos with Telnet is a bad idea. Kerberos with ssh is a reasonable idea. x11 with Kerberos is a bad idea for lot of the same reason Kerberos with Telnet is a bad idea. Yes Telnet over network is a bad idea in general. X11 protocol over network is also a bad idea in general. Kerberos is only a reasonable idea with a protocol if that protocol like ssh is still ok over network or locally. Kerberos does not magically make a bad protocol good.

mSparks note that video showed 4 years old and Kerberos has turned into attack-able in the last 3 years. Kerberos had a good run but that up without updates to implementations. That link above to Kerberos flaws is only the tip of the iceberg found in the last 3 years.

mSparks Now stop trying to move goal posts and accept nothing about x.org X11 servers current security design is any good. It all need major work.

[mSparks]

mSparks Now stop trying to move goal posts and accept nothing about x.org X11 servers current security design is any good. It all need major work.

Thats just the bad news for you wayland guys
unlike wayland, X11 isnt dead, so the goalposts will keep moving to even stay on par with X11

that flawed random number generator for X11 you are getting so excited about was fixed decades ago (rPis even come with an hwrand now), and all the modern kerberos systems use aes256 or 512 now.

replacing that with a display server like wayland that opens your machine up to randsomware just isnt a good idea.

If you dont want the goalposts to keep moving away from you, uninstall wayland, switch to X11, and keep up with the moving goalposts.

[oiaohm]

that flawed random number generator for X11 you are getting so excited about was fixed decades ago (rPis even come with an hwrand now), and all the modern kerberos systems use aes256 or 512 now.

https://trustedsec.com/blog/the-art-of-bypassing-kerberoast-detections-with-orpheus

Turns out people have got kerberos attacks to work with aes256 and aes512 enabled with kerberos.

Section 8 had nothing todo the the random number generated. The rendom number generate defect took you from attack that would take 8 to 12 hours by brute force in 1995 down to mins. Problem is 8 to 12 to do that brute force today in mins so you don't need the random generate fault any more. Old so called dead attack is functional again all due to improve CPU processing power.

Yes 2018 people though they had fixed kerberos by changing to aes256 or aes512. Turned out that did not work mSparks. This now makes the problem a lot more tricky. There is something fundamental with kerberos at play.

Of course you missed that my prior example was also against a aes256 enabled system works.

Here we go with insulting garbage again. So by msparks for good now. I will just now black list you and not bothering coming here to read you posts at all.

[anda_skoa]

The case with Wayland lot of core wayland comes straight out of either the X11 protocol or proposed changes to the X11 protocol.

Exactly.
There are much more similarities than differences.

Some people try to find differences in the areas of similarity and ultimately fail.
Of course accepting such failure is difficult so they insist on why there are differences that don't exist.

Not sure why they can't focus on actual differences instead but it might be a sort of sunken cost issue after having invested so much time going down the rabbit hole.

Sorry for the long post anda_skoa this is the rabbit hole you are dealing with.

No problem at all.
You posts are very informative and look at angles I had not been aware of.

I am approaching these wide spread misconceptions mostly from a system level development perspective and learn a lot about details on the application level that way.

[mrg666]

Thats just the bad news for you wayland guys
unlike wayland, X11 isnt dead, so the goalposts will keep moving to even stay on par with X11

that flawed random number generator for X11 you are getting so excited about was fixed decades ago (rPis even come with an hwrand now), and all the modern kerberos systems use aes256 or 512 now.

replacing that with a display server like wayland that opens your machine up to randsomware just isnt a good idea.

If you dont want the goalposts to keep moving away from you, uninstall wayland, switch to X11, and keep up with the moving goalposts.

You are funny!

have you seen this?

https://www.youtube.com/watch?v=MH7KYmGnj40

[mSparks]

Exactly.
There are much more similarities than differences.

xwayland and xorg-server are not just similar they are identical, xwayland is just a renamed org-server v1.20.

but xwayland only has relevance if wayland has relevance, and the only thing wayland offers is an increased susceptibility to randsomware while breaking everything that made people use linux over the alternatives in the first place, hence waylands now absolute dependency on xwayland.

[oiaohm]

Exactly.
There are much more similarities than differences.

This is true as well for the MIT-MAGIC-COOKIE-1, XDM-AUTHORIZATION-1 and MIT-KERBEROS-5. They were all designed by MIT. They all have sections designed that you will not have enough processing power/bandwidth back at the time they were created to brute force them. Times do change.

MIT-MAGIC-COOKIE-1
XDM-AUTHORIZATION-1
Notice the -1 . That right these items are version 1 from other 30+ years ago. It was intended that there would be a version 2 and so on and this has never happened. Yes that we should have been getting new versions of these as processing power increased so that the defense against brute force held.

We have 30 years of lack of proper updating of X11 security. This problem starts before Linux exists with these two parts.

This is area that if x.org X11 server and X11 protocol was being correctly maintained and updated as the MIT developers of most of it planned out originally I should not be able to pick holes in it as simply because security designs should have been updated.

It looks like we are at the point of needing Kerberos 6 with the current attacks against Kerberos 5. Yes there was a Kerberos 1,2,3 and 4 that in the past were also found to have implementation flaws so resulting in being replaced with newer version. With the massive use of Kerberos 5 by Windows active directory solutions this is going to be one hell of a headache. Remember kerberos major number change is backwards compatibility breaking change.

Kerberos 5 only starts in 1993.

https://www.geeksforgeeks.org/difference-between-kerberos-version-4-and-kerberos-version-5/

Its not the first time Kerberos has need a major version change.

Yes Kerberos 4 had replay attacks. problems that Kerberos 5 interface breaking change was done to fix. Some of the weakness found in Kerberos 5 is more complicated version of replay attack this is why the changing the encryption is not fixing those.

In security nothing lasts forever. Kerberos 5 at around 26 years of people not finding a fundamental flaw was a very good run. It taken a while for people to work out that the flaw is fundamental with Kerberos 5 and that the designed in ways to counter future flaws in theory into the Kerberos 5 protocol did not cover this fundamental flaw.

If people want to keep on using x.org X11 server into the future they need to stop giving x.org X11 server a free pass on these security things.
Lot of it is simple thing that need to happen and people need to accept that there is going to be some breaking changes.
1) Making xhost in X11 server set Unix permissions for local
2) Either update(make new current day secure version) or remove the no longer secure options.

[oiaohm]

This sites filter is horrible. I tried giving the URL to the x.org current xsecurity and I getting 404 blocked.

https://www.x.org/releases/current/doc/man/man7/

Yes go to above then open up "Xsecurity - X display access control"

Then notice something else MIT-KERBEROS-5 is not supported by current version of x.org X11 server at all. Because MIT-KERBEROS-5 was found to be security flawed it was removed. Yes those attempting to push X11 bring out Kerberos to try to say we win because of Kerberos even when MIT-KERBEROS-5 has been removed from the current x.org X11 servers on security grounds for some time resulting in Kerberos not being valid at all to use in for X11 debate.

This note was in my post before but I had to work out what the heck this site filter was picking on.

[mSparks]

If people want to keep on using x.org X11 server into the future they need to stop giving x.org X11 server a free pass on these security things.

If anyone is ever going to use wayland its going to need to start actually implementing these security things rather than relying on every gui app running on a users display having the same unix permission group, but first it will need to build in its multi user support so that is actually technically possible.

But that is never going to happen, not just because it will need a lot more effort than reviewing one pull request a year or because it took wayland app devs 15 years to master giving windows a title.

It's never going to happen because ripping all that functionality out was the whole idea in the first place, it was what would make xwayland superfast compared to "bare metal" as you call it xorg-server. That turned out to be a flawed assumption and now wayland is dead.

No matter how many strawmen about kerberos encryption downgrades on windows machines you burn down, wayland isn't going to magically come back to life.