Re: SE-PostgreSQL Specifications - Mailing list pgsql-hackers

Greg Williamson wrote:
> KaiGai --
> 
> I was pulled away from any work on this for a few days ... what can I do
> to help, if anything ? (Keeping in mind that my knowledge of the internals
> of postgres is, alas, minimal.) ... I had a quick look at this new page and
> want to take another, more careful, look.

I got a few reasonable sugegstions at the last week.
The one is it is important to provide a design specification from the viewpoint
of developers to make clear what features are provided by SE-PostgreSQL, and
it will be a good source for the official documentation for users.
The other is a suggestion corresponding to the way to implement it. Its conclusion
was to inject an abstraction layer to support multiple security models at first.

I guess Robert concerned about my English quality in the documentation patch
contained in the proposed patch set at first. In same time, lack of design
specification was pointed out. It also should be provided prior to the patch
to make clear what is identical to/different from the native database privilege
mechanism.

Both of them are documentations. But these have their own purpose, target and
style to be required. It might be a causion of the confusion.

In my current opinion, we should have a discussion corresponding to the design
specifications and internals, and implement it prior to the user documentation.

So, I would like you to give me the time to conclude the design specifications
and to implement patches for the next commit fest.

> The sheer scope of this proposal undoubtedly gives pause to many, so I'd urge
> a certain minimalism at first to prove that the concept works and doesn't damage
> the core functionality at all when it is not used (fairly straight forward).
> Eventually rough measures of the performance hit when it is used will be useful,
> but users will expect something of a slow-down, I suspect, in exchange foe the
> greater security.

Are you talking about what the user documentation should include, aren't you?
Indeed, I also think these items should be introduced.


> To that end, I am wondering if there is test data yet designed ? Are there
> prescribed tests (I remember seeing some but they seem to be buried in
> months/threads that I have not yet re-dicsovered) ? I have some experience doing
> QA and could perhaps also help in these, a little.

I also provided a patch for the testcases of SE-PostgreSQL.

For example: http://code.google.com/p/sepgsql/source/browse/tags/sepgsql/src/test/sepgsql

Thanks,

> And let me add, I am in awe of your efforts on this !
> 
> G
> 
> 
> 
> ----- Original Message ----
> From: KaiGai Kohei <kaigai@ak.jp.nec.com>
> To: Stephen Frost <sfrost@snowman.net>
> Cc: KaiGai Kohei <kaigai@kaigai.gr.jp>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers@postgresql.org; Greg
Williamson<gwilliamson39@yahoo.com>; Sam Mason <sam@samason.me.uk>; Joshua Brindle <method@manicmethod.com>
 
> Sent: Monday, August 3, 2009 12:09:45 AM
> Subject: Re: [HACKERS] SE-PostgreSQL Specifications
> 
> Stephen Frost wrote:
>>> I think what I should do on the next is ...
>>> - To check up whether it is really possible to implement SELinux's model.
>>> - To describe the list of the security functions in the new abstraction layer.
>>> - To discuss the list of permission at:
>>>   http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls
>> That sounds like a good approach.  As we define the security functions
>> to go into the abstraction layer, I would also say we should identify
>> the exact pieces of existing code which are going to move.
> 
> I began to describe the list of abstraction layer functions (but not completed yet):
>   http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction
> 
> In my current impression, it indeed requires a few kilo lines of changes,
> but it is not impossible scale.
> 
> I now plans to submit two patches for the next commit fest.
> The one is implementation of the abstraction layer.
> The other is basic implementation of the SE-PostgreSQL.
> 
> So, I would like to fix external specification at least.
> 
> The specifications for developer notes definitions of permissions:
>   http://wiki.postgresql.org/wiki/SEPostgreSQL_Development
> 
> As Robert suggested before, I plans to support access controls on the
> following database objects and permissions at the first stage.
> * databases
> * schemas
> * tables
> * columns
> * sequences
> * functions
> * tablespaces
> 
> Do you have any comment for the directions?
> 
> Thanks,


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