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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 21, 2015 at 10:16 AM, Joshua Brindle
<brindle@xxxxxxxxxxxxxxxxx> wrote:
> Paul Moore wrote:
>> 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.
>>
>
> 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.

-- 
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.




[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux