Live data from Hacker News

Kids find a security flaw in Linux Mint by mashing keys

github.com

221–230 of 340 posts

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

#221

Earlier quoted context omitted.

Bad design in X11 which can't be fixed. https://news.ycombinator.com/item?id=25801693

It's not an X11 design flaw. The very concept of locking the screen is flawed. A flaw that also haunts Wayland, BTW. The concept of screen lockers is having a special layer, that can't be bypassed, which a locker creates. The whole security then hinges on the locker not crashing. X11 does have such a layer. Wayland compositors also implement it through such a layer. And for either the situation is, that if the locker…

> In the meantime one can use Xpra with Xvfb to create detachable X11 sessions, which then however lack GPU acceleration.

Maybe using Xdummy instead of Xvfb would work better?

This wiki article makes such an approach look promising: https://xpra.org/trac/wiki/Xdummy

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

#222

Earlier quoted context omitted.

Our internal research found that clear error messages confused our users, so we removed it. I have no idea what KDE is or does, sorry.

> Our internal research found that clear error messages confused our users and removed it. I can't tell if this is sarcasm or if you're serious. If you're serious, please tell me what product you've butchered so I can avoid it like the plague. Clear error messages only confuse people who shouldn't be using the product in the first place. More importantly: a clear error message at the cost of a few confused users is f…

I've had similar discussions at a previous job with their platform (it was a marketing dashboard). Management wanted developers to suppress error messages because users wouldn't know what to do with them. However, users always contact the help desk when things go wrong. User feedback became much harder for us to understand, so issues would take much longer to resolve. Instead of saying "I did ABC and I saw a message that said 'XYZ'", they would say "I did ABC and it broke"

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

#223
post #67
post #35

Earlier quoted context omitted.

Can anyone explain why a crash in xscreensaver results in the computer being unlocked? It seems like this whole class of bugs could be fixed pretty easily by having a simple process watchdog run xscreensaver as a child process, and re-launch it if it crashes without first signalling that the desktop has been unlocked.

I don't believe the X system had/has a separate protocol for screen locking, or if it does, that any of the programs implement it. So xscreensaver is just another X client that happens to draw itself full-screen on top of all other apps and grab all user input. From the point of view of the display manager, a screensaver/screenlocker crashing is just a simple app crash. There's nothing in the protocol to suggest that…

From the point of view of the display manager

Argh. That would be the window manager, of course.

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

#224

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…

[deleted]

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

#225

Earlier quoted context omitted.

jwz has a lot to say about complex graphical toolkits/desktop environments and their complex locking mechanisms. It's an interesting series of posts. If you are not running xscreensaver on Linux, then it is safe to assume that your screen does not lock. Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy. https://www.jwz.org/xscreensaver/toolkits.html

Never directly link to jwz from HN. https://web.archive.org/web/20210117212403/https://www.jwz.o...

[deleted]

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

#226

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…

> I'm not sure why GNOME screensaver cannot do something like this. Lock screen crashing seems like something inevitable (especially considering buggy graphic card drivers and so on), and it makes sense to prepare for it so that crashes won't bypass the screen locker.

That is an option Linux Mint is considering[0] among other options.

[0]: https://github.com/linuxmint/cinnamon-screensaver/issues/354...

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

#227
post #216

Earlier quoted context omitted.

I would recommend not linking to jwz's website. Use web archive or something if you have to. jwz dislikes Hacker News and intentionally shows an NSFW image when Referer header shows Hacker News.

It's quite nice of Apple to strip this by default in Safari—didn't even realize it was a thing until I switched over to Chrome to see what you were talking about.

I didn't see it in mobile Chrome (well, Brave) but I kind of want to...

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

#228

Does anyone know why lockscreens in Linux have been such a joke? I remember trying Ubuntu couple years ago and when waking up my laptop it would show me my entire desktop with all the information displayed right there in the open for about 10-20 seconds before suddenly engaging the lockscreen. All you had to do was close the lid and open it again and you could just copy whatever was on the screen before the lock scre…

In the past I also had some information leaks with an Nvidia discrete graphics card, which seemed to not clear its RAM or something. I think it even persisted over restarts or similar complete session terminations. So I assume, driver issues may play into this too.

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

#229

Earlier quoted context omitted.

I would recommend not linking to jwz's website. Use web archive or something if you have to. jwz dislikes Hacker News and intentionally shows an NSFW image when Referer header shows Hacker News.

Can he at least update the text? HN was full of entrepreneurs and wantrepreneurs years ago. It is mostly big- and mid tech employees now, tech bureaucrats if you will.

Not to belabor the meta discussion, but your comment sparked a question. If it is how you say, and using a politico-economic lens, I wonder if there has been any discernible shift in commenter attitudes as the demographics have changed. Specifically, if the shift was from entrepreneurs -> skilled wage workers, as you’ve asserted.

The interests of the petit bourgeoisie (entrepreneurs, et al), the professional management class and that of skilled workers sometimes overlap. I think those overlaps would probably translate to some overarching strains of belief, for example, the tendency toward libertarian viewpoints on HN.

Sorry for the tangent, just had to get that out of my head!

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

#230

Earlier quoted context omitted.

jwz has a lot to say about complex graphical toolkits/desktop environments and their complex locking mechanisms. It's an interesting series of posts. If you are not running xscreensaver on Linux, then it is safe to assume that your screen does not lock. Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy. https://www.jwz.org/xscreensaver/toolkits.html

Anecdotally, I use xidle[0] and xlock[1], and have found both to be very reliable. xidle supports locking the screen by sending it SIGUSR1, which is really useful since you can trigger it from a process that doesn't have DISPLAY set. The trick on laptops is to block on sending the signal in the script you use to suspend, so that when the laptop resumes the display is already locked. 0 - https://github.com/steinex/xid…

I use physlock[0] which locks all of the ttys. I've had no issues.

[1] https://github.com/muennich/physlock

Post reply on HN