From: kaigai@ak.jp.nec.com (KaiGai Kohei) Date: Mon, 16 Aug 2010 14:38:56 +0900 Subject: [refpolicy] memcached permissions In-Reply-To: <4C5A03DD.5080605@ak.jp.nec.com> References: <4C5A03DD.5080605@ak.jp.nec.com> Message-ID: <4C68CEF0.2070202@ak.jp.nec.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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" 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" 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: refpolicy-memcached.2.patch Type: text/x-patch Size: 12615 bytes Desc: not available Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100816/e9f7ef36/attachment.bin