Re: Are the reference policy abstractions the right ones?

[Karl MacMillan <kmacmillan@mentalrootkit.com>]

On Tue, 2007-10-16 at 07:15 +1000, James Morris wrote:
> On Mon, 15 Oct 2007, Karl MacMillan wrote:
> 

[...]

> > > labeling rules, 
> > 
> > This one is not clear to me. Every time you inherit from a type_class
> > you are creating new types which, almost by definition, should have
> > separate labeling from parent types. When the labeling should be the
> > same you likely want to factor out the type.
> 
> The reason for it is twofold:
>  - allow binding of the class to OS objects
>  - allow the labeling rules to be modified via inheritance
> 
> So, someone wanting to customize their httpd would subclass the httpd 
> security object, which would also need a new name, and potentially 
> override the labeling rules (e.g. different paths to files).
> 

It seems that wanting to _not_ override the rules would only occur in
the case of a container (and even there I'm not certain that is true -
it seems safer to always state the labeling from outside of the
container). So the common case (and the only one possible today) is that
you would always override the rules.

> > > network policy,
> > 
> > Not certain what you mean here - isn't that just packet types?
> 
> Things like netfilter contexts, port labels etc. which can be collected 
> together into a class under this scheme.
> 

These are all handled as types, correct?

> > I agree with the general idea. The devil will be in the details. There
> > also isn't really a good container to reuse. Virtual machines are too
> > separate, we need something where there is the possibility of controlled
> > sharing. Hardened chroots / jails I guess or perhaps one of the other
> > light-weight containers.
> > 
> > Though this won't solve all problems, I do think that making it easy to
> > use containers is important.
> 
> I was thinking of allowing flexibility with the granularity of the class, 
> allowing it to be constructed in a way which matched the granularity at 
> which the admin is managing the system.  Containers are just one example, 
> where you might have a class composed of other classes, with the top level 
> being itself a container, bound to the OS container.
> 
> e.g. for a VM, you'd have a "vm" class containing "base_os" class and the 
> application class.  So, everything needed is packaged with the VM (or 
> whatever: RPM, tarball).  The admin would configure the security of the 
> overall system via a relatively simple config file which specifies 
> interactions between these encapsulating objects (in this case, vm-vm and 
> vm-host policy).
> 
> This allows the low-level policy to be hidden via encapsulation, and for 
> the admin to be able to think at a higher level in terms of how components 
> interact.
> 

I agree about the general point, but not your specific example. Do we
really want every VM to have a unique policy? That would force us to
always do label translation when talking over the network, adding
complexity rather than removing it.

Karl

> 
> - James


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.