lkml.org 
[lkml]   [2006]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Virtualization steps
    Quoting Stephen Smalley (sds@tycho.nsa.gov):
    > On Thu, 2006-03-30 at 08:32 -0600, Serge E. Hallyn wrote:
    > > Frankly I thought, and am still not unconvinced, that containers owned
    > > by someone other than the system owner would/should never want to load
    > > their own LSMs, so that this wasn't a problem. Isolation, as Chris has
    > > mentioned, would be taken care of by the very nature of namespaces.
    > >
    > > There are of course two alternatives... First, we might want to allow the
    > > machine admin to insert per-container/per-namespace LSMs. To support
    > > this case, we would need a way for the admin to tag a container some way
    > > identifying it as being subject to a particular set of security_ops.
    > >
    > > Second, we might want container admins to insert LSMs. In addition to
    > > a straightforward way of tagging subjects/objects with their container,
    > > we'd need to implement at least permissions for "may insert global LSM",
    > > "may insert container LSM", and "may not insert any LSM." This might be
    > > sufficient if we trust userspace to always create full containers.
    > > Otherwise we might want to support meta-policy along the lines of "may
    > > authorize ptrace and mount hooks only", or even "not subject to the
    > > global inode_permission hook, and may create its own." (yuck)
    > >
    > > But so much of this depends on how the namespaces/containers end up
    > > being implemented...
    >
    > FWIW, SELinux now has a notion of a type hierarchy in its policy, so the
    > root admin can carve out a portion of the policy space and allow less
    > privileged admins to then define sub-types that are strictly constrained
    > by what was allowed to the parent type by the root admin. This is
    > handled in userspace, with the policy mediation performed by a userspace
    > agent (daemon, policy management server), which then becomes the focal
    > point for all policy loading.

    Yes, my first response (which I cancelled) mentioned this as a possible
    solution.

    The global admin could assign certain max privileges to 'container_b'.
    The admin in container_b could create container_b.root_t,
    container_b.user_t, etc, which would be limited by the container_b
    max perms.

    Presumably the policy daemon, running in container 0, could accept input
    from a socket from container 2, labeled appropriately automatically
    ensuring that all types created by the policy in container 2 are
    prefixed with container_b, and doing the obvious restrictions.

    Or something like that :)

    -serge
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-03-30 18:18    [W:2.434 / U:0.216 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site