couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad George <c...@mgproducts.com>
Subject Re: Per Document Filtering/Authorization
Date Tue, 30 Nov 2010 15:14:56 GMT
I understand what your saying about the data being ignorant of protection. I
was mostly thinking that was the easiest way to avoid per-document security
from slowing down access to non-secure documents, but maybe that's not a
common enough use case to be worth the problems you mentioned.

Seems like url protection and read_doc_validate() serve different purposes
related to securing a publicly accessible database. Any reason not to
implement both?

Url protection would work for securing views, design documents, raw document
access...all very needed.
read_doc_validate() would add the ability to selectively secure individual
documents based on both the document state and the request context ... which
I think is very important too.

I also wanted the ability to return modified (sanitized) versions of
documents to certain users in a fairly transparent way that also can take
advantage of the rest of the document and view APIs (like direct access,
multi-doc and view + include_docs)

I realize this could be implemented with URL protect + lists/show functions,
but it could be implemented easier if read_doc_validate() was allowed to
throw exception to block access or return a modified document that is the
result of the read request.

Another issue with respect to security ... do we need a default replication
filter that can't be bypassed if its defined on that database?


On Tue, Nov 30, 2010 at 7:50 AM, Bram Neijt <bneijt@gmail.com> wrote:

> You can not change the document during the validate_doc_update, but
> you can change it if you create an _update handler[1]. You would then
> firewall all direct access to the database and allow only global
> access to the different views you define. Replication probably needs
> access to the documents directly, so they should go behind the
> firewall.
>
> I don't really like the idea of having a flag on the document which
> has just to do with security, I think the data should be ignorant when
> it comes to it's protection, as it's protection is context dependent.
>
> I think the biggest obstacle now is to keep people from reading
> information when CouchDB is bound to a public interface.
>
> I would like to see the following question answered: do we want to add
> a function that will set read access for the different databases (a
> read_doc_validate) or do we want a module like rewrite where we get to
> protect urls like we would when using a firewall (restrict
> PUT/GET/DELETE and regex on url paths)?
>
>
> Bram
>
>
>
> [1] http://wiki.apache.org/couchdb/Document_Update_Handlers
>
> On Mon, Nov 29, 2010 at 7:29 PM, Chad George <chad@mgproducts.com> wrote:
> > I was thinking the _access field would hold either a validation function
> or
> > (more often) a path to a function on a design document. And for that
> matter,
> > I'm not sure what (if anything) we gain by having the function definition
> > itself on the document, just a field to point to the correct place in the
> > design document should be sufficient. This way entire classes of
> documents
> > could share the same validation function.
> >
> > I don't think you can modify the document during validate_doc_update, but
> it
> > seems pretty easy to require the _access field to be a certain value to
> > accept creating the document by the user. This would be analogous to the
> > type/class of the document and could be well known without any decrease
> in
> > security.
> >
> > I was thinking that putting the "flag" that turns on document security at
> > the document level would eliminate the need to run the validation
> function
> > for documents that don't require security, so performance should only
> really
> > decrease for secured systems (except for a hopefully cheap check to see
> if
> > the flag exists at all).
> >
> > Another reason to put this on the document is that it simplifies the
> > validation function for lots of different document types in the same
> > database.
> >
> > I think the view access validation function in design document is a very
> > good addition to the security model as well ... possibly this could be a
> > optional method defined as part of the view definition itself.
> >
> >
> >
> > On Mon, Nov 29, 2010 at 11:14 AM, Bram Neijt <bneijt@gmail.com> wrote:
> >
> >> Yes, we could add something like _access to control access to the
> >> document, however that would mean that the validate_doc_update
> >> function will have to add this to the documents (you can't wait for
> >> the user to add the validation function).
> >>
> >> That makes it seem simpler to add an access function at the database
> >> level, where you would still be able to do something like
> >> "if(document.type == 'should_secure') { //heavy security for the
> >> document }" with the added bonus of not having to replicate your
> >> security code in all your documents.
> >>
> >> Maybe we would be better of with a system that allows us to match
> >> requests with user information, because we need something to protect
> >> the view from unauthorized access as well? If somebody thinks that
> >> would be a good idea, feel free to add a comment.
> >>
> >> Please comment on the "per document access function" vs "per database
> >> access function".
> >>
> >> Greets,
> >>
> >> Bram
> >>
> >> On Mon, Nov 29, 2010 at 3:20 PM, Fedor Indutny <fedor.indutny@gmail.com
> >
> >> wrote:
> >> > Yep, that's what I was talking about!
> >> >
> >> > 2010/11/29 Chad George <chad@mgproducts.com>
> >> >
> >> >> Bram Neijt has recently indicated interest in working on per document
> >> >> authorization. I've mentioned an idea a few times here and on the
> user
> >> list
> >> >> but never got any real response so I'm still not sure what the
> general
> >> >> consensus about the idea is.
> >> >>
> >> >> My idea is to add a new special field on the document that indicates
> a
> >> >> function that can modify the document before returning it to the
> user.
> >> >> function(doc, req) {
> >> >>  /* modify doc based on req or just throw exception */
> >> >>  return doc;
> >> >> }
> >> >>
> >> >> I think the main place that document authorization is needed is
> limiting
> >> >> (or
> >> >> sanitizing) access to raw documents. Especially in a mixed authorized
> >> >> and anonymous access environment.
> >> >>
> >> >> Shows/Lists/Updates are already pretty easy to enforce a security
> >> barrier
> >> >> within a single database, but direct access to documents makes
> certain
> >> >> applications difficult (or impossible) to secure without a middle
> server
> >> >> layer.
> >> >>
> >> >> With a filter function attached to the document, we would have
> minimal
> >> >> overhead for when doc auth wasn't required so only secured documents
> >> would
> >> >> get any real performance penalty. By allowing the filter function to
> >> return
> >> >> a modified document --or-- throw an exception we could get access
> denial
> >> >> and
> >> >> minor sanitizing with the same mechanism.
> >> >>
> >> >> This would work nicely with include-docs for views that need
> security.
> >> And
> >> >> it doesn't seem that hard to keep secure info out of being embedded
> in
> >> >> views
> >> >> and view reductions in the first place. I recently saw a suggestion
> on
> >> the
> >> >> mailing list to have an access control function for views on the
> design
> >> >> document, that seems like a nice fix for securing access to views
> >> >> themselves.
> >> >>
> >> >> - Chad
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Cheers,
> >> > Fedor Indutny.
> >> >
> >> > Skype: fedor.indutny
> >> > Gtalk: fedor.indutny@gmail.com
> >> > Github: http://github.com/donnerjack13589
> >> >
> >>
> >
>

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