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"<kaigai@xxxxxxxxxxxxx> 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"<kaigai@xxxxxxxxxxxxx> 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 <kaigai@xxxxxxxxxxxxx> -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
