William Roberts wrote:
On May 21, 2015 7:53 AM, "Joshua Brindle"<brindle@xxxxxxxxxxxxxxxxx> wrote:
William Roberts wrote:
On Wed, May 20, 2015 at 9:17 PM, Jeffrey Vander Stoep<jeffv@xxxxxxxxxx>
wrote:
Thanks for all the feedback and suggestions. Agreed that raw numerical
values are confusing. I will fix up the commit message to set a better
precedent for intended use. I included them more to illustrate what is
happening under the hood. I like the idea of a qualifier for clarity.
The qualifier seems necessary for the suggested non-ioctl-specific
approach.
Individual ioctl labels are only marginally better than raw numbers.
E.g. { TCSETSF TIOCGWINSZ TCGETA TCSETA TCSETAW TCSETAF TCSBRK TCXONC
TIOCMBIS }. More helpful...but not much.
My plan was to group commonly used ioctl sets into macros.
e.g. common_socket_ioc, priv_socket_ioc, tty_ioc, gpu_ioc, etc
This is exactly what I had in mind, just use m4
Even outside of my analysis use case I think this is not a good idea.
Consider the Android base policy defined gpu_op as a set of ioctls, and
there were related rules for gpu users defined there. Then a device variant
policy has additional gpu_op ioctl's. How does it add them? Does it have to
re-add all of the related rules with the new ioctls?
I could define a new macro my_device_GPU_ioctls and include the base macro
in its expansion.
And repeat every related rule (and keep them in sync as the base policy
develops). How much easier is it just to add your ioctl to an ioctl
attribute and be done?
In the ioctl-attibute case the variant policy would just add its specific
ioctls to gpu_op and everything would be taken care of.
Then we just need to preserve the symbols for looking at policies and
we'll all be happy, right?
After monitoring ioctl use across five different devices I think this
is a good approach as just 10-20 macros would be adequate for a
targeted policy and would provide a clearer explanation of the
permissions given.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
