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 10:16 AM, Joshua Brindle
> <brindle@quarksecurity.com>  wrote:
>> Paul Moore wrote:
>>> On Thu, May 21, 2015 at 9:35 AM, Joshua Brindle
>>> <brindle@quarksecurity.com>   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.
>>>
>> The reason *not* to use m4 is because we want some sort of meaningful
>> identifiers preserved in the kernel policy for analysis. I know that isn't
>> your use case but it is some of ours.
>
> You've got the ioctl numbers in the binary policy, which are the same
> numbers used in the policy representation, which are also the same
> numbers used by applications actually making use of the ioctl()
> syscall.  Other than the fact that these things are numbers and not a
> more conventional label string, I don't understand the problem.
>

That is precisely the problem. I'd like any extra symbolic information 
(e.g., calling this range of ioctls gpu_op) preserved and not thrown 
away by m4.

Some of us work on binary only systems where we don't get to see the 
source code of the applications or the policy.