All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Weber, Matthew L Collins" <Matthew.Weber@collins.com>
To: "selinux@vger.kernel.org" <selinux@vger.kernel.org>,
	"linux-security-module@vger.kernel.org" 
	<linux-security-module@vger.kernel.org>
Cc: "Graziano, David D Collins" <david.graziano@collins.com>
Subject: LSM policy options for new GPIO kernel driver interface
Date: Mon, 2 Aug 2021 17:08:14 +0000	[thread overview]
Message-ID: <CY1P110MB0102ED0206E9498C742F6DC0F2EF9@CY1P110MB0102.NAMP110.PROD.OUTLOOK.COM> (raw)

All,

Since the 5.10 kernel, the GPIO subsystem has migrated from a sysfs based GPIO export method [1] (everything is a file) to a character device[2] + library[3].  The new framework[2] provides users with signal debouncing and other features that benefit embedded products.  The legacy method[1] allowed fine policy control of who can export / set / get the GPIO state.  We have not found a similar security policy path with the new approach.  Has anyone brainstormed strategies for the new character device-based interface without adding a userspace broker to enforce another level of rules?  The ideal case would be to keep all the controls within the SELinux refpolicy such that testing can be all-inclusive.

I'd be interested in what people think, such that I can prepare a university research project submission for Fall 2021 to build a prototype. 

Best Regards,
--
Matt Weber

[1] https://www.kernel.org/doc/html/latest/driver-api/gpio/legacy.html#sysfs-interface-for-userspace-optional
[2] https://www.kernel.org/doc/html/latest/driver-api/gpio/using-gpio.html
[3] https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/

             reply	other threads:[~2021-08-02 17:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-02 17:08 Weber, Matthew L Collins [this message]
2021-08-03 17:22 ` LSM policy options for new GPIO kernel driver interface Dominick Grift
2021-08-03 18:11   ` [External] " Weber, Matthew L Collins
2021-08-04 14:02     ` Stephen Smalley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CY1P110MB0102ED0206E9498C742F6DC0F2EF9@CY1P110MB0102.NAMP110.PROD.OUTLOOK.COM \
    --to=matthew.weber@collins.com \
    --cc=david.graziano@collins.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=selinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.