On Thu, May 21, 2015 at 10:10 AM, James Carter <jwcart2@xxxxxxxxxxxxx> wrote:
> On 05/21/2015 10:04 AM, Paul Moore wrote:
>> On Thu, May 21, 2015 at 9:54 AM, Stephen Smalley <sds@xxxxxxxxxxxxx>
>> wrote:
>>> On 05/21/2015 09:50 AM, Stephen Smalley wrote:
>>>> On 05/21/2015 09:43 AM, James Carter wrote:
>>>>>
>>>>> Do you have something else in mind that might use the operation
>>>>> structures?
>>>>>
>>>>> In CIL we will probably make the syntax something like this:
>>>>>
>>>>> ((allowop <source> <target> <class> <ioctl expression>)
>>>>>
>>>>> So the above rule might look like:
>>>>>
>>>>> (allowop <source> <target> <class> ((range 0x8910 0x8926) 0x892A))
>>>>
>>>>
>>>> Paul asked to generalize it so it can be reused for other purposes. One
>>>> example would be netlink message types. Today, there is a hardcoded
>>>> table in SELinux (security/selinux/nlmsgtab.c) that maps specific
>>>> netlink message type values to nlmsg_read (i.e. reads public kernel
>>>> state), nlmsg_readpriv (i.e. reads potentially sensitive kernel state),
>>>> nlmsg_write (i.e. modifies kernel state), and a few other audit-specific
>>>> values so we can distinguish e.g. who can read vs write routing table
>>>> entries or audit configuration, as the normal socket read/write checks
>>>> merely control the ability to send/recv on the socket, which is always
>>>> required for any user of it. That has limited flexibility and isn't
>>>> generally well maintained for newer netlink protocols.
>>>
>>>
>>> So the proposal would be to just add an additional field specifying how
>>> to interpret/apply the operation list, e.g.
>>> (allowop <source> <target> <class> <ioctl|netlink|...> ((range 0x8910
>>> 0x8926) 0x892A))
>>
>>
>> Looks to me like a good solution for CIL.
>>
>
> I agree.
>
> So why not have a syntax like the following for checkpolicy?
>
> allowop <source> <target> <class> <ioctl|netlink|...> { 0x8910-0x8926 0x892A
> };
>
> Woudln't that be clearer?
I have no strong preference here, I'll leave that to the folks working
on the policy toolchain.
--
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.
