Ahhah, thanks :) Was uh, scared for a moment the that initial thread had been lost in time.
On Fri, 27 Aug 2010, KaiGai wrote: > Sorry for the confusion. > I intended to talk to maintainer of the standard security policy in > SELinux. > > It is my job to maintain the selinux_engine.so module. :-) > > Thanks, > > On 8月27日, 午後6:02, dormando <[email protected]> wrote: > > 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"<[email protected]> 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"<[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. > > > > > -- > > > KaiGai Kohei <[email protected]> >
