2010/1/6 KaiGai Kohei <[email protected]>: > (2010/01/07 11:07), Aaron Stone wrote: >> 2010/1/6 KaiGai Kohei<[email protected]>: >>> (2010/01/07 9:14), Matt Ingenthron wrote: >>>> Aaron Stone wrote: >>>>> On Wed, Jan 6, 2010 at 2:48 AM, pub crawler<[email protected]> >>>>> wrote: >>>> (snip...) >>>>>> Needless to say, permissions and authentication is a feature set that >>>>>> is going to re-requested for addition now and in the future. It opens >>>>>> the door for someone to create a memcached variation with such a >>>>>> feature set - anyone? >>>>> >>>>> Please don't. Please nobody even think of doing that. Really. Don't. >>>>> >>>> >>>> Authentication, at least, has been in the community memcached release >>>> for the last two micro releases: >>>> http://code.google.com/p/memcached/wiki/ReleaseNotes143 >>>> >>>> If you need security labels and such, running separate processes would >>>> seem to be the way to go. >>> >>> Yes, it is an approach to enforce strict separation between users. >> >> If "users" means users of your site, then are you going to apply >> per-user access controls to the rows in your database, too? > > Yes, see the page.14 of the slides: > http://sepgsql.googlecode.com/files/JLS2009-KaiGai-LAPP_SELinux.pdf
Neat, you're really serious! Ok, so two ways I can see going about this: Use SASL authentication to validate each "web user" and then tag each key in memcached with a hash that can be verified to be owned by the user. Get and Set would check this tag before allowing a key to be written -- or build compound keys where the hash is the first part, so that separate user data exists each in its own namespace. In this case, you don't need protocol changes, only server changes to do more with the SASL information. Or, similar but without the SASL part, tagging each key with some secret value. If you have protected the database rows, then "SELECT * FROM secret_memcached_keys" will only return the keys the user is allowed to see. They would use those keys in a way similar to the CAS values; operations are only allowed to proceed if the secret tags match. In this case, you need a protocol change to carry the extra values. Anyhow, I'm not even close to a core contributer around here, so those are just some thoughts. > Web users are authorized by apache/httpd and we can restrict privileges > of web applications prior to its launch. We can restrict accesses to the > filesystem, database and probably cached data based on the restricted > privileges. > >> If "users" means admins running their own web apps, then run separate >> instances. There are many other ways for multiple users of the same >> memcached instance to cause each other trouble. Separate instances >> with SASL auth to keep each to their own instance is the way to go at >> this time. > > It is not my intention. Sorry for this confusion. > > Thanks, > >>> However, there are a few assumptions: >>> - We don't need to consider any cases except for the strict-separation. >>> - We need to assume web applications are bug/vulnerability free. >>> >>> In some cases, it is not suitable for the purpose. :( >>> >>> The development roadmap mentions about a modular approach in storage >>> engine support. It seems to me similar approach may be possible in >>> various kind of access control models. >>> >>>> Of course, security labels can also be applied >>>> to network traffic, meaning that the authentication features are >>>> redundant. :) >>> >>> Yes, SELinux provides an API to obtain privilege of the peer process >>> for the given socket file descriptor (IIRC, Solaris also has similar >>> API). We can use it instead of the authenticated username. >>> >>> Thanks, >>> -- >>> OSS Platform Development Division, NEC >>> KaiGai Kohei<[email protected]> >>> >> > > > -- > OSS Platform Development Division, NEC > KaiGai Kohei <[email protected]> >
