Paul Moore wrote:
On Thu, May 21, 2015 at 12:17 AM, 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.
Great, thank you.
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
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.
Agreed. We can use m4 to provide both the ioctl names and sets if needed.
m4 is never the answer....
An attribute-like symbol that is maintained in the binary would make
these visible in the loaded policy and therefore more
understandable/analyzable.
It would also allow you to easily add them in specific devices in a more
readable way. For example, if the Android base policy allowed gpu_ioc to
surfaceflinger all a device specific variant would need to do is add its
ioctls to the attribute.
_______________________________________________
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.
