> -----Original Message----- > From: Selinux [mailto:selinux-bounces@xxxxxxxxxxxxx] On Behalf Of Jeffrey > Vander Stoep > Sent: Friday, November 6, 2015 9:51 AM > To: Paul Moore <pmoore@xxxxxxxxxx>; SELinux <selinux@xxxxxxxxxxxxx> > Subject: Re: New SELinux userspace release supporting extended ioctl > permissions? > > > Applying ioctl whitelisting on GNU/Linux systems looks to me pretty > > hard to do though. Many drivers, and their ioctls to support. > > Agreed. > > On Android we use ioctl whitelisting only in a targeted manner. I think the same > approach could (should) be applied to GNU/Linux. > > The example that went out in the M release focused on restricting the leakage of > privacy sensitive information from socket ioctls. Apps are blocked from using > socket ioctls to access the wifi MAC address, wifi SSID and layer 2 encryption > protocol. I could see a similar policy applied to the GNU/Linux browser. Ioctl > policies on GPU access also seem practical albeit device specific. > > Constructing a comprehensive list of ioctls and the source/target/class sets that > require access does not strike me as practical. In many cases these ioctls are > already properly restricted via the ioctl permission. I think a good example of what could be targeted are perhaps video devices implementing The Video 4 Linux and V4L2 api's. Since those ioctl's are well documented, hopefully things adhere to them. However, based on my experience, there is the standard and then what people do, and they are not one in the same. > _______________________________________________ > 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. _______________________________________________ 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.
