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