Might be a good move [LWN.net]

Might be a good move

Posted Jun 24, 2025 17:45 UTC (Tue) by linuxrocks123 (guest, #34648)
In reply to: Might be a good move by pizza
Parent article: GNOME deepens systemd dependencies

I don't think that's a realistic concern.

Unless there is absolutely no sanity left among mainstream Linux desktop programmers, there's no option to start a shell from those greeters. All you can do is click some stuff and enter text in the username and password fields.

Sure, I guess theoretically you could buffer overflow the username or password field, but since you (again, if there is any sanity left in this world) are limited to the ASCII keys you can physically type on the attached keyboard, it would be pretty damn hard to construct an exploit. And, hopefully, these greeters aren't so broken that someone is actually using something gets() on the user/pass fields, so there's unlikely to be a hole to exploit even if you could somehow find a way to exploit it once you found it.

If someone is actually worried about greeter exploits, why not just write a new greeter in Rust like the cascade of attention-deficit teenagers in charge of this space does with everything else? Why do something ridiculous like using temporary user IDs for xdm? Most machines are only going to be running one copy of xdm anyway, so, if someone can exploit xdm to send usernames/passwords to an attacker, you haven't substantially mitigated that problem by using temporary user IDs.

to post comments

Might be a good move

Posted Jun 24, 2025 19:21 UTC (Tue) by pizza (subscriber, #46) [Link]

> Unless there is absolutely no sanity left among mainstream Linux desktop programmers, there's no option to start a shell from those greeters. All you can do is click some stuff and enter text in the username and password fields.

Maybe the "greeter" is sane, but can the same be said for everything in its tech stack?

> limited to the ASCII keys you can physically type on the attached keyboard,

1) What about non-password-based login mechanisms?
2) What about non-ASCII (especially CJK that requires more advanced input methods)
3) _Which_ attached keyboard/mouse[/camera/biometric/etc]?

> Why do something ridiculous like using temporary user IDs for xdm?

1) "Defense in depth"
2) It's a lot less work than "rewrite everything else" (and inevitably introduce a different set of bugs/regressions)

> Most machines are only going to be running one copy of xdm anyway,

....And what about those which don't?

Might be a good move

Posted Jun 24, 2025 20:00 UTC (Tue) by smurf (subscriber, #17840) [Link] (23 responses)

> All you can do is click some stuff and enter text in the username and password fields.

… and shut down / restart the system, and configure some assistive tools, and attach a Bluetooth keyboard, and read a 2nd factor USB key, and whatnot.

Most of this requires a working dbus server that's attached to a specific seat. The session dbus connection's socket is in, surprise, /run/user/UID/bus, unless you set an envvar (which has its own set of potential issues).

In other words, different and transient user IDs for each login screen aren't just a good idea from a security PoV, they also afford removal of a number of crude hacks and/or enabling tools that didn't want to work right before.

Might be a good move

Posted Jun 25, 2025 2:51 UTC (Wed) by linuxrocks123 (guest, #34648) [Link] (22 responses)

> … and shut down / restart the system, and configure some assistive tools, and attach a Bluetooth keyboard, and read a 2nd factor USB key, and whatnot.

Oh, dear. They really managed to overcomplicate things, now didn't they?

> Most of this requires a working dbus server that's attached to a specific seat. The session dbus connection's socket is in, surprise, /run/user/UID/bus, unless you set an envvar (which has its own set of potential issues).

DBUS to solve a problem that xdm has been solving without DBUS since 1988. Hilarious. And, because they managed to f* up what should be a simple GUI version of getty so badly, now they want to f* up UID management too to try to paper over that. ROFL. There truly is no sanity left among the cascade of attention deficit teenagers.

Ah, well. I'm over here with my Slackware, which will never incorporate any of this ongoing offense against good taste, so not my problem. And they do have version control, so they can always just revert all that nonsense when they grow up.

Might be a good move

Posted Jun 25, 2025 4:30 UTC (Wed) by jem (subscriber, #24231) [Link]

>> … and shut down / restart the system, and configure some assistive tools, and attach a Bluetooth keyboard, and read a 2nd factor USB key, and whatnot.
>Oh, dear. They really managed to overcomplicate things, now didn't they?

These are problems that have to be solved somehow. What if a workstation only has a bluetooth keyboard? It has to be recognized by the display manager.

Some time ago there was talk about a public sector Linux desktop. Logging in using a smart card is an absolutely essential requirement for the public sector in large parts of Europe. This is technically very similar to the USB key case, and requires talking to local hardware (the card reader).

Might be a good move

Posted Jun 25, 2025 7:45 UTC (Wed) by smurf (subscriber, #17840) [Link] (20 responses)

> DBUS to solve a problem that xdm has been solving without DBUS since 1988.

No it has not. Tried to do a 2FA login with xdm lately? Attach a Bluetooth keyboard? Turn on the Sticky Mods a11y helper so that a user who doesn't have the usual number of hands and/or fingers can log in?

You want to rewrite all of that to work directly as XDM plugins instead, be my guest, but I'd rather use whatever everybody else is using. Fewer bugs that slip through the cracks that way, not to mention vastly less pointless work.

Might be a good move

Posted Jun 25, 2025 17:15 UTC (Wed) by linuxrocks123 (guest, #34648) [Link] (19 responses)

> No it has not.

Yes it has too.

> Tried to do a 2FA login with xdm lately?

I don't use xdm. I use console logins at runlevel 3 and then start X if I want it. But, to answer your real question, 2FA is PAM's job, not the greeter's, so of course it would work work xdm.

> Attach a Bluetooth keyboard?

Those can be configured to auto-connect.

> Turn on the Sticky Mods a11y helper so that a user who doesn't have the usual number of hands and/or fingers can log in?

Seriously? You think no one bothered to think of sticky keys with xdm from 1988 to whenever Poettering started f*ing things up? Add +accessx to /etc/X11/xdm/Xservers and you're good.

> You want to rewrite all of that to work directly as XDM plugins instead, be my guest, ...

Traditional UNIX tools already work for these corner cases, and, since traditional UNIX tools are modular and well-designed, they work without requiring a Rube Goldberg service manager to do ghastly hacks like manipulate UIDs.

> ...but I'd rather use whatever everybody else is using. Fewer bugs that slip through the cracks that way, not to mention vastly less pointless work.

Popularity can help, but its effects plateau quickly. Software that is simple and well-designed generally inherently has fewer bugs at the outset, and it is also far less trouble to manage and configure than more complex software. Additionally, more mature software has had a much longer time to see its original bugs fixed.

Might be a good move

Posted Jun 25, 2025 17:41 UTC (Wed) by jem (subscriber, #24231) [Link] (18 responses)

>2FA is PAM's job, not the greeter's, so of course it would work work xdm.

The greeter needs to prompt the user to insert the token (USB key or smart card), and after that prompt for the PIN code. The greeter also needs to respond to errors, like if an invalid token is inserted or the wrong PIN code is entered.

Might be a good move

Posted Jun 26, 2025 6:51 UTC (Thu) by linuxrocks123 (guest, #34648) [Link] (17 responses)

Okay, so, before I get into this again, I hope you guys realize that the weird auth tricks you're saying XDM can't do are all also things the login program running on the gettys couldn't do and that creating a setup where the gettys on your machines all are broken would be an insane thing to do.

(Fortunately, XDM actually can do the weird auth tricks, because PAM is in charge of all of the weird auth tricks, and login can use PAM, too.)

> The greeter needs to prompt the user to insert the token (USB key or smart card), and after that prompt for the PIN code.

The primary enterprise 2FA security theater crap I've encountered has been in the form of "install this stupid app on your phone, and, when you try to log in, we will hang the login until you respond to a notification on your phone." The greeter obviously has no role in that.

The greeter also has no role in the alternative 2FA security theater I encountered when I told an organization I didn't have a cell phone that would work with the app they wanted me to use, so they sent me a Yubikey USB device where you press a button and it spits out a bunch of letters. If someone wanted to use that with PAM, they could claim the USB keyboard device created when a Yubikey is plugged in and hang the login until the button is pressed and the letters are spit out.

Since those are the only two situations I've personally encountered, I'm unfamiliar with the enterprise 2FA security theater crap you're describing. If you're using a password, a PIN, and a smart card all together, that would be 3FA in a way which seems pointless because the password and PIN are duplicative factors. But, I guess PAM could probably take the PIN and password munged together if someone really wants that. For this smart card, it looks like there's a PIN but no password, so you can just put the PIN in the standard password field: https://docs.oneidentity.com/bundle/safeguard-authenticat...

> The greeter also needs to respond to errors, like if an invalid token is inserted or the wrong PIN code is entered.

PAM will just fail the login if that happens. An administrator could find the reason in the logs if it keeps happening.

Might be a good move

Posted Jun 26, 2025 7:21 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (13 responses)

> creating a setup where the gettys on your machines all are broken would be an insane thing to do

? No, this is an entirely normal thing. There's an expectation that the login environment be able to present things through audio, to change the colours it's presenting, to support touchscreen text entry, to support eyetracking input devices. There's a whole bunch of accessibility requirements that can never be satisfied by a text console, and that's just fine.

But even outside accessibility, yes, complex authentication is expected to fail in simpler environments. How does a console interface interact with PAM in such a way that you can choose which of the multiple authentication mechanisms with it should trigger with appropriate UI guidance? How does your getty login manage user choice of whether to use a password, fingerprint, or facial recognition? You may not care about these use cases, but the people deploying Linux in enterprise environments (including me) do.

Might be a good move

Posted Jun 26, 2025 14:24 UTC (Thu) by linuxrocks123 (guest, #34648) [Link] (12 responses)

> There's a whole bunch of accessibility requirements that can never be satisfied by a text console, and that's just fine.

Text console is one of the most inherently accessible interfaces for the blind because it is extremely easy to do text-to-speech with. I recently read a blog post by a blind Linux user in which he lamented that he's recently had to switch back to the console since GUI accessibility is degrading as GTK4 was adopted more, since GTK4 was released with some bad accessibility bugs. Unfortunately, I can't find it now. I think it was on BlueSky.

> How does your getty login manage user choice of whether to use a password, fingerprint, or facial recognition?

First thought that came to the top of my head was to put linuxrocks123-pass, linuxrocks123-finger, or linuxrocks123-facial in the the username field. You could put those instructions in /etc/issue for user friendliness, right below your standard enterprise all-caps threat that I'm sure is already there. (You know what I mean, that "ATTENTION: IF YOU DO SOMETHING WE DON'T LIKE WE WILL MAKE SURE YOUR LIFE BECOMES A LIVING A HELL" thing.)

Might be a good move

Posted Jun 26, 2025 17:49 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (11 responses)

> Text console is one of the most inherently accessible interfaces for the blind

That's great, except you can't run a modern browser there so you're cut off from most of the world. But even then, accessibility isn't purely about people being blind, there's a giant array of other accessibility mechanisms that can't possibly work in a text-only world. Someone who needs to use an eye-tracking on-screen keyboard isn't going to do very well at the console.

> First thought that came to the top of my head was to put linuxrocks123-pass, linuxrocks123-finger, or linuxrocks123-facial in the the username field

Ah, so we'd encode additional logic into getty to parse out the PAM stack it should use? That'd probably work, and now we're starting down the road that gets you to the level of complexity modern graphical login environments have.

Might be a good move

Posted Jun 26, 2025 21:01 UTC (Thu) by linuxrocks123 (guest, #34648) [Link] (10 responses)

> That's great, except you can't run a modern browser there so you're cut off from most of the world.

https://www.brow.sh/
https://github.com/fathyb/carbonyl

> Ah, so we'd encode additional logic into getty to parse out the PAM stack it should use?

No, "getty" (you actually mean "login") wouldn't change. PAM would interpret the username and decide what to do based on the suffix. Or, if you don't like that, I guess you could type one of the actual password, "finger", or "facial", to select what you want to do at the password prompt.

Or you could just use pam_any to try all of them at once: https://github.com/ChocolateLoverRaj/pam-any

That would probably best for that situation.

Might be a good move

Posted Jun 26, 2025 22:28 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (7 responses)

You're narrowly focusing on one aspect of accessibility and ignoring the much wider spectrum (there are people who use screen readers but still have enough vision that presenting them with graphics is worthwhile, for instance) which leaves me pretty convinced you don't actually care about accessibility - a text only interface is an option for a set of people who need accessibility features, and entirely unusable for another set. A graphical login system needs to handle those situations, which means it needs more complexity.

And shoving this into PAM in the way you describe breaks any users who have hyphens in their username, and running everything in parallel provides no indication to the user what they should be trying and is going to be confusing if the face recognition fails because they're looking down at their keyboard to find the fingerprint reader. The complexity that exists isn't gratuitous, it solves real problems for real people. You don't need to care about those problems, and you're free to run software that doesn't solve them. But I *need* software that solves these problems because I have users and policies that have these requirements and telling me that this software shouldn't exist doesn't make my problems go away.

Might be a good move

Posted Jun 27, 2025 23:08 UTC (Fri) by linuxrocks123 (guest, #34648) [Link] (6 responses)

If your usernames have hyphens then yeah type it in the password field.

> running everything in parallel provides no indication to the user what they should be trying and is going to be confusing if the face recognition fails because they're looking down at their keyboard to find the fingerprint reader.

As long as they find the fingerprint reader, they won't have a problem. pam_any is successful if *ANY* of the authentication options succeeds.

> The complexity that exists isn't gratuitous, it solves real problems for real people.

Agree to disagree.

> But I *need* software that solves these problems because I have users and policies that have these requirements

Not users, I wouldn't think, but, I am sure you have *policies* with those requirements, likely the same *policies* that gave CrowdStrike's customers so many problems a year ago (and serves them right, I'd say).

> telling me that this software shouldn't exist doesn't make my problems go away.

A problem doesn't exist because software that meets stupid requirements doesn't exist. A problem exists because someone has stupid requirements in the first place. Now, if you can't solve the "someone has stupid requirements" problem, then sure, maybe you do need to use or create software that meets the stupid requirements as a workaround.

But can't you at least cordon the stupid software off from the rest of the system and not make it the default? Must you really expand the attack surface of the login prompt so much that you then have to take heroic measures to give each individual login prompt its own UID to protect it from *other instances of itself*?

I'd say no. I'd say let the enterprise buffoons write their own greeter and maintain it themselves. But, I'm on Slackware, so none of this is my problem anyway.

Might be a good move

Posted Jun 27, 2025 23:16 UTC (Fri) by intelfx (subscriber, #130118) [Link] (1 responses)

> Agree to disagree.

That's not how it works.

"Agree to disagree" is only appropriate in situations when both sides have presented compelling, non-mutually-exclusive arguments, but can't decide *which* arguments have more weight. You haven't presented any, short of "I don't have that problem, so I don't care about solving it".

Might be a good move

Posted Jun 28, 2025 3:13 UTC (Sat) by linuxrocks123 (guest, #34648) [Link]

Agree to disagree :P

Might be a good move

Posted Jun 28, 2025 8:20 UTC (Sat) by jem (subscriber, #24231) [Link] (3 responses)

Let me tell you about a two factor authentication system I'm familiar with. In this system, every user has a smart card. To log in to a workstation, they insert the card into the reader and, if the card is valid, a PIN entry pop-up is displayed. After entering the correct PIN they are logged in.

No field for entering a user name is displayed, the user is identified from the certificate the card sends when the negotiating with the system. The backend system also checks that the user is authorized to log in by examining the certificate (which is digitally signed.)

The card also functions as a visual ID badge. When the user leaves their desk, they have to remove the card from the reader and carry it with them. This automatically locks the workstation.

Why a smart card? A smart card is designed to follow the Unix principle: do one thing, and do it well. The "one thing" in this case is to be a unique, extremely hard to forge physical token, designed to protect the private key of the user. A smart card also has a very small attack surface: a serial interface with a limited command set.

This system is in use all over the public sector here, nation wide. It has been in use for at least 15 years now. The workstations are running Windows, of course. Trying to sell a "Public sector Linux OS" as a replacement with this functionality haphazardly shoehorned into an XDM-like user interface is doomed from the beginning. That ship sailed a long time ago.

Might be a good move

Posted Jun 28, 2025 23:58 UTC (Sat) by linuxrocks123 (guest, #34648) [Link] (2 responses)

That sounds like both a cool setup and a fancy way to waste taxpayer money. Not super secure to be using a PIN instead of a password as the second authentication factor, though.

You could certainly make that work on Linux without any changes by just leaving the username empty and typing a password for the PIN, so I'm not sure why at you think it would present a problem for a standard greeter or why support would need to be "shoehorned". However, if you wanted to make the login UX superb, with a whizz-bang popup window saying "Hello <Name>" like you described, you could certainly make a custom greeter that watches for the device to be plugged in and then uses PAM to authenticate after plugging it in. You could do the auto-locking thing with a few custom udev rules and a script to do xscreensaver-command --lock when the key is removed.

Whether or not you wrote a custom greeter, you'd want the complexity in PAM so that people can still unlock xscreensaver by plugging in the device and typing the PIN in the xscreensaver password field.

In the end, these problems are not hard. There's no reason for these programs to be complex, and there are good reasons for them not to be.

Might be a good move

Posted Jun 29, 2025 10:52 UTC (Sun) by cortana (subscriber, #24596) [Link] (1 responses)

> Not super secure to be using a PIN instead of a password as the second authentication factor, though

"PIN" does not imply "4 numeric digits". But in any case - the smart card will only allow authentication attempts at a configured rate, and will lock down, preventing any further attempts after a certain number of failures.

> You could certainly make that work on Linux

sssd already implements all this AFAIK. At least, what jem describes is exactly how I use my YubiKey, except that I haven't enabled the option to lock the screen when it's unplugged, because I'm using this on my home systems and I often do want to have my laptop and desktop both active at the same time!

Might be a good move

Posted Jun 29, 2025 22:02 UTC (Sun) by linuxrocks123 (guest, #34648) [Link]

Good to know. It looks like pam_sss is the module that bridges sssd to standard login programs: https://linux.die.net/man/8/pam_sss

Might be a good move

Posted Jun 27, 2025 6:21 UTC (Fri) by smurf (subscriber, #17840) [Link] (1 responses)

> That would probably best for that situation.

Please accept the fact that there are many people out there who do not think, for various reasons (not all of which can be argued away), that "that situation" is acceptable these days.

NB: using expletives to describe these requirements ("security theater crap") and/or systemd and/or its implementation, goals or whatever doesn't help your case either.

Might be a good move

Posted Jun 27, 2025 23:14 UTC (Fri) by linuxrocks123 (guest, #34648) [Link]

> Please accept the fact that there are many people out there who do not think, for various reasons (not all of which can be argued away), that "that situation" is acceptable these days.

I don't think you're understanding the thread. There's a hypothetical situation where someone wants to do really weird auth, and we're talking about whether using PAM, which would work with every greeter, is better for that situation, or if it's better to create a greeter that handles the weirdness in the greeter itself. I hope that helps.

Might be a good move

Posted Jun 26, 2025 22:32 UTC (Thu) by elsandosgrande (subscriber, #174457) [Link] (2 responses)

> PAM will just fail the login if that happens. An administrator could find the reason in the logs if it keeps happening.

Do you mean that the login manager shouldn't report errors to the user at all, that it should just report a generic “login failed” error and that the user or administrator then should look in the system log(s) to see the details of said failure, or …? Neither of the two interpretations of your statement that I can think of right now sound like a great user experience compared to the login manager giving the user at least a bit more information regarding login failures.

Might be a good move

Posted Jun 27, 2025 23:27 UTC (Fri) by linuxrocks123 (guest, #34648) [Link] (1 responses)

> Do you mean that the login manager shouldn't report errors to the user at all, that it should just report a generic “login failed” error and that the user or administrator then should look in the system log(s) to see the details of said failure, or …? Neither of the two interpretations of your statement that I can think of right now sound like a great user experience compared to the login manager giving the user at least a bit more information regarding login failures.

mjg59 got into a bit of a stupid argument about whether it would work at all, not whether it would work well. Yes, of course an ideal greeter would say why the login failed. pam_info is the function that allows that message to be printed, but it has some prereqs that mean I don't think it actually works with the current versions of login and xdm. I expect that would be easy to fix if someone wanted to fix it.

Might be a good move

Posted Jun 28, 2025 23:59 UTC (Sat) by linuxrocks123 (guest, #34648) [Link]

Meant to say "mjg59 and I got into a bit of a stupid argument"

Might be a good move

Posted Jun 24, 2025 21:36 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> Sure, I guess theoretically you could buffer overflow the username or password field

Some password greeters can do remote calls to LDAP, there can be greeters that can do a 3D scan of your face with a call to a remote service to validate it, etc. That's quite a sizeable attack surface.

And I have personally seen a greeter that opens a browser and does an SSO login to retrieve the user's details.

Might be a good move

Posted Jun 25, 2025 3:35 UTC (Wed) by linuxrocks123 (guest, #34648) [Link]

> And I have personally seen a greeter that opens a browser and does an SSO login to retrieve the user's details.

I actually wrote a greeter like that for a university! The browser was locked down, of course. It was a very unusual set of requirements.