(2010/01/08 15:25), KaiGai Kohei wrote:
> (2010/01/07 19:19), Toru Maesaka wrote:
>> Ahh, now I'm with you.
>>
>>> I don't deny it is niche. However, it is absolutely necessary feature
>>> for people who want to set up secure web application platform.
>>
>>> It seems to me there is no difference from what I said, except for name
>>> of the framework.
>>
>> Indeed. Apologies for not realizing this earlier... Good luck on
>> hacking your Access Control engine module :)
>>
>> - Toru
>>
>> P.S. It might save your time if you look at this first:
>> http://github.com/trondn/memcached/blob/engine/doc/engine-interface.xml
Sorry for this break of discussion.
I checked the engine implementation, and found out several matters to
implement access control feature on the framework.
So, it is still unavailable an example module based on the framework.
* Again, the engine framework is not designed to host multiple modules
in usual way. If a security module occupies the engine framework, it
also has to load another module that provide physical storage engine,
by itself. (Or, security module also has to provide i/o feature? it
is quite nonsense.)
* The engine framework does not provide a hook just after a connection
from client is established. It is not a must-requirement. However,
we want to obtain privilege of the client process, and cache it in
the userspace.
If it is not available, we have to invoke a system-call for each
access control decision, but it will be expensive.
* The security module needs its private storage different from the storage
engine module.
Now, the conn structure has "void *engine_storage" to store an engine
private information, but the right to use is closed for the second
module.
In addition, the hash_item structure does not provide any private
storage to store security context of the item (e.g this context will
record what process create this object).
* The deployment of some hooks makes hard to decide what permission
should be applied. For example, process_bin_delete() calls "get"
method to confirm the object to be removed is existing.
But the "get" method is only chance for the engine module to know
a certain item is accessed in reader context.
Of course, if we consider "delete" is a combination of "read" and
"delete", it will be resolved. But it will damage the flexibility
of security design.
Please note that I don't intend to disparage the engine framework.
It seems to me it well organizes the physical structures in memcached.
However, it is not designed to host a security module, so here are
several difficulties.
So, I would like to go back to the earlier idea which tries to implement
a pluggable framework for access control feature.
In the default, it does not apply anything, like air.
However, if administrator want to apply security checks in memcached also,
it will allow to apply its access controls in this level.
Thanks,
> I began to trace the engine implementation.
> In overview level, it seems to me the engine interface well organize the
> physical structures in memcached, like filesystem interface in the operating
> system.
> However, I could find several places unsuitable for infrastructure of
> the access controls, because it needs to handle logical schema.
>
> For example, process_bin_delete() calls the get() method at first to
> confirm existence of the item for the given key. Then, if exist,
> it calls remove() method to delete the specified item.
>
> <quote>
> static void process_bin_delete(conn *c) {
> :
> if (settings.engine.v1->get(settings.engine.v0, c,&it, key, nkey) ==
> ENGINE_SUCCESS) {
> uint64_t cas = ntohll(req->message.header.request.cas);
> if (cas == 0 || cas == settings.engine.v1->item_get_cas(it)) {
> MEMCACHED_COMMAND_DELETE(c->sfd,
> settings.engine.v1->item_get_key(it), it->nkey);
> settings.engine.v1->remove(settings.engine.v0, c, it);
> write_bin_response(c, NULL, 0, 0, 0);
> } else {
> write_bin_error(c, PROTOCOL_BINARY_RESPONSE_KEY_EEXISTS, 0);
> }
> /* release our reference */
> settings.engine.v1->release(settings.engine.v0, c, it);
> } else {
> write_bin_error(c, PROTOCOL_BINARY_RESPONSE_KEY_ENOENT, 0);
> }
> }
> </quote>
>
>> From the perspective of physical structure, it is completely right.
>
> However, the get() method is the only chance for the engine module to control
> read access on the specified item, and we have no way to inform the engine
> module whether this invocation is due to the preprocess of the delete
> operation,
> or the get operation.
> In other word, the engine module cannot distinguish "get" command and a part
> of "delete" command.
>
> Thanks,
>
>> 2010/1/7 KaiGai Kohei<[email protected]>:
>>> (2010/01/07 17:55), Toru Maesaka wrote:
>>>>> Please use the correct term to avoid confusion :(
>>>>> Authentication is a different concept from access control.
>>>>
>>>> Point taken :)
>>>>
>>>>> Obviously, it is valueable.
>>>>>
>>>>> My proposition is just a framework to host an additional access control
>>>>> feature without any assumption for security models. In other word, the
>>>>> default installation does not apply any access controls, unless
>>>>> administrator explicitly set up its own security module.
>>>>>
>>>>> Please note that any security solution has its own assumption, so the
>>>>> preferable answer depending on the situation.
>>>>> In our assumption, it is difficult to keep application bug/vulnerability
>>>>> free, so we need to minimize the number of points to be checked.
>>>>> It is also why operating system checks filesystem permission on the system
>>>>> call invocations, not application side.
>>>>
>>>> Like I said, I understand your argument. The question is what
>>>> proportion of the users would benefit from this? To be honest I don't
>>>> have the answer for this. However, taking into account that memcached
>>>> has been used worldwide
>>>> without serious complaints by players of all sizes in it's history, I
>>>> don't think it's necessary. Damn, I was even skeptical of the SASL
>>>> support at the beginning (I agree with this now though). I just don't
>>>> want to see memcached get bloated by adding database-like
>>>> functionalities.
>>>
>>> I don't deny it is niche. However, it is absolutely necessary feature
>>> for people who want to set up secure web application platform.
>>>
>>> So, I suggested this idea with modular approach, not built-in.
>>>
>>>> However, I have nothing against people providing this functionality
>>>> inside their engines. In fact, I think it would be fantastic! This was
>>>> my original view of the Engine Project (additional things should be
>>>> provided by the engine) which was fortunately embraced by the
>>>> community. The binary protocol turned out to be useful for this too.
>>>
>>> It seems to me there is no difference from what I said, except for name
>>> of the framework.
>>>
>>> Right now, I'm not clear whether the engine is a reasonable framework
>>> to host access control feature, or not. So, I represented it just a
>>> security framework.
>>>
>>> Anyway, system administrators can decide whether the memcached should
>>> load the access control module on the "engine" framework, or not.
>>> Of course, he can pay mention about its tradeoff.
>>>
>>>>> BTW, Is the storage engine stackable? If not so, it seems to me we will
>>>>> face a tradeoff between persistent storage and access controls.
>>>>
>>>> No. It's not stackable. If you want to do this you'd have to create an
>>>> abstraction layer within the storage engine. There were discussions on
>>>> this a while back though (I forget if it was online or offline).
>>>
>>> It seems to me it is a bit ad-hoc workaround.
>>> For example, when the primary module allocate an item object, what should
>>> the secondary module perform?
>>>
>>> However, it is not a bad idea to start it from the upcoming engine
>>> framework.
>>>
>>> Thanks,
>>>
>>>> Cheers,
>>>> Toru
>>>>
>>>>
>>>> 2010/1/7 KaiGai Kohei<[email protected]>:
>>>>> (2010/01/07 16:17), Toru Maesaka wrote:
>>>>>> Yo all,
>>>>>>
>>>>>> Looks like I've jumped on this band wagon a little late but allow me
>>>>>> to throw in my thoughts. Firstly, I'm totally against item-level
>>>>>> authentication.
>>>>>
>>>>> Please use the correct term to avoid confusion :(
>>>>> Authentication is a different concept from access control.
>>>>>
>>>>>> I see KaiGai Kohei's motivation to want this but in the context of
>>>>>> memcached, this is the applications job. I think it could upset mid to
>>>>>> large scale memcached users if we added this. They're using it because
>>>>>> they love the simplicity and the high throughput of memcached. They
>>>>>> can take care of security themselves. I guess things are different in
>>>>>> a hosting environment but there are different solutions for this which
>>>>>> Dustin has been looking into.
>>>>>>
>>>>>> So the question is, is it worth the effort for the memcached project?
>>>>>
>>>>> Obviously, it is valueable.
>>>>>
>>>>> My proposition is just a framework to host an additional access control
>>>>> feature without any assumption for security models. In other word, the
>>>>> default installation does not apply any access controls, unless
>>>>> administrator explicitly set up its own security module.
>>>>>
>>>>> Please note that any security solution has its own assumption, so the
>>>>> preferable answer depending on the situation.
>>>>> In our assumption, it is difficult to keep application bug/vulnerability
>>>>> free, so we need to minimize the number of points to be checked.
>>>>> It is also why operating system checks filesystem permission on the system
>>>>> call invocations, not application side.
>>>>>
>>>>> If we can trust applications, it is not a wrong approach to control
>>>>> all the things in the application, not memcached.
>>>>>
>>>>>>> One question. Is the storage engine an appropriate layer for access
>>>>>>> controls on item level?
>>>>>>
>>>>>> Yes. This wouldn't be too difficult to pull off with Binary Protocol
>>>>>> + Engine API. You could create a scramle buffer and send that with the
>>>>>> most appropriate binary protocol field (worst case, use the reserve
>>>>>> field). This scramble buffer can be appended into the key of the item
>>>>>> inside your engine. So you could pull this off with keys with the
>>>>>> following structure:
>>>>>>
>>>>>> <key_value><scramble_buffer> (or vice versa).
>>>>>>
>>>>>> Pretty much you're free to do anything in the engine. Memcached is
>>>>>> only a darn efficient network interface and protocol parser in the
>>>>>> context of Engine API.
>>>>>
>>>>>> After sending the previous email, I realized that the engine solution
>>>>>> I mentioned is not that good. It limits access to a certain item to
>>>>>> one user. A better approach would be to create a security map that
>>>>>> associates scrambled data with items.
>>>>>
>>>>> Are you suggesting that applications has to handle the scramble buffer
>>>>> correctly for each accesses? It seems to me we can obtain credential of
>>>>> the client using SASL authentication, without any additional hints.
>>>>>
>>>>> If the security map means something like access control list, what we
>>>>> are talking about is not fundamentally different.
>>>>> The issue is the way to store the properties within the item.
>>>>>
>>>>> BTW, Is the storage engine stackable? If not so, it seems to me we will
>>>>> face a tradeoff between persistent storage and access controls.
>>>>>
>>>>> Am I missing something?
>>>>>
>>>>> Thanks,
>>>>>
>>>>>> Cheers,
>>>>>> Toru
>>>>>>
>>>>>> 2010/1/7 KaiGai Kohei<[email protected]>:
>>>>>>> (2010/01/07 13:02), Matt Ingenthron wrote:
>>>>>>>> dormando wrote:
>>>>>>>>>> Getting down to the item level would be tough to accept due to the
>>>>>>>>>> overhead
>>>>>>>>>> involved, one would think though. There may be some ways of getting
>>>>>>>>>> closer to
>>>>>>>>>> access control though without going down to the item level.
>>>>>>>>>
>>>>>>>>> This seems like it'll be solved by an engine dealio. Mapping a user
>>>>>>>>> to an
>>>>>>>>> internal instance of the storage system. Sort of like running multiple
>>>>>>>>> instances, *cough*. Getting super granular access levels for a web
>>>>>>>>> cache
>>>>>>>>> (more than a few dozen users) would be insane, but if someone really
>>>>>>>>> wants
>>>>>>>>> to they could implement a storage engine for it.
>>>>>>>>
>>>>>>>> My thoughts exactly. That's what engine is for!
>>>>>>>
>>>>>>> Does the engine mean something pluggable or modular?
>>>>>>> If so, it is similar to what I think.
>>>>>>>
>>>>>>> One question. Is the storage engine an appropriate layer for access
>>>>>>> controls on item level?
>>>>>>>
>>>>>>> It might be possible to provide strict separation between users.
>>>>>>> Is it possible to provide read-only or append-only rules for a certain
>>>>>>> users in the item level granularity?
>>>>>>>
>>>>>>>>> It'd be incredibly inefficient on memory, compared to keeping the
>>>>>>>>> number
>>>>>>>>> of users down or even running multiple instances.
>>>>>>>>
>>>>>>>> Only if you were trying to go all the way down to the item level. It's
>>>>>>>> possible to have groups of slabs that are dedicated to one label/auth
>>>>>>>> or
>>>>>>>> something like that, right?
>>>>>>>
>>>>>>> It may be possible. However, if the usage of slabs are not balanced,
>>>>>>> it may remove cached object, although we have unallocated cache in
>>>>>>> the slab owned by other label/auth. right?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> --
>>>>>>> OSS Platform Development Division, NEC
>>>>>>> KaiGai Kohei<[email protected]>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> OSS Platform Development Division, NEC
>>>>> KaiGai Kohei<[email protected]>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> OSS Platform Development Division, NEC
>>> KaiGai Kohei<[email protected]>
>>>
>>
>>
>>
>
>
--
OSS Platform Development Division, NEC
KaiGai Kohei <[email protected]>
