3 ms·
The remote daemon has its own account and is given a privilege that allows it to connect a network socket to a pseudo terminal.
by charcircuit 9mo ago
The remote daemon has its own account and is given a privilege that allows it to connect a network socket to a pseudo terminal.
- esseph 9mo agoAny breach of the daemon will still give access to a system that can approve/deny user logins. Breaching the daemon therefore allows permission escalation, because you can simply jump to an account. Chain with any local vuln of your choice to completely own the box. It doesn't matter what user it is running as. If this was so easy to deal with, someone would have done it. Instead, we get endless HN comments about people that act like they can do better but never submit a PR.
- charcircuit 9mo agoBreaching the daemon only allows for the attacker to get access to the login. User accounts should still be secured requiring authentication. >If this was so easy to deal with, someone would have done it. Sadly this is not the case. There is a lot of inertia towards solutions like ssh or sudo. It may be easy to delete them, but actually getting such a changed accepted is no trivial task.
- esseph 9mo ago> Breaching the daemon only allows for the attacker to get access to the login Yes, but potentially any login. See the problem? If you compromise the gatekeeper, you are now the keymaster. Or whatever :)
- charcircuit 9mo agoI'll admit it is still problematic. But at least there is only 1 gatekeeper instead of 2.
- jmb99 9mo agoHow is that better?
- charcircuit 9mo agoYou can focus all of your energy into strengthening and testing a single point of the system instead of having to do it for many.
- esseph 9mo agoYou're grasping for straws a bit here. This is already done for ssh as the defacto remote access mechanism for a very long time.
- direwolf20 9mo agoThose are already unprivileged operations, but how does it start the initial process in that terminal with the correct privileges for a different user?
- charcircuit 9mo agoThe kernel could authenticate the user before starting it.
- direwolf20 9mo agoHow does it do that?
- charcircuit 9mo agoThere are many ways from passkeys to SAML. Though for complex methods we may want a dedicated services outside the kernel.
- direwolf20 9mo agoHow does that service get launched with the privilege to switch to any user?
- charcircuit 9mo agoThe kernel can start a process with any user it wants. The user doesn't have to switch during the process's life.
- acdha 9mo agoYes, but that has to happen somewhere. OpenSSH already uses privilege separation to limit the scope of the code which requests the kernel set the user for the process for the session. Can you say where precisely you think that should happen instead? If you’re saying it should delegate to login(1) it would be useful to discuss in detail what you see OpenSSH doing which is weaker because otherwise that seems like it’s just recreating chances for this CVE without meaningfully improving a hardened implementation.