> 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@xxxxxxxxxxxxx>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
