|
Thanks for the information. I have previously looked
at the SE-PostgreSQL code/documentation. It was helpful and most
interesting. The base DBMS I am using is called Trusted RUBIX, which is
an CC EAL-4 (Trusted Solaris) evaluated MLS DBMS. We have been
contracted to integrate SELinux TE and MLS (Red Hat flavor) into our
DBMS. So, obviously using SE-PostgreSQL is not an option :-) In the
bigger picture, this current work is a small (and rather detached) step
towards a high robustness (EAL-6+) DBMS solution. Historically, our company (and myself personally) have been involved in high(er) assurance MLS DBMS products/research for a number of years. As such, we tend to use a more "traditional" minimized trust, reference monitor architecture as opposed to inserting hooks and using query modification for our security enforcement. This means, for instance, that a label object permeates much of our kernel code at a fairly low level as well as storage objects. Thus, the runtime and storage representation must be chosen carefully as it will touch much of our kernel code. We also support full polyinstantiation of named objects, which dictates an efficient label mechanism. (Integration of TE + MLS into traditional MLS polyinstantiation behavior is an interesting topic!) Out of curiosity, KaiGai, a question about how SE-PostgreSQL presents the security context to a user. From your security guide I see that the context is a selectable column. But, what SQL type is the column? For instance, do you define your own SQL type, such as "Security Context" or is it a VARCHAR that has special constraints placed upon it to force it to conform to the structure of a security context? Blessings, Andy KaiGai Kohei wrote: I have also considered maintaining my own internal, persistent mapping |
