Re: [PATCH] SE-PgSQL/tiny rev.2193 - Mailing list pgsql-hackers

From KaiGai Kohei
Subject Re: [PATCH] SE-PgSQL/tiny rev.2193
Date
Msg-id 4A650E74.1090100@ak.jp.nec.com
Whole thread Raw
In response to Re: [PATCH] SE-PgSQL/tiny rev.2193  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PATCH] SE-PgSQL/tiny rev.2193  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: COPY WITH CSV FORCE QUOTE *
Next
From: Greg Stark
Date:
Subject: Re: [PATCH v4] Avoid manual shift-and-test logic in AllocSetFreeIndex