2010/1/6 KaiGai Kohei <kai...@ak.jp.nec.com>: > (2010/01/07 11:39), Aaron Stone wrote: >>>> 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. > > It is my preference rather than the second idea, because it requires > application to handle the security tag explicitly for each accesses, > but most of access control feature generally performs below the surface. > For example, we don't provide filesystem permissions any additional > credentials for each read(2) or write(2) system call. > > If we don't assume a certain security model, in other word, if memcached > provides a pluggable access control mechanism, it always does not need > SASL authentication. For example, SELinux's security label of the peer > process is a candidate. > > If we can identify the client (web application instance) in some way, > memcached will be able to store the something identifier of the cached > object. It may be called owner of the cached object (depending on the > security model). > Then, access control mechanism can provide its access control decision > based on the client's identifier and object's identifier.
With a filesystem, the kernel knows which process is making the call and what user and group ids the process is running as, so it can perform access checks with that sideband information. Is there a mechanism for this with network sockets in SELinux? > It basically does not need protocol changes. However, we may want > a new command to set/get security properties (or not only security > properties) of the cached objects in the future. > > Thanks, > >> 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<kai...@ak.jp.nec.com> >>>>> >>>> >>> >>> >>> -- >>> OSS Platform Development Division, NEC >>> KaiGai Kohei<kai...@ak.jp.nec.com> >>> >> > > > -- > OSS Platform Development Division, NEC > KaiGai Kohei <kai...@ak.jp.nec.com> >
