couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF IRC Services" <asf...@wilderness.apache.org>
Subject Summary of IRC meeting in #couchdb-meeting, Wed Apr 17 19:10:30 2013
Date Wed, 17 Apr 2013 20:00:46 GMT
Members present: jan____, ryan_ramage, Humbedooh, Wohali, benoitc, drsm79, wendall911, rnewson,
TheJH

----------------
Meeting summary:
----------------

1. Preface

2. TheJH’s Security Proposal

3. action items from last week

IRC log follows:


# 1. Preface #
19:10:37 [Humbedooh]: ACTION coughs at jan____
19:11:48 [rnewson]: ah, I do recall the proposal.
19:12:00 [wendall911]: Having docs be encrypted would be crazy slow
19:12:07 [rnewson]: It seems to assume the replicator is specially privileged in some way.


# 2. TheJH’s Security Proposal #
19:12:52 [rnewson]: I'm not sure what a secure solution looks like if you give couchdb the
private or secret key.
19:13:01 [wendall911]: Not sure how it could be implemented in a way that wouldn't be so slow
as to just not work at some point. This is why this type of thing is typically handled in
the client
19:13:24 [rnewson]: wendall911 erlang can call native crypto libraries, I wouldn't assume
it's too slow to be useful.
19:13:30 [jan____]: Humbedooh: oopsn, thx
19:13:30 [rnewson]: but that's not the hard part.
19:13:37 [rnewson]: as ever, it's key management.
19:14:17 [TheJH]: wendall911, well, that depends on how often documents are replicated, right?
In my usecase, replication only happens when I get an email or set flags on it or so... so
replication speed wouldn't be an issue for my usecase (but maybe that's too specific?)
19:15:01 [ryan_ramage]: I think that if/when the view server gets changed as discussed, it
would be easier for people to build modules, one of which could be encryption
19:15:02 [Wohali]: ...That's a pretty narrow definition of when replication matters, and speed
imo...
19:15:07 [rnewson]: let's ignore the speed issue please.
19:15:24 [rnewson]: and also remember that the replicator is just calling the http api available
to everyone.
19:15:40 [TheJH]: rnewson, what specifically would be hard about key management? It's already
possible to put passwords into the replicator DB without revealing them to other users, right?
Why not keys, too?
19:15:52 [rnewson]: key management is de facto hard.
19:16:22 [rnewson]: how will keys be protected on disk? in memory? how can they be changed?
revoked?
19:16:39 [wendall911]: Would it be better to handle encryped attachments? Wouldn't need to
decrypt for replication then. Only would need to have keys on all masters, but wouldn't prevent
getting a copy.
19:16:45 [rnewson]: do these sound like problems you'd expect a database to solve directly?
19:16:45 [Wohali]: If we do key management, people will start expecting things like PCI compliance,
which is especially hard.
19:17:00 [benoitc]: Wohali: encryption should be a client thing
19:17:07 [Wohali]: yup
19:17:15 [wendall911]: benoitc: I agree
19:17:45 [TheJH]: hmm, so if I want fast access to the unencrypted data on my PC, I should
just write a custom replicator?
19:17:45 [Wohali]: i could see key-based auth overall being beneficial, but not with the private
keys in the db.
19:17:54 [rnewson]: attachment data can be completely opaque without breaking anything in
couchdb, that's true.
19:18:30 [rnewson]: TheJH: decrypt it when you need to see it?
19:18:52 [rnewson]: rather than have the replicator acts a plaintext/ciphertext converter
too.
19:19:00 [TheJH]: rnewson, that would make it impossible to make views on the documents
19:19:03 [rnewson]: yes.
19:20:10 [benoitc]: why do you need a pki btw ? It looks to me that a simple token is enough,
token can be fetched during the authentication step
19:20:12 [benoitc]: in couch or anywhere
19:20:40 [benoitc]: couch only need an api to match keys to roles or access possibilities
in that case
19:20:55 [benoitc]: that can be in couch or anywhere
19:21:10 [benoitc]: (coudl also work for ssl keys too)
19:23:02 [wendall911]: TheJH: so what is the goal of having encryption for your use-case?
19:23:40 [TheJH]: wendall911, if someone breaks into my server, he does not get access to
all my past e-mail traffic (although he can intercept new mails in the future)
19:24:17 [jan____]: would an encrypted file system help?
19:24:17 [Wohali]: Have you considered using truecrypt for the volume that holds your CouchDB
/var directory?
19:24:18 [Wohali]: :)
19:24:19 [wendall911]: because, in my mind if you're trying to protect the server, in a compromise,
the keys would also be part of the server data, so data is compromised
19:24:25 [Wohali]: great minds
19:24:42 [wendall911]: however, if you store the data encrypted and support decryption in
the client, you're protected
19:24:55 [wendall911]: couchdb is just a storage mechanism at that point
19:25:03 [wendall911]: imo, that's the only secure way to do it
19:25:11 [TheJH]: my goal is to protect data from people with root access to the vserver.
my private key wouldn't be on that vserver, just in the couchdb I have at home
19:25:40 [TheJH]: there are two couchdb instances and I have different levels of trust in
the systems they're running on
19:26:28 [TheJH]: truecrypt or encfs on the vserver's couchdb won't help because it would
always be running
19:27:00 [TheJH]: however, if only the encryption key (not the decryption key) is on the server,
the data is secure
19:27:46 [Wohali]: ( today's XKCD is appropriate. :) )
19:28:35 [jan____]: :D
19:29:08 [TheJH]: yes, if someone owns my PC, it's over  but if someone owns my vserver,
it's not, and I'd like to further reduce the possible damage :P
19:30:00 [wendall911]: It's an excellent use-case. It might be a can of worms, but it's interesting
to see if it could be supported in some way without pushing into PCI compliance territory
19:30:58 [jan____]: my gut says that this wants to be done outside of CouchDB
19:31:05 [Wohali]: I arrived late but the challenge of course is how secure the erlang VM
is, too. Easy to get a remsh into that and then game over. And if Erlang doesn't know what
the data means, it can't readily do anything useful with it.
19:31:42 [Wohali]: I think I came in just as the view server protocol was being discussed,
so I'll skip that piece of the puzzle.
19:32:21 [rnewson]: Wohali: not that easy if it's not enabled..
19:33:12 [Wohali]: I guess if you go down the SELinux route you could even block off access
to /dev/mem. I'm just saying that it's a lot of things to worry about, and if we start down
the road, we need to go all the way. Which means someone picking up this feature and shepherding
it thru that process.
19:35:12 [wendall911]: Wohali: yes, and this could be a full-time job for someone for quite
some time. I'm not sure it's a tenable situation at the moment without someone sponsored to
do this work.
19:35:21 [TheJH]: Wohali, but that's not relevant to my proposal, right? You are talking about
preventing exploitation of couchdb, I'm talking about reducing the impact of exploitation
of the whole system
19:35:52 [Wohali]: Key word there is "reduce." Don't get me wrong, I love the idea, but I
am immediately thinking of all the ways I could get around your proposed approach.
19:36:20 [wendall911]: TheJH: the point here is it's nearly impossible to secure an app in
an insecure system.
19:36:50 [TheJH]: wendall911, but it's totally possible to secure its data. With GPG, your
mail is secure even if someone breaks into your mail account.
19:36:59 [wendall911]: yep
19:37:15 [wendall911]: hence, attach it as data and couchdb works as-is
19:37:27 [wendall911]: attach it to a doc with some metadata for your views
19:37:35 [TheJH]: Wohali, if the private key isn't on the vserver and you only have access
to the vserver, I think there can be no way to get around it
19:37:43 [wendall911]: the metadata can be stuff you're OK with anyone getting
19:38:05 [rnewson]: do we time-box topics in these meetings?
19:38:15 [TheJH]: wendall911, hmm... yes, that might work for me.
19:38:21 [wendall911]: I'm all done commenting, sorry :)
19:38:28 [TheJH]: rnewson, sounds like a good idea :D
19:38:36 [ryan_ramage]: I agree, in light of time, this discussion can move to the mailing
list
19:38:58 [TheJH]: ok
19:39:00 [jan____]: I’d +1 that
19:39:13 [wendall911]: TheJH: thank you for bringing this to our attention. Also appreciate
the email to the list. Sorry there wasn't a better response there.
19:39:30 [jan____]: :) yeah
19:40:36 [TheJH]: well, thanks for the feedback so far :)
19:40:58 [jan____]: cool


# 3. action items from last week #
19:41:13 [jan____]: ryan_ramage: all yours
19:41:29 [ryan_ramage]: ok, this is just time for reminders about action items
19:41:36 [ryan_ramage]: kind of a whip :)
19:41:58 [ryan_ramage]: if you want to get to the meat of these, most discussion is for the
ML
19:42:13 [ryan_ramage]: just ack if you have done the action:
19:42:43 [ryan_ramage]: benoitc to send proposal to mailing list about the once a month meeting
idea
19:43:38 [benoitc]: i didn't because was stopped by sonme comments I have to comments
19:43:43 [benoitc]: next
19:43:53 [ryan_ramage]: ok. wendall911 to start discussion on dev and add a page in the wiki
to start gathering ideas for a formal proposal
19:44:21 [ryan_ramage]: ( javascript test update. View engine update/replacement. Removal
of _restart)
19:45:06 [wendall911]: ok, I'm dragging my feet here, as I'm buried on a work project. I will
have time in the next week to work on this.
19:45:28 [wendall911]: will discuss next week for certain
19:45:37 [ryan_ramage]: ok, this is just so everyone knows where its at. 
19:45:43 [wendall911]: np
19:45:53 [ryan_ramage]: dch to update COUCHDB-1696 and prod the list on it
19:46:22 [jan____]: dch is out
19:46:36 [ryan_ramage]: have we felt prod'ed?
19:46:51 [ryan_ramage]: I think I saw some emails about this
19:47:28 [jan____]: ok
19:48:06 [ryan_ramage]: And I had an action to check on fauxton builds. and I now have to
bug drsm79 for some code to check in to get it back working
19:48:28 [drsm79]: yes! I have the code
19:48:28 [drsm79]: need to commit it
19:48:36 [jan____]: cool
19:48:38 [ryan_ramage]: ok cool :) 
19:48:43 [drsm79]: my bad - last weeks cloudant conf got in the way
19:48:51 [ryan_ramage]: ok, my section done
19:49:06 [ryan_ramage]: I can be a followup whip in the future, if this is useful
19:49:13 [jan____]: # Any other business
19:49:21 [jan____]: ryan_ramage: please :)
19:50:13 [Wohali]: 15:48 < drsm79> my bad - last weeks cloudant conf got in the way
19:50:21 [Wohali]: goes double for me
19:51:01 [jan____]: not to worry!
19:51:05 [ryan_ramage]: Wohali, drsm79 no doubt the conference will be beneficial to us all
in the long run! :)
19:51:12 [jan____]: I was out most of the time as well
19:51:12 [Wohali]: indeedly doodly
19:51:20 [Wohali]: i guess i have something to insert here
19:51:50 [Wohali]: actually no, i'll hold it
19:51:57 [Wohali]: because i don't want to mention it until i really have time to focus on
it
19:51:57 [jan____]: heh
19:51:59 [Wohali]: and i have a conference speech to give
19:52:06 [Wohali]: next week.
19:52:12 [jan____]: ok
19:52:21 [Wohali]: topic is automated hot upgrades compatible with package systems. watch
this space.
19:52:50 [wendall911]: ACTION drools
19:52:57 [wendall911]: Wohali: awesome
19:52:59 [Wohali]: :)
19:58:50 [ryan_ramage]: ACTION prods jan____ to release our loose group of awesome back to
our separate ways :)
19:59:20 [benoitc]: ACTION try to decrypt that sentence
19:59:35 [benoitc]: tries
19:59:44 [ryan_ramage]: benoitc: you need my keys, that couch can't store. sorry


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message