On Thu, May 21, 2015 at 9:35 AM, Joshua Brindle
<brindle@xxxxxxxxxxxxxxxxx> wrote:
> Paul Moore wrote:
>> On Thu, May 21, 2015 at 12:17 AM, Jeffrey Vander Stoep 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....
Except for the policy interfaces, permission sets, etc. ;)
See Stephen's comments on this, specifically the idea that ioctls are
not objects. Further, the existing permission set shorthand is a very
good precedence for this approach towards ioctl number handling; I see
no reason *not* to use m4.
> An attribute-like symbol that is maintained in the binary would make these
> visible in the loaded policy and therefore more understandable/analyzable.
I think the proposed approach is easily understood and/or 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.
Once again, I think the proposed approach ticks these boxes as well.
--
paul moore
www.paul-moore.com
_______________________________________________
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.
