William Roberts wrote: <snip>
---- Policy format ---- allow<source> <target>:<class> { 0x8910-0x8926 0x892A-0x8935 } auditallow<source> <target>:<class> 0x892AI agree with only specifying the lower 16 bits (command,type) when specifying the individual ioctls, I even like the '-' shortcut, but I'm a little concerned about specifying a number directly in the permission field without any sort of qualifier. Specifically I'm worried that it hurts the readability of the policy and could pose problems with future work. I'd be much happier if we could add some sort of syntax which would qualify the numbers as ioctls, for example: allow<source> <target>:<class> { ioctl(0x8910-0x8926) ioctl(0x892A) }If you want additional syntax couldn't we move that burden to m4 rather then making it a part of the compiler core?
I haven't looked at the patches but the parser isn't going to be any more or less complex either way, so whatever looks better and is easier to generate is likely better.
These raw values really bother me, though. They make policy impossible to interpret if you do not have an intimate understanding of the drivers. Are these really permissions? It seems closer to Xen's labeling of memory addresses and pci devices.
For reference Xen policy labels various objects: pirqcon 33 system_u:object_r:nicP_t iomemcon 0xfebe0-0xfebff system_u:object_r:nicP_t iomemcon 0xfebd9 system_u:object_r:nicP_t ioportcon 0xecc0-0xecdf system_u:object_r:nicP_t pcidevicecon 0xc800 system_u:object_r:nicP_t And uses standard TE rules to allow access. Why not label ioctls and have an ioctl object class? _______________________________________________ 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.
