Live data from Hacker News

Kids find a security flaw in Linux Mint by mashing keys

github.com

271–280 of 340 posts

Re: Kids find a security flaw in Linux Mint by mashing keys

#271
post #80
post #60

Earlier quoted context omitted.

That might be a kde limitation in general. The amount of "fun" I had dealing with two screens on kde is outright endless. Not sure they even test that kind of configuration, 640x480 pixels should be enough for everyone.

I'm using 3 monitors on KDE with Debian currently and it's been fine for me. All screens lock together etc.

Now imagine they're powered by a docking station, you go into suspend, put the laptop out of the docking station, wake it up and - tadaa! This bug dissappeared but still occurs slightly diffrent for other people. Three monitors itself aren't more edgecase than 2. How long are you using this setup?

Besides screenlockers, having 2 screens with diffrent resolutions is way worse in KDE than in GNOME. (On X11)

Re: Kids find a security flaw in Linux Mint by mashing keys

#272
post #70

Earlier quoted context omitted.

Because, IIRC, xscreensaver is launched on demand (idle timer, power management), and that's a terrible time to detect the extension and tell a user that they won't be able to resume their session, because their Xserver is too old. Also, because of piecemeal releases, and remote X. You might update Xscreensaver, but not your X server or desktop environment. You might have a dedicated X terminal which can't easily hav…

What is todays alternative to remote sessions?

Most of what I've seen has migrated towards a virtual display on the session server, streamed via vnc/rdp/? to a thin client.

Re: Kids find a security flaw in Linux Mint by mashing keys

#273
I enjoy to see my kid breaking software, POS terminals and causing ATMs to throw error windows. Nothing critical, just funny how random screen touching and keyboard mashing drives “serious” software crazy.

Fool-proof and child-proof software is yet to come.

Hire QA kids.

Re: Kids find a security flaw in Linux Mint by mashing keys

#274

Earlier quoted context omitted.

I did not get redirected--would that be because I'm using Brave? Or because I'm on mobile?

The former. Brave has explained their referer policy here: https://brave.com/privacy-updates-5/ > When navigating to a new site, never send a referer header. JWZ wouldn't know you are visiting from HN if you use Brave.

Or Safari, apparently.

Re: Kids find a security flaw in Linux Mint by mashing keys

#275

Earlier quoted context omitted.

I'm asking nicely, can we please not do this? Let's not exacerbate the problems of bad communication by using more sarcasm and hyperbole. If there is some particular thing that can be done to improve areas where there are perceived design proclivities, can we focus on that instead?

But it's not constructive criticism, but humor. I agree that sarcasm provides for poor constructive criticism to get a point across, but the intent was mockery, not being helpful. I certainly do not believe that GNOME would take the advice of an H.N. post, and they are well aware of these criticisms to begin with, as they are commonly levied against them.

I don't mean criticism, we (HN users) all have heard all the criticism a hundred times before. I mean actual actionable feedback that someone is able to work with, e.g. if there are problems with the design then we can bring some concrete data that shows new, reliable information. That means taking honest efforts to establish two-way communication where there is none.

Re: Kids find a security flaw in Linux Mint by mashing keys

#276
That reminded me of the Linux GRUB2 bug where you could press Backspace key 28 times and bypass all security. [1]

>The source of the vulnerability is nothing but an integer underflow fault that was introduced with single commit in Grub version 1.98 (December 2009) – b391bdb2f2c5ccf29da66cecdbfb7566656a704d – affecting the grub_password_get() function.

[1] https://thehackernews.com/2015/12/hack-linux-grub-password.h...

Re: Kids find a security flaw in Linux Mint by mashing keys

#278

Earlier quoted context omitted.

My kid (3 years old then) found an issue in the MacOS lock screen as well. It didn't result in a bypass, but a "Spinning Beach Ball of Death". I could then reproduce it and even filed an issue, but only I could reproduce (and one funny response was: "Why would you want a screen shot of the screen sleeping? It would just be black." - well tell that to my kid): https://discussions.apple.com/thread/7598463

> https://discussions.apple.com/thread/7598463 Wow every new person who joins that thread misses the point more than the previous one. This was painful to read.

genuine question: Is that dialabrain person an Apple employee or just a user?

Re: Kids find a security flaw in Linux Mint by mashing keys

#279

Earlier quoted context omitted.

But it's not constructive criticism, but humor. I agree that sarcasm provides for poor constructive criticism to get a point across, but the intent was mockery, not being helpful. I certainly do not believe that GNOME would take the advice of an H.N. post, and they are well aware of these criticisms to begin with, as they are commonly levied against them.

I don't mean criticism, we (HN users) all have heard all the criticism a hundred times before. I mean actual actionable feedback that someone is able to work with, e.g. if there are problems with the design then we can bring some concrete data that shows new, reliable information. That means taking honest efforts to establish two-way communication where there is none.

> I mean actual actionable feedback that someone is able to work with

Is this not what “constructive criticism”, as I called it, is?

GNOME is not going to listen to an H.N. comment an change it's ways, and it was never my intent to reach them or otherwise inspire change in them.

My intent was simply to be humorous.

Re: Kids find a security flaw in Linux Mint by mashing keys

#280

I find interesting that GNOME Screensaver's security depends on it to not crash. Meanwhile, in KDE the lock screen is managed by KDE Session Management Server which ensures that lock screen cannot be bypassed by simply crashing its process. The way it works is follows: ksmserver draws a black rectangle over everything and spawns kscreenlocker. If kscreenlocker crashes, the black rectangle is still here, and ksmserver…

In Windows it’s also good. The way it works is follows.

The OS support multiple desktops. Similar to files or registry keys, desktops have security descriptors attached (a data structure keeping who’s the owner, and optionally listing users/groups with their respective permissions on the object being controlled).

To do anything on a desktop, like create windows, paint stuff, or interact with windows on that desktop, user doing that is required to pass an access check against the security descriptor of the desktop. If failed, these GUI-related functions gonna return “access denied” status code instead of doing anything.

The login screen is simply rendered on a separate desktop. That desktop has restrictive security descriptor, most users don’t have permissions to interact with them. UAC prompts are also displayed on another desktop, that’s how it’s impossible to automate them from within a program who triggered the UAC prompt.

BTW, about crashing GPU drivers, on modern Windows the condition is recoverable. The symptoms are black screen for a second, then the OS resets the hardware, restarts the driver, and resumes rendering of the desktop. Observed quite a few times working on advanced GPU stuff, especially compute shaders.

Post reply on HN