Re: [RFC] Virtualization steps

[David Lang]

On Wed, 29 Mar 2006, Chris Wright wrote:

> * Eric W. Biederman (ebiederm@xxxxxxxxxxxx) wrote:
> > Chris Wright <chrisw@xxxxxxxxxxxx> writes:
> >
> > > * Sam Vilain (sam@xxxxxxxxxx) wrote:
> > > > extern struct security_operations *security_ops; in
> > > > include/linux/security.h is the global I refer to.
> > >
> > > OK, I figured that's what you meant.  The top-level ops are similar in
> > > nature to inode_ops in that there's not a real compelling reason to make
> > > them per process.  The process context is (usually) available, and more
> > > importantly, the object whose access is being mediated is readily
> > > available with its security label.
> > >
> > > > There is likely to be some contention there between the security folk
> > > > who probably won't like the idea that your security module can be
> > > > different for different processes, and the people who want to provide
> > > > access to security modules on the systems they want to host or consolidate.
> > >
> > > I think the current setup would work fine.  It's less likely that we'd
> > > want a separate security module for each container than simply policy
> > > that is container aware.
> >
> > I think what we really want are stacked security modules.
>
> I'm not convinced we need a new module for each container.  The module
> is a policy enforcement engine, so give it a container aware policy and
> you shouldn't need another module.

what if the people administering the container are different from the 
people administering the host?

in that case the people working in the container want to be able to 
implement and change their own policy, and the people working on the host 
don't want to have to implement changes to their main policy config (wtih 
all the auditing that would be involved with it) every time a container 
wants to change it's internal policy.

I can definantly see where a container aware policy on the master would be 
useful, but I can also see where the ability to nest seperate policies 
would be useful.

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