Correct manner to handler undefined classes/permissions? (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei <kaigai@ak.jp.nec.com>]

> 5. Handle unsupported object classes/access vectors
> 
> What is the correct behavior for userspace object managers,
> when it tries to check undefined object classes or access
> vectors?
> 
> For example, we don't define db_database:{superuser} in the
> security policy. We cannot decide whether it is denied, or not.
> How the SE-PostgreSQL should perform for this?
> 
> In the current implementation, it simply ignores undefined
> permissions because string_to_av_perm() cannot return a valid
> access vector.
> 
> One possible idea is it performs according to /selinux/deny_unknown.
> If so, a new interface on libselinux is desirable.

This topic has been left for a week.

How should it be handled when we cannot find required classes or
permissions in the security policy?

The kernel allows anything or nothing for undefined object classes
based on policydb.allow_unknown. However, if the security policy
does not have a definition of the required access vector, it is
always denied (due to lack of explicit permission).

My preference is filling up the undefined access vectores with
policydb.allow_unknown. It seems to me quite natural.

Userspace object managers also have same issue.
Now it's unclear for me what is the preferable behavior.
For example, how should it handle the db_database:{superuser}
on the older security policy?

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
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.