ssh-agent: hardening

[glitsj16]

IMO there's nothing holding back making the (OpenSSH) authenticator agent profile very tight. Contrary to the SSH client its functionality is very limited and it doesn't need access to much of the file system.

[kmk3]

Suggested change

nou2f

If anything, this would be the quintessential application that uses hardware
keys :p

[kmk3]

@glitsj16 on Mar 25:

Not according to my observations no. Other parts of OpenSSH need that kind of
access, like ssh, ssh-add, ssh-copy-id, ssh-key{gen,scan}... The
authentication agent itself is kept 'dumb' on purpose (which is a good thing
security-wise). We don't have profiles (yet) for ssh-add and the others
mentioned.

Sorry, now that you mention it, the hardware keys might only be needed by
ssh-add, not ssh-agent (I'm not sure).

[glitsj16]

I agree. But the way I read its man page (in this case more specifically the -P switch) it's actually ssh-add that needs u2f access, the agent only stores whatever is put in. Sadly I don't have access to hardware keys to properly test my assumptions. Does anyone on the collaborator team?

[glitsj16]

Well that's the thing. I'm not sure either. Too many open-ended questions for comfort... Especially the points you refer to below, in combination with @rusty-snake's hint send me back to the drawing board :)

[kmk3]

Note that the following might be one reason that this is not currently hardened
too much:

From ssh-agent(1):

     command [arg ...]
             If a command (and optional arguments) is given, this is executed
             as a subprocess of the agent.  The agent exits automatically when
             the command given on the command line terminates.

     There are two main ways to get an agent set up.  The first is at the
     start of an X session, where all other windows or programs are started as
     children of the ssh-agent program.  The agent starts a command under
     which its environment variables are exported, for example ssh-agent xterm
     &.  When the command terminates, so does the agent.

     The second method is used for a login session.  When ssh-agent is
     started, it prints the shell commands required to set its environment
     variables, which in turn can be evaluated in the calling shell, for
     example eval `ssh-agent -s`.

     In both cases, ssh(1) looks at these environment variables and uses them
     to establish a connection to the agent.

That is, hardening ssh-agent could break running subcommands like in the
example:

ssh-agent xterm &

If that is a supported use-case, it might be better to only use firejail with
the subcommand.

Example:

/usr/bin/ssh-agent firejail /usr/bin/foo &

Or to remove ssh-agent from firecfg to ensure that the following works:

ssh-agent foo & # -> /usr/bin/ssh-agent firejail /usr/bin/foo &

[glitsj16]

Converted to draft. There are several important issues raised in review that need more testing. Thanks @kmk3 and @rusty-snake for their initial observations, remarks and questions. IMO we need to de-mystify our OpenSSH profiles/use cases. Could take some time though.

[glitsj16]

See #5751 for details on closing.