Paul Moore wrote:
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.
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.
_______________________________________________
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.
