sudo+rootsh derivate: `root`

[hilbix]

Secondary layer to secure root logins.

• 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?