Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide more efficient category representation in policy and security contexts #30

Open
stephensmalley opened this issue Nov 17, 2016 · 1 comment

Comments

@stephensmalley
Copy link
Member

stephensmalley commented Nov 17, 2016

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

@stephensmalley
Copy link
Member Author

stephensmalley commented Nov 17, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant