Re: How to get SE-PostgreSQL acceptable

Bruce Momjian wrote:
> KaiGai Kohei wrote:
>>> Why an OID?  We store acl items now without a lookup table;  I think
>>> there will be at most the same number of SE-Linux entries.  Also, by
>>> using text we avoid the problem of cleaning out unreferenced pg_security
>>> rows, improve performance (no lookups), and simplify the code.
>> The reason why I concern about text formed security context is
>> it has variable length, so it requires to deform/form a HeapTuple
>> again when SE-PostgreSQL assigns a default security context.
>> If a user inserts a new tuple into pg_xxxx without explicit security
>> context, it has to be labeled based on security context. We cannot
>> estimate what string will be given prior to ExecInsert(), it needs
>> to put a security label on the given HeapTuple.
>> If is is a fixed length variable (like "oid"), it is not necessary
>> to deform/form them. So, I prefer the security identifier.
>>
>> In addition, it also has performance gain.
>> The current architecture does not need to look up pg_security in most
>> cases. SE-PostgreSQL caches results of access controls in userspace
>> to reduce the number of kernel invocation.
>> (In generally, context switch is a heavy one.)
>> All cached entries are tagged by its security identifier, so we can
>> lookup the entry without string comparing. The text form is used
>> only when it could not find the entry on the cache. In this case,
>> SE-PostgreSQL translate security identifier into text form and
>> ask for in-kernel SELinux. It requires a text form due to the
>> protocol.
> 
> That is an interesting optimization I had not thought of.
> 

Just as an FYI, SELinux does this in general. There is an access vector cache in 
the kernel that caches the access computations, and there is also a userspace 
implementation in libselinux that most apps use. KaiGai reimplemented the AVC 
because he wanted it to work in a shm and be shared by multiple postgres processes.

There is also a sidtab which is just a hashtable that maps string contexts to 
sids. The sidtab is filled at runtime and not persistent across boots, which 
means the contexts are generally stored as text on the persistent medium (like 
the xattr's on the filesystem).

It doesn't matter from a security perspective whether the contexts are stored as 
strings or sids, its just an optimization you guys need to work out.

>> At least, we cannot apply this scheme on the next phase (row-level)
>> due to the storage consumption and others. So, I don't think it is
>> a preferable way to design the first step without ignoring upcoming
>> expandability.
> 
> The big problem is that the security value on system tables controls the
> _object_ represented by the row, while on user tables the security value
> represents access to the row.  That is just an odd design, and why a
> regular system table security value makes sense, independent of the
> row-level security feature.
> 

I may not be understanding this but I don't see why. In SELinux everything is an 
object, and all objects have contexts. No access is specified on the object or 
in the context, that is all done in the policy currently loaded in the security 
server. system tables and user tables shouldn't be treated differently 
implementation wise, they should just have a context and defer the decision 
making to the policy.

In practice the system tables (and rows within the tables) would have a context 
that restricts access tightly, but this is up to the policy, not the implementation.

> FYI, it is possible we might implement row-level security a different
> way in 8.5.