On Wed, 21 May 2008, brett lentz wrote: > 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? > Some will want access to the build roots and things to test. There's other reasons third party people would want to setup accounts with us as well that don't involve the account system. > 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. > Maybe, maybe not. If someone wants to gain our trust (which, admittedly would require them to do a lot of work to 'prove' themselves) they could. But thats different then doing the bare minimum to, for example, get in the cvs extras group. > 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. > But how would this protect us in any way if the users of that system had root on it? Since all of these 3rd part systems aren't officially monitored by us we have to assume the worst on each of these hosts. > > 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. > You think mitm is fairly low but is it really? Lets say, for example, you forward your ssh agent to this remote host. What are the implications there? -Mike _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
