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 t4LErf5O016033 for ; Thu, 21 May 2015 10:53:42 -0400 Received: by qget53 with SMTP id t53so41267936qge.3 for ; Thu, 21 May 2015 07:53:37 -0700 (PDT) Message-ID: <555DF171.10805@quarksecurity.com> Date: Thu, 21 May 2015 10:53:37 -0400 From: Joshua Brindle MIME-Version: 1.0 To: William Roberts 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Cc: linux-security-module@vger.kernel.org, Stephen Smalley , "selinux@tycho.nsa.gov" , James Morris List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: William Roberts wrote: > On Wed, May 20, 2015 at 9:17 PM, 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. >> >> 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 >> > > This is exactly what I had in mind, just use m4 > Even outside of my analysis use case I think this is not a good idea. Consider the Android base policy defined gpu_op as a set of ioctls, and there were related rules for gpu users defined there. Then a device variant policy has additional gpu_op ioctl's. How does it add them? Does it have to re-add all of the related rules with the new ioctls? In the ioctl-attibute case the variant policy would just add its specific ioctls to gpu_op and everything would be taken care of. Then we just need to preserve the symbols for looking at policies and we'll all be happy, right? > >> 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. >> > > >