FAS and public Key auth

[brett lentz]

On Wed, May 21, 2008 at 9:06 PM, Mike McGrath <mmcgrath at redhat.com> wrote:
> Now lets say that one of our third party machines is allowing people to
> build via mock for PPC (this is one real request).  That third party box
> has the SSH keys of a number of people, lets say one of them is
> sysadmin-main.  The attacker would need to merely create an fas account,
> request access to the group that gives access to that machine and they'd
> be able to take the ssh keys as people log in.
>

Shouldn't the builds be done through Koji?  Why would someone be doing
builds with mock, but not through Koji?

Secondly, any attacker can already create a fas account, and use a bit
of social engineering to gain enough access to do damage. There are
already some obvious attack vectors in the current processes that are
much more vulnerable than the configuration of third party systems.

That said, that doesn't mean we should ignore potential risk from
blindly trusting third party systems. I would recommend that, at a
minimum, third party systems should run with selinux on and enforcing.
This would afford some additional assurance of the system's security,
but won't solve all problems.

> Now, I've never actually done this.  It's just my understanding that it'd
> work that way.  If you had root on a box and I sshed there with my ssh
> key, would you not have access to take the key and log in to other boxes
> as me?
>

I'm not a crypto guy by any stretch. But, my understanding is that no,
that's not how it public key authentication should work. As I
understand it, your private key is never sent across the wire and
therefore even with root on the remote system, an attacker could only
ever has access to your public key. This is assuming that your private
key isn't also in your home directory on the remote system (i.e. the
only local file they have is the authorized_keys). Please double-check
RFC 4252 for more details.


> So my question is, is this a real risk or is there a precaution in SSH
> preventing the attack i'm describing (basically a man in the middle type
> attack)
>

I think the mitm risk is fairly low. I think there are other risks,
such as not having direct control over keeping third party systems up
to date, or allowing third party systems running non-Fedora or
non-RHEL distros (e.g. the latest Debian openssh debacle). Privilege
escalation on the remote system is also a concern. Thankfully, selinux
can mitigate the last fairly effectively.

I definitely don't think this should be done lightly.

> I can think of a number of options to prevent this but I'm curious what
> the rest of you think.
>

I think that keeping the keys secure is only a small piece of the
puzzle. One option that helps mitigate the keys issue to some extent
is if we adopt a "pull" model with third party systems. We give them a
public key that allows us to execute commands on the system and pull
results from it, but the remote systems never get access into the
Fedora production systems.

>        -Mike
>

---Brett.