no, actually, your SUID program which is "sudo, but written in rust" is not actually "safe" because "memory safety"
the primary vulnerability for programs like this is logic errors, which rust can't do anything about on its own.
12
76
449
Conversation
Replying to
Admittedly Rust *style* discourages a lot of logic error classes, beyond memory safety issues. But unlike the hard guarantees of memory safety of safe code, there are no such guarantees here, just tools to hopefully encourage people to write better code.
2
65
well it would have been slightly better perhaps without this root privilege escalation vulnerability caused by a memory safety issue. :')
1
1
At any rate I largely agree that magically replacing things isn't the greatest idea. However just because the "primary" problem with a particular class of application isn't directly addressed, that doesn't mean that all the other issues that also affect it are not important.
1
1
2
There doesn't need to be a more secure implementation of su and sudo but rather the bad concepts need to be abandoned. On a server, it's far better to have key-only SSH login and set up a proper way of delegating access rather than trying to do it based on CLI command names/args.
1
Make a user that has access to the functionality and provide access via keys. It shouldn't even be possible to attempt to login to accounts via passwords locally. Normal default when you create a user is that password login is disabled and they can't change it since it's unset.
1
Supposed use case for these tools is on a multi-user server for delegating privileges via CLI command names/syntax. Bad idea.
If you're giving access to everything as root, you might as well just be using key-only ssh as root. Can use it via localhost.
What does sudo offer?
Replying to
On a conventional Unix-like system, how do you propose to give a user the ability to run the commands necessary to restart the HTTP daemon without also letting them reconfigure the whole server?