We're still working on merging down 1.6... but if this exists outside as an engine nothing of us blocks you from using it for now.
I sort of wonder a little about outright pulling it into the tree, since that implies we have to maintain it. On Fri, 27 Aug 2010, KaiGai Kohei wrote: > BTW, how about getting inclusion of this patch? > > (2010/08/16 14:38), KaiGai Kohei wrote: > > The attached patch is a revised version of memcached permissions. > > > > The 'calculate' permission has gone, and INCR/DECR requires us > > both of 'read' and 'write' permissions. > > It means we should switch domain of the client process when we > > need special treatments to unaccessable items; something like > > trusted procedures. > > > > Rest of the patch is not changed. > > > > (2010/08/05 9:20), KaiGai Kohei wrote: > >> (2010/08/04 10:25), Kelvin Edmison wrote: > >>> I'm still not sure how allowing a 'calculate' permission would be helpful > >>> in > >>> this case. Incr and decr allow for incrementing and decrementing by any > >>> amount. There does not seem to be any real difference between that and > >>> 'write' to me. > >>> > >> INCR and DECR allow users to set a numerical value according to arithmetic > >> rule, although SET allows to set a fully arbitrary value. > >> If administrator want to allow users to modify a value in a limited way, > >> he can grant 'calculate' permission, instead of 'write' permission. > >> > >> If we would be talking about RDBMS, it is possible to switch client's > >> privileges during execution of a certain stored procedure. > >> However, memcached does not have such a feature, so we need to consider > >> more fine grained permissions. > >> > >> BTW, I noticed a different viewpoint, although I didn't reach the idea > >> before. > >> Since memcached does not have stored procedure, it might be a correct > >> answer > >> that the client switches its privileges when it tries to modify read-only > >> values. Like set-uid programs in unix, SELinux has a feature to switch > >> privileges of process on execve(2) time. It allows a small number of > >> trusted > >> programs to write values, but prevents to modify items by others. > >> > >>> If a strict security partitioning is desired, then perhaps a single > >>> reference counter isn't feasible. Would it not be better, from a security > >>> point of view, to have individual counters for the different clients? > >>> The clients would have 'create|read|write' permissions, and any overall > >>> administrative app could have read-only permissions on all those counters > >>> to > >>> collect and sum (or otherwise report) them? > >>> > >> If a strict security partitioning environment, it seems to me what you > >> introduced > >> is reasonable. > >> > >> Thanks, > >> > >>> Kelvin > >>> > >>> On 02/08/10 1:45 AM, "KaiGai Kohei"<kai...@ak.jp.nec.com> wrote: > >>> > >>>> (2010/07/30 22:55), Kelvin Edmison wrote: > >>>>> While I haven't yet read the patch, I would like to understand why > >>>>> there is > >>>>> a need for a Calculate permission. Why would someone be granted > >>>>> 'calculate' > >>>>> permission but not 'write' permission? > >>>>> > >>>>> Kelvin > >>>>> > >>>> The issue depends on individual user's requirement of security. > >>>> If they want not to leak anything over the security domains, > >>>> they should grant the 'calculate' permission on everybody who > >>>> already have both 'read' and 'write' permissions. > >>>> It it equivalent to these permissions. > >>>> However, it may lack flexibility in configuration of access > >>>> controls, if users don't consider 'INCR' and 'DECR' are risk > >>>> information leaks/manipulations. > >>>> For example, it is not a rare case that we don't want to expose > >>>> individual client's items, but want to control a shared reference > >>>> counter. > >>>> > >>>> Ideally, I'd like to define more fine grained permissions to > >>>> distinguish a security sensitive operations and others. > >>>> But here is limitation of protocol. We cannot automatically > >>>> determine what is security sensitive data and what is not. > >>>> > >>>> Thanks, > >>>> > >>>>> On 30/07/10 12:49 AM, "KaiGai Kohei"<kai...@ak.jp.nec.com> wrote: > >>>>> > >>>>>> I'll mainly submit the patch and message to SELinux community, > >>>>>> but please don't hesitate to comment anything from memcached > >>>>>> community. > >>>>>> -------- > >>>>>> > >>>>>> The attached patch adds policies to support access controls > >>>>>> on key-value items managed by memcached with SELinux engine. > >>>>>> > >>>>>> Nowadays, various kind of key-value-stores support memcached > >>>>>> compatible protocol as a de-facto standard. So, it will be a > >>>>>> reasonable start to consider the protocol to control accesses > >>>>>> from clients; typically web applications. > >>>>>> > >>>>>> > >>>>>> http://github.com/memcached/memcached/blob/master/doc/protocol.txt > >>>>>> > >>>>>> 1) new permissions > >>>>>> > >>>>>> This patch adds 'kv_item' class with the following permissions > >>>>>> - create > >>>>>> - getattr > >>>>>> - setattr > >>>>>> - remove > >>>>>> - relabelfrom > >>>>>> - relabelto > >>>>>> - read > >>>>>> - write > >>>>>> - append > >>>>>> - calculate > >>>>>> > >>>>>> Most of permission works as literal. > >>>>>> On the 'SET' or 'CAS' operations, it creates a new item when > >>>>>> here > >>>>>> is no items with same kye. In this case, 'create' permission > >>>>>> shall > >>>>>> be checked. Elsewhere, 'write' permission shall be checked on > >>>>>> the > >>>>>> existing items. > >>>>>> > >>>>>> When an item get expired, it shall be unlinked internally. In > >>>>>> this > >>>>>> case, no permissions are checked, because it does not work > >>>>>> according > >>>>>> to the user's request. > >>>>>> > >>>>>> On the 'FLUSH_ALL' operation, it unlinks any items older than > >>>>>> a certain watermark. In this case, 'remove' permission shall be > >>>>>> checked on the items to be unlinked. If violated, it skips to > >>>>>> unlink this item. > >>>>>> > >>>>>> On 'INCR' or 'DECR' operation, 'calculate' permission shall be > >>>>>> checked. > >>>>>> Is it necessary to distinguish between 'INCR' and 'DECR' here? > >>>>>> E.g, an item which can be incremented, but unavailable to > >>>>>> decrement. > >>>>>> > >>>>>> 2) new types > >>>>>> - memcached_db_t > >>>>>> Some of modular memcached engines support on-disk storage, not > >>>>>> only > >>>>>> volatile ram. The selinux_engine.so allows us to use a certain > >>>>>> file > >>>>>> as a backend storage, but existing policy does not have > >>>>>> definition > >>>>>> of data file type. This type allows memcached_t read/write > >>>>>> accesses. > >>>>>> > >>>>>> - memcached_item_t (default of unconfined domain) > >>>>>> - memcached_ro_item_t > >>>>>> - memcached_secret_item_t > >>>>>> - user_memcached_item_t (default of rbac domain) > >>>>>> - unpriv_memcached_item_t (default of unprivileged domain) > >>>>>> These are types of individual key-value items. > >>>>>> The three default types are read-writable for its domains, > >>>>>> memcached_ro_item_t is read-only for confined domains, and > >>>>>> memcached_secret_t is invisible from confined domains. > >>>>>> > >>>>>> 3) supplemental policies > >>>>>> - This patch also adds permission on memcached_t to communicate > >>>>>> with > >>>>>> SELinux using netlink socket and selinuxfs. > >>>>>> - This patch also adds permission on memcached_t to write out > >>>>>> audit > >>>>>> logs onto auditd daemon, although it is not implemented yet. > >>>>>> > >>>>>> Thanks, Any comments please. > >>>>> > >>> > >>> > >> > >> > > > > > > > -- > KaiGai Kohei <kai...@ak.jp.nec.com> >
