question on persistent security context storage
Andrew Warner
warner at rubix.com
Mon Jul 21 15:12:13 UTC 2008
Hello,
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 factor)
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
appreciated!
Andy Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20080721/4f214f23/attachment.htm>
More information about the fedora-selinux-list
mailing list