Re: memcached permissions

[KaiGai Kohei <kaigai@ak.jp.nec.com>]

(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@ak.jp.nec.com>  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@ak.jp.nec.com>   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@ak.jp.nec.com>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.