Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)

Поиск
Список
Период
Сортировка
От KaiGai Kohei
Тема Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
Дата
Msg-id 49427C28.8050804@kaigai.gr.jp
обсуждение исходный текст
Ответ на Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)  ("Robert Haas" <robertmhaas@gmail.com>)
Список pgsql-hackers
Peter Eisentraut wrote:
> KaiGai Kohei wrote:
>>> I would like to be able to assign SQL-level ACLs and SELinux labels 
>>> to the same row at the same time in the same build, and have the 
>>> system enforce both on top of each other.
>>
>> In my opinion, it makes more pains (user-interface, performance, 
>> complexity
>> of implementation and so on) than its benefit which allows to support MAC
>> and DAC concurrently.
> 
> I am a bit surprised.  I'd consider the ability to do DAC and MAC 
> concurrently to be absolutely essential, for several reasons:
> 
> 1. DAC is managed by users, MAC by administrators.
> 
> 2. They address different but concurrent use cases.

Yes,
Please note that I don't say it is something worthless.
However, when we implement it with a single security system column,
its demerit is unacceptable.

> 3. Transitioning to MAC will be a lot easier if it doesn't require you 
> to drop the DAC configuration all at once.
> 
> 4. You don't propose to drop table ACLs if you enable SELinux, do you? 
> Same issue.

Yes, management of security attribute is a major work of security features.
Thus, when we switch the active security feature, it does not managed
correctly. Please imagine what is happen when we remount ext3 filesystem
without "acl" flag, or we boot a SELinux'ed system with selinux=0.

> 5. It's possible!

Indeed, it is possible, but it is fact we also have some of trade-offs.
The biggest matter is user-interfaces to modify security attribute is
unclear.

If we have two system column, "security_acl" for DAC and "security_label"
for MAC, it allows to implement the feature without remarkable pains.
Well, we can simply update the "security_acl" to update per tuple ACLs.
However, again, we return to start of the discussion.

Tom said:> Wait a minute.  The original argument for providing SQL-driven row level> security was that it would help
providea framework for testing the code> and doing something useful with it on non-selinux platforms.
 

I think it is not a issue which has perfect answer, so we need to decide
a way to implement it. My preference is 1 security system column and
1 security feature design.

I tried to summarize the proposed options, as follows:

o : merit    x : demerit    X : unacceptable demerit

* 1 security system column, 1 security feature (DAC or MAC) o It suitable for a single security system column
implementation.x If a user want to use both of DAC and MAC concurrently, he has   to choose one of them. o It allows
allthe security feature on the common framework,   suitable for the original Row-level ACLs purpose.
 

* 2 security system column, 2 security feature (DAC and MAC) o It allows both of DAC and MAC consurrently, without
remarkable  regressions. x It needs two new security system columns. x What is the purpose of the Row-level security in
original?

* 1 security system column, 2 security feature X It gives us catastrophic regression in user-interface, performance
andcode complexity. Its merit is trivial compared to its demerit.
 

--
KaiGai Kohei


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

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: WIP: default values for function parameters
Следующее
От: "Pavel Stehule"
Дата:
Сообщение: Re: WIP: default values for function parameters