Can an SSH tunnel not be used to add an authentication layer? Can't any
TCP/IP-based application protocol be encapsulated in an SSH tunnel?
Brandon Ramirez | Office: 585.214.5013 | Fax: 585.295.4848
Software Engineer II | Element K | www.elementk.com
From: KaiGai Kohei <kai...@ak.jp.nec.com>
To: memcached@googlegroups.com
Cc: Toru Maesaka <d...@torum.net>, Matt Ingenthron <ingen...@cep.net>
Date: 01/07/2010 03:26 AM
Subject: Re: memcached and access control
Sent by: memcached@googlegroups.com
(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<kai...@ak.jp.nec.com>:
>> (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<kai...@ak.jp.nec.com>
>>
>
>
>
--
OSS Platform Development Division, NEC
KaiGai Kohei <kai...@ak.jp.nec.com>
