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