Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep) - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Date
Msg-id 200809231507.30264.josh@agliodbs.com
Whole thread Raw
In response to Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  (Bruce Momjian <bruce@momjian.us>)
Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Bruce,

> I think the community's priorities are to add security at the SQL
> level, and then we can see clearly what SE-PostgreSQL requires.  This
> has been discussed before so it should not come as a surprise.

Well, I'm not that clear on exactly the SE implementation, but I spent a 
fair amount of time with Trusted Solaris and I can tell you that a 
multilevel security implementation would work in a different way from SQL 
row-level permissions.

Multilevel frameworks have concepts of data hiding and data substitution 
based on labels.  That is, if a user doesn't have permissions on data, 
he's not merely supposed to be denied access to it, he's not even supposed 
to know that the data exists.  In extreme cases (think military / CIA use) 
data at a lower security level should be substitited for the higher 
security level data which the user isn't allowed.  Silently.

So it's quite possible that the SE and/or multilevel framework could remain 
parallel-but-different from SQL-level permissions, which would not include 
data hiding or data substitution.

-- 
--Josh

Josh Berkus
PostgreSQL
San Francisco


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Subtransaction commits and Hot Standby
Next
From: Bruce Momjian
Date:
Subject: Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)