Re: Yet Another New systemd Feature

On 5/7/24 10:29, Richard Kettlewell wrote:

I think this is optimistic at best.

I've used it that way for years.
The big outsourced IT company that I worked for converted hundreds of clients (each with hundreds of servers using sudo) to this model.
It was a PITA to do the conversion.  But once it was done, things worked better, there was more tracking, and everybody involved had a much better idea of what was going on.

One reason is the difficulty of writing correct setuid programs. sudo’s CVE record shows how hard this is (as if there were any doubt by now). Some of the historical CVEs stem from it being written in C but for others the implementation language doesn’t seem to be very relevant.

I didn't mean to imply that sudo was perfect.  If anything, it's imperfect.  But nothing is perfect.  It's also got decades of people poking at it with sticks of varying sharpness.

The other is that impracticality of ensuring the the commands you want to run don’t allow further escalation. Of course you may be auditing all the commands you permit in this way but realistically, most people doing this aren’t.
 Some of these issues translate to any other strategy for managing privilege escalation (there is no free lunch); others don’t.

I had typed out something to similar sentiment, then saw your comment.

Certainly getting the escalated process out of the calling user’s environment, as run0 does, is a real improvement. Being able to remove setuid/setgid programs from Linux would be a big step forward in security terms.

I don't agree that removing setuid / setgid binaries from systems is the panacea some make it out to be.
I also suspect that we may be looking at sudo, et al, slightly differently.
All of the use cases we had at my previous employer were business justifiable (as in the business benefited from people running the commands) and had multiple layers of management approval / blessing for the requestor to be able to run them.
So sudo really was a way to conveniently provide the approved commands without the requestor needing to go through the hassle of checking the shared password out of a database, logging in as the target user, running the necessary commands, logging out, and ensuring that the password was rotated.
Sudo was really a way to make it easier for people to access the privileges that they had already been granted.
The more people that need to access a shared account, the more benefit there is in them not utilizing the shared password for everything.
Size of team and managerial bye in makes a HUGE difference.
--
Grant. . . .