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

From Greg Williamson
Subject Re: SE-PostgreSQL Specifications
Date
Msg-id 789560.98116.qm@web46112.mail.sp1.yahoo.com
Whole thread Raw
In response to Re: SE-PostgreSQL Specifications  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: SE-PostgreSQL Specifications
List pgsql-hackers
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
myknowledge 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.
 

The sheer scope of this proposal undoubtedly gives pause to many, so I'd urge a certain minimalism at first to prove
thatthe concept works and doesn't damage the core functionality at all when it is not used (fairly straight forward).
Eventuallyrough 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.
 

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

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>

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


     


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: 8.4 win32 shared memory patch
Next
From: Peter Eisentraut
Date:
Subject: Alpha releases: How to tag