Re: [PATCH 0/2] selinux: add targeted whitelisting of ioctl commands.

[Joshua Brindle <brindle@quarksecurity.com>]

Paul Moore wrote:
> On Thu, May 21, 2015 at 12:17 AM, Jeffrey Vander Stoep<jeffv@google.com>  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.