You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since policies are mostly auto-generating large numbers of categories via macros and defining each level as being authorized for all categories and defining various initial security contexts with all categories set, the category representation in the policy ends up being larger than needed. It would be helpful to allow the policy to just specify the number of categories and not need to store the c0, c1, ... strings in the policy when we do not want human-meaningful names in the kernel categories, and to provide an efficient ebitmap representation of all-categories-set without actually generating a large bitmap with all bits set. This can be done at multiple levels, from just changing the ebitmap representation in the policy (requiring changes to libsepol and the kernel and a new policy version) to also extending the policy language and security server to support implicit category definition with only the number of categories being specified.
Also consider a more efficient representation in security context strings, e.g. a bitmap string format ala 0xfffffe0d..., to reduce the pressure on passing security context strings across often page-size-limited boundaries for /proc/pid and selinuxfs and reduce memory consumption. (However, this may not prove to be a win, since the current format is more efficient for sparse bitmaps and allows compact representation of a series of consecutive categories via the cN.cM notation; probably the major corner case at present is when you have a bitmap with every other bit set).
The text was updated successfully, but these errors were encountered:
Also if we do this we should simultaneously synchronize the ebitmap structures and code used by libsepol to the ones used by the kernel, since the latter were optimized and those optimizations were not carried to libsepol or the policy file. (However, we cannot use the kernel ebitmap representation exactly, since it is now arch-specific, unlike the policy ebitmap representation, which should remain arch-neutral.)
Since policies are mostly auto-generating large numbers of categories via macros and defining each level as being authorized for all categories and defining various initial security contexts with all categories set, the category representation in the policy ends up being larger than needed. It would be helpful to allow the policy to just specify the number of categories and not need to store the c0, c1, ... strings in the policy when we do not want human-meaningful names in the kernel categories, and to provide an efficient ebitmap representation of all-categories-set without actually generating a large bitmap with all bits set. This can be done at multiple levels, from just changing the ebitmap representation in the policy (requiring changes to libsepol and the kernel and a new policy version) to also extending the policy language and security server to support implicit category definition with only the number of categories being specified.
Also consider a more efficient representation in security context strings, e.g. a bitmap string format ala 0xfffffe0d..., to reduce the pressure on passing security context strings across often page-size-limited boundaries for /proc/pid and selinuxfs and reduce memory consumption. (However, this may not prove to be a win, since the current format is more efficient for sparse bitmaps and allows compact representation of a series of consecutive categories via the cN.cM notation; probably the major corner case at present is when you have a bitmap with every other bit set).
The text was updated successfully, but these errors were encountered: