From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id t4LENZxO013720 for ; Thu, 21 May 2015 10:23:36 -0400 Received: by qget53 with SMTP id t53so40563116qge.3 for ; Thu, 21 May 2015 07:23:10 -0700 (PDT) Message-ID: <555DEA4E.4000807@quarksecurity.com> Date: Thu, 21 May 2015 10:23:10 -0400 From: Joshua Brindle MIME-Version: 1.0 To: Paul Moore Subject: Re: [PATCH 0/2] selinux: add targeted whitelisting of ioctl commands. References: <1428616130-14570-1-git-send-email-jeffv@google.com> <1684020.b5Ioztp7mc@sifl> <555D3E20.7050907@quarksecurity.com> <555DDF2C.3010606@quarksecurity.com> <555DE8A4.2050000@quarksecurity.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: James Morris , linux-security-module@vger.kernel.org, "selinux@tycho.nsa.gov" , Stephen Smalley List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: Paul Moore wrote: > On Thu, May 21, 2015 at 10:16 AM, Joshua Brindle > wrote: >> Paul Moore wrote: >>> On Thu, May 21, 2015 at 9:35 AM, Joshua Brindle >>> 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.