Hi all.
There is a darkish cloud of security uncertainty in my sky (and Fedora's!), so it's better to discuss this as early as possible to avoid any late notices.
I'm working on a web app that will help translation submission by allowing fedora translators (members of cvsl10n group) to commit translations to systems they don't have direct access to. Think: hosted.fpo (svn/hg/git).
https://hosted.fedoraproject.org/projects/transifex
The idea is that transifex will act as a proxy/mediator for translation commits. A translator will login to the transifex instance running on a host like `translate.fpo`, choose a module, a PO file to upload, and a destination file and click "submit". The system will commit the file for him. Underneath this is achieved by having the VCS admin create a user (eg. fedora-transifex) with a dedicated SSH key, and give it write access to the specific modules accepting translations. The transifex admin will then hook the repo and module up with the system. Each commit will be done by the "fedora-transifex" user, and the actual user's details (name, surname, email, fedora username) will be written in the commit message and Changelog file. Transifex supports filaname filters, so even if a module maintainer can't add ACLs to the repo, he can define them on the transifex side; for example, .*/po/(LINGUAS|Changelog|.*po$).
To put things in perspective, if we do this *right*, then *any* remote VCS could be hooked up. In the future, we could add a layer of "approval" before commits, so that the language maintainer (which we probably trust more than a john doe user with cvsl10n access) approves queued messages to be pushed. Or, we could give the option to a dev (for DVCS) to pull instead of the webapp to push.
To the implementation details now, transifex will become the client to the remote VCSs. Once the user clicks "submit PO", the webapp should commit (and push). The security question is how do we handle SSH keys?
- Where do we store them? Best place would be ~/.ssh/, because not all VCS commands support SSH options to point to a different config file.
- Right before running the checkout/pull and checkin/push commands, the environment should be right so that the commands run by the webapp will succeed over SSH. So an option the webapp (just like anyone) will have to "type" the passphrase to unlock the key. Or, use ssh-agent. And probably SELinux. What's the best approach with the minimum compromise risk?
- Where are we going to actually store the keys and passphrase? On-disk or in the DB? If we store them encrypted, where do we store the salt?
- Do we need a different process running that handles these security requests?
Seeking the knowledge and experience of the wise, the humble developer comes to you with seriously cold feet.
-d
Dimitris Glezos wrote:
Hi all.
There is a darkish cloud of security uncertainty in my sky (and Fedora's!), so it's better to discuss this as early as possible to avoid any late notices.
I'm working on a web app that will help translation submission by allowing fedora translators (members of cvsl10n group) to commit translations to systems they don't have direct access to. Think: hosted.fpo (svn/hg/git).
https://hosted.fedoraproject.org/projects/transifex
The idea is that transifex will act as a proxy/mediator for translation commits. A translator will login to the transifex instance running on a host like `translate.fpo`, choose a module, a PO file to upload, and a destination file and click "submit". The system will commit the file for him. Underneath this is achieved by having the VCS admin create a user (eg. fedora-transifex) with a dedicated SSH key, and give it write access to the specific modules accepting translations. The transifex admin will then hook the repo and module up with the system. Each commit will be done by the "fedora-transifex" user, and the actual user's details (name, surname, email, fedora username) will be written in the commit message and Changelog file. Transifex supports filaname filters, so even if a module maintainer can't add ACLs to the repo, he can define them on the transifex side; for example, .*/po/(LINGUAS|Changelog|.*po$).
To put things in perspective, if we do this *right*, then *any* remote VCS could be hooked up. In the future, we could add a layer of "approval" before commits, so that the language maintainer (which we probably trust more than a john doe user with cvsl10n access) approves queued messages to be pushed. Or, we could give the option to a dev (for DVCS) to pull instead of the webapp to push.
To the implementation details now, transifex will become the client to the remote VCSs. Once the user clicks "submit PO", the webapp should commit (and push). The security question is how do we handle SSH keys?
- Where do we store them? Best place would be ~/.ssh/, because not all VCS
commands support SSH options to point to a different config file.
- Right before running the checkout/pull and checkin/push commands, the
environment should be right so that the commands run by the webapp will succeed over SSH. So an option the webapp (just like anyone) will have to "type" the passphrase to unlock the key. Or, use ssh-agent. And probably SELinux. What's the best approach with the minimum compromise risk?
- Where are we going to actually store the keys and passphrase? On-disk or in
the DB? If we store them encrypted, where do we store the salt?
- Do we need a different process running that handles these security requests?
Seeking the knowledge and experience of the wise, the humble developer comes to you with seriously cold feet.
I'm surprised no one commented on this, I suspect they didn't read it :) How did your paramiko search go?
-Mike
Dimitris Glezos wrote:
Hi all.
There is a darkish cloud of security uncertainty in my sky (and Fedora's!), so it's better to discuss this as early as possible to avoid any late notices.
I'm working on a web app that will help translation submission by allowing fedora translators (members of cvsl10n group) to commit translations to systems they don't have direct access to. Think: hosted.fpo (svn/hg/git).
https://hosted.fedoraproject.org/projects/transifex
The idea is that transifex will act as a proxy/mediator for translation commits. A translator will login to the transifex instance running on a host like `translate.fpo`, choose a module, a PO file to upload, and a destination file and click "submit". The system will commit the file for him. Underneath this is achieved by having the VCS admin create a user (eg. fedora-transifex) with a dedicated SSH key, and give it write access to the specific modules accepting translations. The transifex admin will then hook the repo and module up with the system. Each commit will be done by the "fedora-transifex" user, and the actual user's details (name, surname, email, fedora username) will be written in the commit message and Changelog file. Transifex supports filaname filters, so even if a module maintainer can't add ACLs to the repo, he can define them on the transifex side; for example, .*/po/(LINGUAS|Changelog|.*po$).
To put things in perspective, if we do this *right*, then *any* remote VCS could be hooked up. In the future, we could add a layer of "approval" before commits, so that the language maintainer (which we probably trust more than a john doe user with cvsl10n access) approves queued messages to be pushed. Or, we could give the option to a dev (for DVCS) to pull instead of the webapp to push.
To the implementation details now, transifex will become the client to the remote VCSs. Once the user clicks "submit PO", the webapp should commit (and push). The security question is how do we handle SSH keys?
- Where do we store them? Best place would be ~/.ssh/, because not all VCS
commands support SSH options to point to a different config file.
- Right before running the checkout/pull and checkin/push commands, the
environment should be right so that the commands run by the webapp will succeed over SSH. So an option the webapp (just like anyone) will have to "type" the passphrase to unlock the key. Or, use ssh-agent. And probably SELinux. What's the best approach with the minimum compromise risk?
Well, storing keys, key-pairs or their passwords no matter crypted or salted, under the same user account that runs your webinterface generally is a bad idea. (In fact, storing passwords in general is a bad idea, no matter where they live).
Then again, you could have passwordless SSH private and public key pairs, but you wouldn't want those usable by the account that has your web interface running either.
A possible solution might be though, to have Transifex store the submitted PO's in /some/path/transifex, and then have another user account lift it's files and metadata, commit it to the pulled source repository (signed with GPG), and then push it upstream (with SSH priv/pub keys). Storing those passwords (plaintext or decryptable) would make just as much sense to me as allowing empty passwords to use these keys, but at least you prevent the webinterface from ever reaching those keys or files.
I bet there's some thoughts on this ;-)
Kind regards,
Jeroen van Meeuwen -kanarip
On Wed, 2007-07-11 at 21:30 +0200, Jeroen van Meeuwen wrote:
A possible solution might be though, to have Transifex store the submitted PO's in /some/path/transifex, and then have another user account lift it's files and metadata, commit it to the pulled source repository (signed with GPG), and then push it upstream (with SSH priv/pub keys). Storing those passwords (plaintext or decryptable) would make just as much sense to me as allowing empty passwords to use these keys, but at least you prevent the webinterface from ever reaching those keys or files.
Seems like an idea to pursue. If httpd is the user doing the TurboGears part, then have a transifexd that does the actual commits. That separation of the Web interface plus a good SELinux policy might be enough. How to trigger it? Or let it run as a full-time daemon?
The risk, folks, is that we get compromised and someone cracks an upstream SCM through our servers. Just think about that. Enough to turn a warm beer cold.
- Karsten
Karsten Wade wrote:
On Wed, 2007-07-11 at 21:30 +0200, Jeroen van Meeuwen wrote:
A possible solution might be though, to have Transifex store the submitted PO's in /some/path/transifex, and then have another user account lift it's files and metadata, commit it to the pulled source repository (signed with GPG), and then push it upstream (with SSH priv/pub keys). Storing those passwords (plaintext or decryptable) would make just as much sense to me as allowing empty passwords to use these keys, but at least you prevent the webinterface from ever reaching those keys or files.
Seems like an idea to pursue. If httpd is the user doing the TurboGears part, then have a transifexd that does the actual commits. That separation of the Web interface plus a good SELinux policy might be enough. How to trigger it? Or let it run as a full-time daemon?
The risk, folks, is that we get compromised and someone cracks an upstream SCM through our servers. Just think about that. Enough to turn a warm beer cold.
This is my worry too. It's almost enough to make me not want to do it for non Fedora projects but thats just bad. I'm hoping someone here has a good, clever way to solve this issue.
-Mike
Mike McGrath wrote:
Karsten Wade wrote:
On Wed, 2007-07-11 at 21:30 +0200, Jeroen van Meeuwen wrote:
A possible solution might be though, to have Transifex store the submitted PO's in /some/path/transifex, and then have another user account lift it's files and metadata, commit it to the pulled source repository (signed with GPG), and then push it upstream (with SSH priv/pub keys). Storing those passwords (plaintext or decryptable) would make just as much sense to me as allowing empty passwords to use these keys, but at least you prevent the webinterface from ever reaching those keys or files.
Seems like an idea to pursue. If httpd is the user doing the TurboGears part, then have a transifexd that does the actual commits. That separation of the Web interface plus a good SELinux policy might be enough. How to trigger it? Or let it run as a full-time daemon?
The risk, folks, is that we get compromised and someone cracks an upstream SCM through our servers. Just think about that. Enough to turn a warm beer cold.
This is my worry too. It's almost enough to make me not want to do it for non Fedora projects but thats just bad. I'm hoping someone here has a good, clever way to solve this issue.
-Mike
So do I. A great deal of security would be achieved by having just a small number of people actually know the GPG and RSA passwords, and have them manually trigger the full commit/push. Then again, that requires human interaction and isn't fully automated.
I'm thinking of a way where the user's credentials could be used to trigger the signed commit and push without needing the GPG/RSA password for the user transifex, but I'm not sure if it's even remotely possible to like 'share' these keys and authorize different users to use them, without (again) compromising the security principle of these tokens.
Kind regards,
Jeroen van Meeuwen -kanarip
On Sat, 2007-07-14 at 00:55 +0200, Jeroen van Meeuwen wrote:
Mike McGrath wrote:
This is my worry too. It's almost enough to make me not want to do it for non Fedora projects but thats just bad. I'm hoping someone here has a good, clever way to solve this issue.
The benefits of these new tools far outweigh the relatively slight risks. We really must step up and find a way to make it work.
My vote is simple: we do the best we can, we spell out what the security is and the risks involved, and we put that in front of upstream projects. We ask them to agree (via email?) to the risk/reward balance we present.
So do I. A great deal of security would be achieved by having just a small number of people actually know the GPG and RSA passwords, and have them manually trigger the full commit/push. Then again, that requires human interaction and isn't fully automated.
... and introduces risks we can't predict or mitigate.
I'm thinking of a way where the user's credentials could be used to trigger the signed commit and push without needing the GPG/RSA password for the user transifex, but I'm not sure if it's even remotely possible to like 'share' these keys and authorize different users to use them, without (again) compromising the security principle of these tokens.
Let us remember the caveat of best being the enemy of good enough.
Security risk assessment is never about, "No matter the cost, I will secure this until it is unbreakable." That guarantee comes from a pair of wire cutters used on the CAT(5) between the server and the switch. Great for security, bad for business.
At first glance, compromising an upstream SCM via our servers might be harder than to directly attack the servers:
1. First gain access to the transifex server, which only has an address on the VLAN behind the firewall; 2. Compromise that box sufficiently to take control of either the transifex process or to have a shell as the transifex user; 3. This is made harder if we cook up the SELinux policy for transifex, which protects the overall system in the case of a bug; 4. Begin compromising upstream SCMs -- corruption and deletion are the two real risks here, right?
Kanarip suggests human intervention decreases the risk. To that I have to add two concepts: social engineering, and can we trust those users not to be doing all this from a compromised system?
Upstream SCM actually has the same risks -- they let few to hundreds to thousands of users have SCM access ... all who may have a compromised system ... all of whom are subject to social engineering.
My back-of-the-envelope assessment says this:
* On the average, Fedora Infra boxen are going to be more secure (dedicated staff, for example, compared to the average FLOSS project);
* Our code that accesses upstream SCMs is behind multiple layers of security;
* Our risk to upstream projects is the same or less than they have with every single user they give SCM access to.
Remember, a risk assessment has to balance the rewards.
In this case, the rewards are ENORMOUS:
* Anyone notice how translate.fedoraproject.org and transifex have just solved in six weeks many of the complaints people have about Launchpad and Rosetta?
* Do we think upstream projects are going to want the ability to add an army of translators?
Full disclosure of the security measures in place should be enough for upstream to decide if the rewards are worth the risk.
- Karsten
O/H Karsten Wade έγραψε:
On Sat, 2007-07-14 at 00:55 +0200, Jeroen van Meeuwen wrote:
Mike McGrath wrote:
This is my worry too. It's almost enough to make me not want to do it for non Fedora projects but thats just bad. I'm hoping someone here has a good, clever way to solve this issue.
The benefits of these new tools far outweigh the relatively slight risks. We really must step up and find a way to make it work.
My vote is simple: we do the best we can, we spell out what the security is and the risks involved, and we put that in front of upstream projects. We ask them to agree (via email?) to the risk/reward balance we present. [...]
Security risk assessment is never about, "No matter the cost, I will secure this until it is unbreakable." That guarantee comes from a pair of wire cutters used on the CAT(5) between the server and the switch. Great for security, bad for business. [...]
Remember, a risk assessment has to balance the rewards.
In this case, the rewards are ENORMOUS:
- Anyone notice how translate.fedoraproject.org and transifex have just
solved in six weeks many of the complaints people have about Launchpad and Rosetta?
- Do we think upstream projects are going to want the ability to add an
army of translators?
Full disclosure of the security measures in place should be enough for upstream to decide if the rewards are worth the risk.
Karsten pretty much summarized all my thoughts on the whole idea of transifex. Thanks mate. :)
I plan to start by directly using `~/.ssh/` and one key for all remote repos. If it's not hard to do multiple keys (I think it isn't) via `.config`, then cool. For starters, we can try it out with {cvs, hg, git}.fpo. And i18n.redhat.com if the folks behind it want to be part of this.
This will give us a proof-of-concept implementation and will help us document the procedure and understand what more we can do in the area of security and usability. Then I'd be happily accepting any patches to add more layers of security, like eg.:
* Adding SELinux to protect the keys * Moving `.ssh` out of `~/` * Creating a new program/daemon to handle the VCS transactions
And some more high-level controls that could bump the system's trust:
* Add editors (eg. lang maintainers) who only them could push the changes after reviewing them * Publish local repos to add the choice for a maintainer to pull the translations instead for transifex to push them to the main repo
-d
Dimitris Glezos wrote:
O/H Karsten Wade έγραψε:
On Sat, 2007-07-14 at 00:55 +0200, Jeroen van Meeuwen wrote:
Mike McGrath wrote:
This is my worry too. It's almost enough to make me not want to do it for non Fedora projects but thats just bad. I'm hoping someone here has a good, clever way to solve this issue.
The benefits of these new tools far outweigh the relatively slight risks. We really must step up and find a way to make it work.
My vote is simple: we do the best we can, we spell out what the security is and the risks involved, and we put that in front of upstream projects. We ask them to agree (via email?) to the risk/reward balance we present. [...]
Security risk assessment is never about, "No matter the cost, I will secure this until it is unbreakable." That guarantee comes from a pair of wire cutters used on the CAT(5) between the server and the switch. Great for security, bad for business. [...]
Along these thoughts and Dimitris', having a transifexd running under User A to collect to translations, and another User B to do the actual commits and pushes with, seems to be the best design. SELinux protection of course, is mandatory, although it doesn't prevent a compromised transifexd from putting 'malicious' file in User B's commit/push queue.
Kind regards,
Jeroen van Meeuwen -kanarip
infrastructure@lists.fedoraproject.org
-
Dimitris Glezos -
Jeroen van Meeuwen -
Karsten Wade -
Mike McGrath