On Wed, May 21, 2008 at 9:06 PM, Mike McGrath <mmcgrath@xxxxxxxxxx> 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. _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
