I've often given thought to running two processes in this context, and using inter process communications( shared memory seemed the most attractive to me ). How I envisioned this though, is that you have one process running as root, that is the main "supervisor" part of the application. Then a regular user application that makes requests via whatever shared memory mechanism that get used.
I think the main benefit of an application of this sort is that there is kind of a partition between privileged commands, and non privileged users. With the ability of having very fine grained control. Anyway, I only bring this up because the last post kind of reminds me of what I mention above, and actually could be made to work as a "userland" driver. On Wed, Feb 10, 2016 at 4:02 PM, <ybeag...@rehut.com> wrote: > You might want think more about this then the peep hole approach. > > Rather then running things in userland and relying on user id isolation; a > better way is to write a kernel driver that exposes a very specific and > limited interface. GPIOs are directly toggling hardware which means there > are > more then thing simple "privileges" - > - Can the pins be reconfigured to conflict (i.e. BBB is an Output and the > thing connected is an output) and is the hardware tolerant of that or will > things die? > > - Is there anything bad that will happen if the pin floats (i.e. a normally > output pin is switched to an input)? Will it pickup noise and let things go > crazy? > > Just merely changing permissions can leave a dangling problem. > > On Monday, February 08, 2016 10:33:03 j...@forelight.com wrote: > > This is John, the guy with the question Drew to above on the Adafruit > > board. (Thanks Drew for starting this conversation here.) > > > > The problem is, this is part of a commercial application. My code will be > > reading and writing to the GPIOs and doing various things, communicating > > data to remote systems... I anticipate adding a fair bit of complexity. > I'd > > hate to make a bug that blew something important away or something like > > that. I am generally leery of unnecessary privilege escalation. > > > > So I could > > > > - sudo my entire application, which would be the same as running as root; > > - partition my application and have it invoke the code that interfaces > > directly to the GPIOs as sudo in some way (via shell?); > > - go by way of the PRUs; > > - change permissions; > > - some other way. > > > > I did have partial success changing the permissions on relevant files, > ala > > > > https://github.com/cnobile2012/RobotControl/tree/master/contrib > > > > which uses udev to set up permissions (not that I understand udev > either.) > > > > I call my success partial because I can get a test LED to turn on, but I > > can't get it to flash using PWM. > > > > Any ideas why that would be? > > > > On Sunday, February 7, 2016 at 10:00:01 AM UTC-6, Mike Bell wrote: > > > On 02/06/2016 12:51 AM, Brian Anderson wrote: > > > > > > > > > My comments are really to do with what I perceive as best practices on > how > > > one would approach building systems that are "security conscious". Of > > > course, "convenience" may direct us in different directions during > > > development. I am not sure what you are trying to imply by "safe" as > in > > > protecting the GPIOs from misuse. I don't actually see any way to > > > accomplish that. What I do think one can do is to be aware of security > > > considerations and not unnecessarily present an attack surface that can > > > compromise the entire system. > > > > > > > > > *Using sudo seems much less secure as it exposes the application to > being > > > > > >>> exploited for security flaws. And since the application is running as > > >>> root, > > >>> it has access to everything.* > > >> > > >> So, we have a device on a system that can potentially cause physical > > >> damage to external hardware when something like a wrong GPIO state is > > >> toggled, or such. How would sudo be less secure in this context? > > > > > > It wouldn't. And that is not my point. I am not talking about how to > > > protect the GPIOs from "bad behaved" programs that are "trusted" as > > > implied > > > by the fact that they are running as a normal user in the group that > has > > > access to those GPIOs. If an application is trusted (is a member of > the > > > appropriate group or for that matter can sudo), it is a hopeless task > to > > > protect the GPIOs from misuse. What I am trying to point out is that > > > running an app as "root" (sudo, set uid, whatever) exposes a security > > > attack vector...a vector that has access to _all_ system resources. I > > > would claim that it is an unnecessary exposure...from a security point > of > > > view. YMMV when it comes to "convenience". > > > > > >> In fact under certain conditions it would be less safe using groups. > > > > > > How would an application running at a non-root level using groups to > > > access protected resources be less "safe" than an application running > as > > > root using sudo? > > > > > >> Also, "root has access to everything" is wrong. Reread what I've > written > > >> above about running specific commands through sudo. > > > > > > Errr, an application running as root, by definition, has access to > _all_ > > > system resources. The fact that you are limiting just a single > > > application/user to run sudo doesn't limit the attack surface for that > > > application. If your root application is compromised in some way, then > > > the > > > entire system can be compromised. Running as a normal user does not > > > present the same attack surface...its much smaller and sandboxed by the > > > kernel. Running as root affords no protection enforcement by the > kernel. > > > > > > ba > > > > > >> On Fri, Feb 5, 2016 at 6:05 PM, Brian Anderson <b...@nwlink.com> > wrote: > > >>> Err, why? > > >>> > > >>> Groups are frequently used to restrict access to resources. Android > > >>> exploits groups for permissions and to sandbox applications. And the > > >>> kernel enforces access. > > >>> > > >>> Using sudo seems much less secure as it exposes the application to > being > > >>> exploited for security flaws. And since the application is running as > > >>> root, > > >>> it has access to everything. > > >>> > > >>> But maybe I'm missing something? > > >>> > > >>> ba > > >>> > > >>> Brian, > > > > > > This is a great summation of the issue! > > > > > > Mike > > -- > Hunyue Yau > http://www.hy-research.com/ > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
