I am currently developing an "SELinux aware" DBMS (primarily TE and
MLS) that is characterized by:
1. The need to store a security context (in some recoverable form) in
our persistent database (storage size of the context is an important
2. The need to frequently perform a high number of security access
checks in a performance sensitive way
My question relates to the first characteristic from above. I am having
trouble deciding on the best way to store the security context in the
database. From my research I* see (I think!) three different representations for a security context:
1) string; 2) raw; 3) SID.*
The string representation, generally, seems clear as this is what is
shown in all documentation as the context representation that exists in
user space. My only question regarding the string representation is: is
there is any hard limit to the length of the security context string?
Do I need to allow for no theoretical size limit on a context string if
I choose to store it?
I am inferring the
the raw representation exists from seeing *_raw functions (e.g.,
security_compute_create_raw) referenced in selinux header files. Other
than seeing these functions declared I am having trouble finding out
much about a raw representation. Is there any advantage to
storing/manipulating a context in its raw representation? That is, are
they more suited for a fast security access check, are they smaller in
size, or do they have a fixed or maximum length?
The SID I have also seen mentioned in various documentations but can
determine little about them. My guess is that they are an integer value
that is used for fast internal access, particularly for the AVC. Are
SIDs indeed integer values? Are they persistent or are they meaningful
only for a particular OS session?
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.
Any answers, pointers to documentation, or other help would be greatly
fedora-selinux-list mailing list