Re: [RFC] Virtualization steps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 29 Mar 2006, Chris Wright wrote:


* Eric W. Biederman ([email protected]) wrote:
Chris Wright <[email protected]> writes:

* Sam Vilain ([email protected]) 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux