Joshua Brindle wrote:
> KaiGai Kohei wrote:
>> Joshua Brindle wrote:
>>> KaiGai Kohei wrote:
>>>> The attached patch for libsepol add suport for a new policy version
>>>> named as (MOD_)POLICYDB_VERSION_BOUNDARY.
>>>> Userspace hierarchy checks are reworked in this revision.
>>>>
>>>> FEATURES:
>>>>
>>>> - Boundary feature support:
>>>> The upcoming kernel has a feature to define boundary relationship
>>>> between two users, roles and types. It enables to restrict a bounded
>>>> one can never have wider permissions than its bounds one.
>>>> Any XXXX_datum_t structure have "u32 bounds" member to indicate its
>>>> bounds, and we can handle it with the latest version of policy format
>>>> provided by this patch.
>>>>
>>>> - Loading attributes into kernel space:
>>>> The upcoming kernel also allows to load entries of attribute.
>>>> The attached patch turn off to drop them, when it tries to write
>>>> kernel policy with its version is equal or greater than
>>>> POLICYDB_VERSION_BOUNDARY.
>>>> Any entries of attribute has a property of TYPEDATUM_PROPERTY_ATTRIBUTE.
>>>>
>>>> - Improvement of type_datum format on kernel/modular policy.
>>>> The type_datum entry has several its attribute fields like "primary",
>>>> "flavor" and "flags", and these are stored within separated fields
>>>> on-disk format. This patch enables to pack them into a single field.
>>>> Currently four bits are defined, and rest of them are reserved.
>>>> #define TYPEDATUM_PROPERTY_PRIMARY 0x0001
>>>> #define TYPEDATUM_PROPERTY_ATTRIBUTE 0x0002
>>>> #define TYPEDATUM_PROPERTY_ALIAS 0x0004 /* userspace only */
>>>> #define TYPEDATUM_PROPERTY_PERMISSIVE 0x0008 /* userspace only */
>>>>
>>>> - Hierarchy checks are reworked
>>>> The existing userspace hierarchy checks are reworked for the upcoming
>>>> boundary feature. It can handle parent one based on both newer bounds
>>>> relationship and existing name-based hierarchy.
>>>>
>>>> In addition, I put a trick to evaluate conditional rules correctly.
>>>> The following example shows a confusable case. A_t is the bounds of B_t,
>>>> so B_t can never has wider permission than A_t.
>>>>
>>>> Example)
>>>> allow B_t X_t : file { read_file_perms };
>>>> if (A_can_write_X) {
>>>> allow A_t X_t : file { write_file_perms };
>>>> } else {
>>>> allow A_t X_t : file { read_file_perms };
>>>> }
>>>>
>>>> A_t's permissions on X_t is depend on the 'A_can_write_X', however,
>>>> a part of them, like 'read', are unconditionally allowed.
>>>> If we can find common permission on both of true/false lists, these
>>>> are pulled up to unconditional rules.
>>>> Thus, B_t's read permission on X_t is not hierarchy violated in the
>>>> above example. It also matches the upcoming kernel behavior no need
>>>> to say.
>>>>
>>> Was this the latest patch? I can't seem to apply it either to the latest
>>> git HEAD or to the last svn revision:
>> Sorry, my Thunderbird translated any tabs into spaces.
>> The patch is made based on the latest subversion repository.
>> Can you apply the attached one correctly?
>>
>
> Yes it applies. I'm going to have to track down that bug you reported
> before merging this because it prevents policy compilation.
Note that the patch does not contain fixes for a bug I reported.
IMO, alias types of invisible primay should be simply filtered
at the expand_module(), or should generate an error.
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.
