>Now back to PrivEsc, I actually found Antenore's suggestion inspiring. >It would work if we could force only part of the command to remain >constant, and use the constant part to perform non-interactive >authentication (e.g. by verifying a provided secret). Essentially >delegate authentication to a sub-command in a Bernstein-style exec >chain, like this: > >$ sudo -n -- verifyme -- ./my-amazing-script > ^ substitute doas, sup, etc > ^ authn helper, no suid > ^ arbitrary; exec only if authn successful > >Pros: > >- Can perform non-interactive verification >- No new suid cruft on your system; can be written in plain sh >- No black magic, keep existing setup almost untouched >- Just one extra rule in sudoers / doas.conf / config.h >- Reuses and plays nice with existing PrivEsc methods > >Cons: > >- ?
Thank you for clarifying. Later (well I hope) I'll show exactly what we do. As we use also the var SSH_ORIGNAL_COMMAND in the remote script. SSH keys management itself is the cons. We've some hundreds of keys, therefore you must keep a good Inventory of the keys.
