[lkml]   [2013]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v12 0/9] LSM: Multiple concurrent LSMs
    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

     \ /
      Last update: 2013-01-09 15:01    [W:8.545 / U:1.564 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site