KaiGai Kohei
memcached permissions
July 30, 2010 07:00AM
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]>
Kelvin Edmison
Re: memcached permissions
July 30, 2010 04:00PM
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.
KaiGai Kohei
Re: memcached permissions
August 02, 2010 07:50AM
(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]>
Kelvin Edmison
Re: memcached permissions
August 04, 2010 03:30AM
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.

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?

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
Re: memcached permissions
August 05, 2010 02:30AM
(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]>
KaiGai Kohei
Re: memcached permissions
August 16, 2010 07:40AM
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]>
KaiGai Kohei
Re: memcached permissions
August 27, 2010 10:50AM
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]>
dormando
Re: memcached permissions
August 27, 2010 11:10AM
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]>
>
KaiGai
Re: memcached permissions
August 28, 2010 02:05AM
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]>
dormando
Re: memcached permissions
August 28, 2010 02:05AM
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]>
>
Sorry, only registered users may post in this forum.

Click here to login