Re: [PATCH] SE-PgSQL/tiny rev.2193

Поиск
Список
Период
Сортировка
От KaiGai Kohei
Тема Re: [PATCH] SE-PgSQL/tiny rev.2193
Дата
Msg-id 4A650E74.1090100@ak.jp.nec.com
обсуждение исходный текст
Ответ на Re: [PATCH] SE-PgSQL/tiny rev.2193  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [PATCH] SE-PgSQL/tiny rev.2193  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas wrote:
> I have attempted, on the relevant threads, to enumerate those problems
> as I see them.  Mainly they have to do with hooks all over the code in
> strange and unmaintainable places, documentation that is written in
> poor English and is not easily understandable by people who are not
> already experts in SE-Linux, and a complete inability to get a patch
> that implements a useful subset of the total realm of SE-Linux
> desiderata that more or less matches up with what the existing
> PostgreSQL permissions structure already does.  What we've established
> so far is that the following things should NOT be in the list of
> permissions that we attempt in the initial patch:
> 
> - row-level security
> - complex DDL permissions

Is the complex DDL permissions mean something like db_xxx:{create},
db_xxx:{relabelfrom relabelto} and others?
If so, I can agree to implement these checks at the later patch.

However, please note that the initial patch cannot achieve actual
security in this case, because it means anyone can change security
label of objects.

> But I think the following things probably should be:
> 
> - tables
> - columns
> - sequences
> - functions
> - schemas
> - databases
> - tablespaces

I also think it is reasonable to apply access controls on the types
of object classes at the initial pach.

> I'd be willing to negotiate on all but the first.
> 
> I also agree with Peter's contention that a spec would be useful.  If
> you could read a clear description of what the patch was going to do,
> then you could separate the problem of figuring out whether that was
> the right thing from the question of whether the patch actually did
> it.

I can also agree with the suggestion.
The specifications (from viewpoint of the developer) will introduces
the fundamental principles to be implemented, and it will figure out
what implementation is better.

As I noted before, I've been flexible about how SE-PgSQL is implemented
as far as it can perform SELinux's security model correctly.

Please for a several days. I'll describe it.
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>


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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: COPY WITH CSV FORCE QUOTE *
Следующее
От: Greg Stark
Дата:
Сообщение: Re: [PATCH v4] Avoid manual shift-and-test logic in AllocSetFreeIndex