Hacker News Reader

Comment by mehrdadn | Hacker News Reader

Can I just point out that this is just one vivid example of why tying setuid permissions to a file is a terrible design to begin with? Permissions should be derived from the execution context at run time. (People might hate me for saying this, but this is one of those design decisions Windows fundamentally gets right.)

View on HN

Even Windows gets this wrong at times, with several UAC bypass techniques exposed by auto-elevating binaries. Still, Microsoft has done a great deal of work with the Windows privilege model to prevent things like this, and these issues are steadily being resolved.

>with several UAC bypass techniques exposed by auto-elevating binaries

According to Raymond Chen, a MSFT employee:

>There really are only two [UAC] settings.

>* Always notify

>* Meh

https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94...

https://www.networkworld.com/article/2295224/microsoft--uac-...

Pasting a random article from 2007 with no other comment is not a great rebuttal of what they said.

A _lot_ has changed since 2007.

I'm pretty sure the fact that it's not a security boundary has not changed since 2007. They should've probably marketed it better to clarify this, but that's not a technical issue. It was always a horrible idea to run a malicious program under your credentials relying on UAC to enforce any security. That's never changed.

How do you suggest implementing passwd without setuid?

Using the design of the LSASS is one way, as mentioned. Others include OpenWall's tcb, and Daniel Rench's userdirs.

* https://www.openwall.com/tcb/

* https://web.archive.org/web/20030919191907/http://dren.ch:80...

Off the top of my head? Ask a system service that has the privilege to change it for you after authenticating you.

Isn’t that exactly what passwd is? A system service that has permission to change the passwords file?

No, the point is that passwd should obtain its privilege by virtue of being started by a privileged process, not by virtue of being marked as a privileged program when it's run by an unprivileged user.

How do you start the privileged process as a normal user?

You don't. It's already started as part of the system. Or you ask some part of the system that is willing to authenticate you to do it for you.

Shhhhhhhhhh.

Stop giving systemd more ideas.

(/s)

(But seriously, imagine a world where you can't get root because D-Bus crashed.)

PolicyKit essentially already does this, and all of the systemd *ctl commands support authentication via polkit

TIL (so that's what the whole PolicyKit thing was all about).

Now I'm wondering what its worst case crash behavior is like.

Reply on news.ycombinator.com