On Tue, 8 Jan 2013, Casey Schaufler wrote: > What I was hoping to say, and apparently didn't, is that people > are developing "total" solutions in user space, when some of the > work ought to be done in an LSM. Work that is appropriate to the > kernel is being done in user space. Often badly, because the > kernel provides too many mechanisms to circumvent user space > based access controls. People do stupid things all the time. How is this particular case our problem to fix? Do you have any concrete examples? > And before we get too far, distros are no longer the driving force > for Linux development. I suggest that "operating systems", including > ChromiumOS, Android and Tizen are every bit as important. Indeed. I was including these projects as "distros". > > What is the UID issue and how does LSM stacking address it? > > Android utilizes UIDs in a way that has often been referred to as > "hijacking". The UID mechanism supports much of what they want, > but clearly isn't complete. Now that Android is moving to multi-user > support they're hitting conflicts with their use of the UID > attribute. They really ought to be using an LSM that implements > the security policy they want rather than hacking around the > behavior of UID based controls. Right, so they implement an LSM to do what they need. What does this have to do with stacking? > > Also, are you saying that security mechanisms are inherently easier to > > configure if they're composed from a variety of distinct modules vs. a > > monolithic scheme? > > Nope. I'm saying that for specific use cases including but not limited to > telephones, TVs and surveillance networks it is simpler and more appropriate > to create the access control and security schemes that directly address > the needs than to attempt to squeeze them into corsets designed in the > 1990's. That may be true, but we do need at least one significant user to step up with concrete plans for deployment. -- James Morris <jmorris@xxxxxxxxx> -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
