Re: The reason why SEPostgreSQL use original userspace AVC

[KaiGai Kohei <kaigai@kaigai.gr.jp>]

Stephen Smalley wrote:
> On Mon, 2007-03-19 at 23:11 +0900, KaiGai Kohei wrote:
>> Hi,
>>
>> This was one of the topics discussed on SELinux developer summit held on
>> last Friday.
>> I like to send the reason why I made a decision to implement SE-PostgreSQL
>> with original userspace AVC, for wider discussion.
>> (SE-PostgreSQL didn't use the userspace AVC provided by libselinux.)
>>
>> There are two major reasons. The one is a performance gain. The other is
>> concurrency of invalidation.
>>
>> Any comment and suggestion please.
>>
>> [ performance gain ]
>>
>> The biggest reason is originated from the way to associate a security context
>> for each tuple. As I mentioned, I modified the internal data structure of
>> tuples to add its security context. The field is a 4-byte length integer
>> variable (same as object id data type), not a string expression.
>> This value is associated with the contains of 'pg_selinux'.
>>
>> 'pg_selinux' is one of the system catalogs. System catalogs are special tables
>> which contains database meta information like definition of table, view, stored
>> procedure and so on.
>> 'pg_selinux' has two column. One is 'oid' defined as object id type. It hold
>> a unique number within the table. The other is 'selcontext' defined as variable
>> length text type. It hold a security context in text expression.
>> So, we can refer the pg_selinux system catalog, when a text expression of security
>> context is required.
>> (e.g A case when 'security_context' is specified in SQL queries.)
>>
>> The object id enables to identify a security context in text expression, so we
>> can also apply them as a key of userspace avc. I named it as psid (persistent
>> security id).
>>
>> Using psid enables to be unnecessary to handle a text represented security context
>> in the most frequently path. When we have to make a decision whether the fetched
>> tuple is allowed or not, we can search the userspace avc with psid held by the tuple
>> as is.
>>
>> In the userspace avc provided by libselinux. Its avc_has_perm() requires security_id_t
>> as arguments, but it means we have to translate security context from psid to text
>> representation in a decision making process.
>> No need to say, it make a bad effect to the performance of SE-PostgreSQL.
> 
> So I understand correctly, the underlying issue here is that you want
> your userspace object manager to be able to generate its own SID mapping
> (in your case, using these psids or object ids) rather than have the SID
> mapping handled entirely within libselinux, so that you can have the ids
> also represent something meaningful to the object manager for efficient
> lookup.  It seems possible to have the libselinux userspace AVC export
> interfaces to allow an object manager to optionally populate the
> SID->context mapping itself using identifiers it selects.  Would that
> address your concern?

Yes.
If we can use PSIDs as an alternatives of security_id_t, it seems to me
a good idea.

>> [ concurrency of invalidation ]
>>
>> SE-PostgreSQL deploys its userspace avc on the shared memory region, and generates
>> a single policy state monitoring process to poll netlink socket at bootup time.
>> It enables to invalidate the userspace avc referred by all SE-PostgreSQL instances
>> concurrently.
>>
>> If the userspace avc is deployed on the process local memory for each instance,
>> we need policy state monitoring threads for each instances and the invalidation
>> of userspace avc is not done concurrently.
>> At a moment, different policies may be applied between SE-PostgreSQL instances.
>>
>> In addition, we will get a little performance improvement on startup time of instances.
>> If the userspace avc deployed on the shared memory region, it may contains several
>> access control rules before it is referred at first. It enables to reduce the number
>> of calling system-call.
>> And, it is not necessary to generate a policy state monitoring thread for each
>> SE-PostgreSQL instance.
> 
> I'd be interested in seeing your userspace AVC implementation - is it
> short enough that you can post it, or if not, point us to the specific
> files in your repository?  I would tend to think that any gains you
> might get from sharing a single AVC among multiple processes would tend
> to be negated by 1) the locking required to make that safe (similar to
> the locking support in the AVC for multi-threaded applications), and 2)
> the affect on the cache of having multiple processes using it for
> different access checks. 

http://sepgsql.googlecode.com/svn/trunk/src/backend/security/sepgsqlCore.c
includes the implementation of userspace AVC.

It utilizes the shared memory management system in PostgreSQL.
sepgsqlShmemSize() is called to return the size of avc we need.
In sepgsql_avc_init(), ShmemInitStruct() is called to create/attach a shmem
segment.
If the shmem segment is newly generated, we initialize a lock variable and
the userspace avc deployed on the shmem segment.

sepgsql_avc_audit() is called to generate an audit message.

sepgsql_avc_permission_noaudit() is the core of the userspace avc.
It uses a light weight lock provided by PostgreSQL. In actually, it's a mutext
lock held on shmem segment.

sepgsqlMonitoringPolicyState() is the implementation of policy state monitoring
process. It is fork()'ed on bootup.

http://sepgsql.googlecode.com/svn/trunk/src/backend/security/sepgsqlPsid.c
provides translation between PSID and security contexts in text representation.

When we try to update/insert on a cell declared with PSID type, psid_in() is
called at first. It formalize the security context into raw format. Then, it
convert into PSID by looking up pg_selinux system catalog.
In finally, a security context we inputed with text representation is translated
into an integer value with 4-byte length.

> Also, IIUC, you don't need to have a separate
> thread monitoring the netlink socket per se; the libselinux AVC can
> check just its state on each avc_has_perm call in the non-threaded case.

The checks are done by recvfrom() with a netlink socket.
Because the userspace AVC is referred so frequently in SE-PostgreSQL,
I thought that checks on each avc_has_perm() will cause serious
performance degradation.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.