Re: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))

Поиск
Список
Период
Сортировка
От KaiGai Kohei
Тема Re: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))
Дата
Msg-id 4AE801F0.6030202@ak.jp.nec.com
обсуждение исходный текст
Ответ на Re: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
Heikki Linnakangas wrote:
> KaiGai Kohei wrote:
>> Robert Haas wrote:
>>> 2009/10/27 KaiGai Kohei <kaigai@ak.jp.nec.com>:
>>>> - no statement support to specify security context.
>>>>  (It makes impossible to add support in pg_dump. Is it really OK?)
>>> I doubt that anything without pg_dump support would be even vaguely OK...
>> In my previous experience, it enabled to reduce 300-400 lines of the patch.
>> But here is no more sense than the 300-400 lines.
>>
>> In my honest, I like to include a feature to specify an explicit security
>> context in the patch from the begining.
>> (It also allows to attach test cases with more variations.)
> 
> Can you explain why that's required for pg_dump support? I was thinking
> that there would be no explicit security labels on objects, and
> permissions would be checked based on other inherent properties of the
> object, like owner, name, schema etc.

In SELinux model, security context is the only property which can be
used to decision making based on the security policy.
It never uses any other properties, like owner, name, ...

There are two cases when we create a new object.

1) create a new object without any explicit security context.
If we don't have statement support, it is the only case.
In this case, SELinux computes a default security context to be assigned
on the new object. It depends on the client's security context.
Then, it checks "create" permission on a pair of the client's security
context and the default security context. If not allowed, an error will
be raised.

2) create a new object with an explicit security context.
In this case, the given explicit security context will be assigned.
SELinux checks "create" permission on a pair of the client's security
context and the given explicit security context. If not allowed, an error
will be raised.

Please note that SELinux assigns a security context on the managed object
in either cases.

If we don't have any statement support, there are no way to specify
an explicit security context on the new object in creation.
It also means we cannot recover the security context of objects correctly.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Parsing config files in a directory