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:23 AM, Joshua Brindle
> <brindle@quarksecurity.com>  wrote:
>> Paul Moore wrote:
>>> 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.
>
> Sorry, I keep forgetting you are special.  Thanks for the multiple reminders.
>
> I suggest talking with James and the CIL folks to arrive at some
> solution that works well with CIL, whatever that might be.  As for the
> checkpolicy based policy, I think m4 is just fine if folks want to use
> it; there is no requirement that m4 must be used for this.
>
> Further, if we do need to introduce some attribute like construct for
> these operations/ranges/permissions/whatever-we-call-them, I'm okay
> adding that in a future patchset, I see no reason to hold up this
> initial work for that.

It seems like some adjustments are being made anyway. I wish I'd brought 
this up when the patches were first posted so it is definitely my fault 
if it doesn't happen.

I doubt you'd want to be on the hook to analyze a policy that just dumps 
a wall of hex values instead of descriptive symbols though. This is the 
exact reason that attribute names are now preserved in the kernel 
binary, despite the kernel not needing them.