Re: questions about persistent storage of security contexts

[Andrew Warner <warner@rubix.com>]

[-- Attachment #1: Type: text/plain, Size: 3336 bytes --]

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
>>> between string based contexts and an integer representation, the 
>>> mapping
>>> being stored/indexed inside the DBMS. This gives me a small storage 
>>> overhead
>>> with a fixed size.
>>
>> I don't have a problem with internal mapping like that.
>
> In SE-PostgreSQL, it maintains own internal mapping between text 
> represented
> security context and its integer identifier. The 'pg_security' system 
> catalog
> stores the pair of them.
>
> Any tuple (including system catalog) has its security context. It is 
> stored
> within padding area of HeapTupleHeader as an integer value, and it 
> means the
> primary key of 'pg_security' system catalog.
>
> It also enables to boost userspace AVC, because this idea makes 
> possible to
> implement it using a relationship between identifiers (not a text 
> representation).
>
>
> When the security policy is reloaded and it makes invalidate the 
> stored context,
> the stored one is dealt as 'unlabeled_t'.
>
>> But, don't we already have sepostgresql?  Maybe you should be looking
>> to see if that fits your needs or you might get ideas from the work
>> that they performed?
>
> FYI:
>   http://code.google.com/p/sepgsql/
>
> Andrew, what is your intended base RDBMS?
>
> Currently, SE-PostgreSQL is the only SELinux awared RDBMS.
> It is now under reviewing for the next release (v8.4) cycle.
>   http://wiki.postgresql.org/wiki/CommitFest:2008-07
>
> However, I think we can apply SELinux for any other relational model 
> implementation.
>
> Thanks,

[-- Attachment #2: Type: text/html, Size: 4169 bytes --]