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 On 30/07/10 12:49 AM, "KaiGai Kohei" <[email protected]> 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.
