Using sudo with password is bad, as the password is prone to keyloggers.
So sudo should not need passwords but some other method to protection against becoming root too easily, like Yubikey.
However you cannot use such a method in many situations, for example if remote authentication is not available.
So we still need fallback to password auth in such a case.
Idea: Two ways:
Normal SUDO with password.
Secondary SUDO without password through some other means.
Example:
Usual way:
start "sudo su -" or any other command
give password
you are root, as usual
New way:
start "root" or "root CMD"
this invokes "sudo root -r su -" or "sudo root -r CMD"
the forked root asks an authenticator for permission
It then runs like rootsh or script in it's own PTY
But permission can be revoked any time remotely (lockdown)
if you continue typing, the authenticator is asked again
If successfully, everything continues as usual
If something fails you can still back up to the usual way.
Unsure if logging shall be implemented. If so it differs from rootsh as follows:
Never use something like unencrypted syslog (WTF?)
Recording must not be secret to user.
Use encrypted link.
Record keystrokes as soon as they happen (Optionally).
Record output as soon as it happens (Optionally).
Transactioned, recording must be done successfully before it is forwarded
Unknown how this can be done, so recording is not implemented until this is clear.
For the permission thing, there may be several ways:
On a timed base like SUDO.
On certain keys (CR/LF/SPC).
Permission shall not break if link to authenticator breaks.
Insecure relaying of answers must be possible.
Mutual authentication between root and authenticator.
Authenticator:
Uses HTTPS like protocol
CONNECT PROXY support (for relays)
SSL certificates with client certificate checking
TCP is ok, no need to support UDP, too.
Protocol is stateless and reconnectable. Network outages do not much harm.
Protocol works with pseudo names and registry, so not everything must be directly connected all the time.
Never rely on shared secrets! Always asymmetric!
Trust checking:
SSL only for transport authorization, not command authorization
Application protocol to allow/revoke etc.
Application protocol authenticated again based on PKI
Modular framework of permission checking (checking of ticket)
Need at least 2:
Android OTP authenticator app.
Linux commandline client authenticator app (for example Yubikey)
DuoSecurity-support?
Security examples:
Common CA for communication. Certificates are checked against the CA cert. So both sides are authentic. But only used for communication encryption and MiTM protection, not for authorization.
Anroid OTP creates a ticket which can be checked by the application without external ressources. This shall be the default.
Yubikey plus PIN eventually transported to the authenticator module and checked by the host itself.
If DuoSecurity is requested, Duo must be performed completely by the host, again, I think. Would be better if done by the relay. Can this be splitted onto different devices securely somehow, so that compromized relays are no problem?
Secondary layer to secure root logins.
sudo
with password is bad, as the password is prone to keyloggers.sudo
should not need passwords but some other method to protection against becoming root too easily, like Yubikey.Idea: Two ways:
Example:
Usual way:
New way:
root
asks an authenticator for permissionIf something fails you can still back up to the usual way.
Unsure if logging shall be implemented. If so it differs from
rootsh
as follows:For the permission thing, there may be several ways:
root
and authenticator.Authenticator:
Trust checking:
Need at least 2:
Security examples: