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]>
