Tails

#2 Updated by bertagaz about 9 years ago

So, I’ve talked a bot with weasel about that too. At Torproject, they’re using the plain Jenkins authentication abilities and the matrix based ACL to secure access to their instance access.

Maybe if we choose to use the upstream LTS Debian package as they do, which has better security support than the one from Debian (well, because it’s upgraded more often at least), we could consider doing the same and rely on Jenkins rather than researching something than no one else seems to do.

#3 Updated by intrigeri about 9 years ago

> At Torproject, they’re using the plain Jenkins authentication abilities and the matrix based ACL to secure access to their instance access.

https://wiki.jenkins-ci.org/display/JENKINS/Matrix-based+security or https://wiki.jenkins-ci.org/display/JENKINS/Matrix%20Authorization%20Strategy%20Plugin ?

> Maybe if we choose to use the upstream LTS Debian package as they do, which has better security support than the one from Debian (well, because it’s upgraded more often at least), we could consider doing the same and rely on Jenkins rather than researching something than no one else seems to do.

I’ve quickly looked at this again and I agree.

#9 Updated by intrigeri about 5 years ago

Note that the test job runs logs contain passwords that we probably don’t want to expose publicly.

#10 Updated by anonym about 5 years ago

intrigeri wrote:
> Note that the test job runs logs contain passwords that we probably don’t want to expose publicly.

Indeed. I see a couple of ways to solve this:

1. For simplicity, let’s assume that the password leaks all occur when @screen.type() them. Then I could add an option to suppress the logging, e.g. @screen.type("trustno1", log: false), and then we’ll just have to be careful and do that for each occurrence when we type (secret) passwords. And since the assumption probably doesn’t hold we’d have to look for other ways the passwords leaks and add support for log: false to them too (e.g. probably Dogtail, which any way could use some work to reduce its excessive logging).
2. On Jenkins, we could post-process the logs by reading all the .json files in features/config, extract all their password fields, and for each $PASSWORD just s/$PASSWORD/XXX_CENSORED_XXX/g on the debug.log.

Of course, passwords could still leak, e.g. if there is a GUI focus issue the password could end up being typed into the wrong place, like a normal text area that is visible in a failure screenshot/video. I think that’s something we could live with, at worst an attacker can make Jenkins’ tests fail. If that turns into a recurring headache we can always just revert.

#11 Updated by anonym about 5 years ago

Actually, at least in the email tests it’s not enough to hide the password: by learning the email address an attacker can fill the inbox resulting in test failure. So we could @screen.type(email_address, log: false) to fix the logs, but the email address would still appear in any failure screenshot/video where it was typed since its not a password field that hides the characters.

I think I still would like to try this and not get too discouraged by these theoretical attacks. Thoughts?

#12 Updated by intrigeri about 5 years ago

> Actually, at least in the email tests it’s not enough to hide the password: by learning the email address an attacker can fill the inbox resulting in test failure. So we could @screen.type(email_address, log: false) to fix the logs, but the email address would still appear in any failure screenshot/video where it was typed since its not a password field that hides the characters.
>
> I think I still would like to try this and not get too discouraged by these theoretical attacks. Thoughts?

I agree the disclosure of the test email address is not, in itself, a blocker.

Making it possible to not log passwords seems worthwhile to me regardless of whether we end up publishing our Jenkins read-only (that’s very unclear to me at the moment: we don’t know if we’ll still be using Jenkins in 2-3 years, and there are probably a bunch of other, bigger blockers than password logging):

• Our track record wrt. not publishing logs is not good. There might be other places where these passwords are leaked.
• It would also be useful (or possibly, needed) if we migrate to another CI system.
• More generally, it just makes sense to me that CI artifacts should be things we can publish and share. I think that most of the password leaks problems we had so far happened because someone (sometimes myself) was implicitly acting based on this assumption. Let’s make this assumption correct :)

So I’m definitely in favor of capturing this idea in a dedicated ticket (blocking this one), where we can discuss/prioritize this further. I doubt it’s close to the top of the list of the most useful/important test suite work we have on our plate though.