Re: object context records for Xen

[Joshua Brindle <method@manicmethod.com>]

Joshua Brindle wrote:
> Stephen Smalley wrote:
>> Hi,
>>
>> Xen needs its own object context (ocontext) records in the policy for
>> various resources (pirq, iomem, ioport, device), and has no need for the
>> Linux object context records other than initial SIDs. Thus, rather than
>> just add new OCON_ indices and waste space in both the Linux and Xen
>> policies, I'd like to be able to interpret OCON_ indices differently
>> depending on some other value in the policy that identifies the target
>> kernel (Linux, Xen, FreeBSD, Solaris, ...). Possible ways to identify
>> the target kernel within the policy image:
>>
>> - Use different policydb strings ("SE Linux", "Xen Flask", ...) in the
>> header. I already introduced support for at least one other policydb
>> string ("Flask") in policydb_read() in libsepol so that we didn't have
>> to use "SE Linux" as the string in the OpenSolaris FMAC policy files.
>> Each kernel would only need to support reading files with its own string
>> identifier and would reject all others. Only libsepol would support all
>> of them for reading and writing.
>>
>
> I am a fan of this. One question is how do you build policydb's with the
> correct string? libsemanage option? checkpolicy option? It seems like
> only checkpolicy would be able to build policies for other systems since
> it doesn't make sense to have the policy be 'managed'. OTOH maybe it
> does make sense to have them managed, if there is extra infrastructure
> to load policies into e.g., Xen (like load_xen_policy) from domain 0.
>
>> - Use the config flags in the header. We are presently only using 3
>> bits in the config field (MLS, reject_unknown, allow_unknown), so we can
>> easily use a bit for each target kernel. Not very general/scalable, but
>> it isn't clear that we need this for very many cases.
>>
>
> I don't think this is the purpose of the config flag. What if the
> destination systems have their own config flags?
>
>> - Introduce an entirely new field to the header to select the target
>> kernel. In which case it could just be an unsigned integer with defined
>> values for Linux, Solaris, Xen, FreeBSD, etc. This is the only one that
>> absolutely requires a new policy version (policy.25).
>>
>
> boo to bumping policydb versions if not necessary.
>

On this topic, do we foresee any target needing policydb changes that will 
diverge the version between targets? If so, how do we plan to handle that?

>> Other aspects of the policy might likewise get interpreted differently
>> based on the target kernel, such as policy capabilities (the current
>> ones are very Linux-specific).
>>
>> Then we'd have to decide how we want to drive selection of the target
>> kernel when building the policy; it could be an option to
>> checkpolicy/checkmodule (ala MLS and handle_unknown behavior) or it
>> could be an actual directive within the source policy configuration.
>>
>
> Ah, yes. If we were using modules to build policies for other systems
> would every module have to identify its platform? Is SELinux default?
> Will refpolicy ever be able to build policies for different targets?
>
> In the spirit of standard compilers this seems like a --target sort of
> thing rather than sticking it in the language.
>

Also, is it an error condition if there are ocon's unrelated to the target 
platform? Is it possible to create a general policy that may work on multiple 
platforms and therefore have a superset of the ocons for each possible platform?

--
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.