object context records for Xen

object context records for Xen

[Stephen Smalley]

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.

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

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

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.

Thoughts?

-- 
Stephen Smalley
National Security Agency


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

Re: object context records for Xen

[Joshua Brindle]

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.

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

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

Re: object context records for Xen

[Joshua Brindle]

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.

Re: object context records for Xen

[Stephen Smalley]

On Mon, 2009-08-24 at 10:53 -0400, 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.

I think checkpolicy option in the short term.  In the longer term, I
think we'll want a per-store libsemanage option (not just global like
the current semanage.conf ones), so that we can use managed policy for
both the dom0 SELinux policy and the Xen policy. 

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

checkpolicy option and potentially libsemanage config option is fine
with me.

On a separate but related topic, we also want to introduce a separate
Xen interface for adding/removing/replacing ocontext entries without
having to do a full policy reload.  That might also be useful to have in
SELinux via a new selinuxfs interface.
  
-- 
Stephen Smalley
National Security Agency


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

Re: object context records for Xen

[Stephen Smalley]

On Mon, 2009-08-24 at 11:05 -0400, Joshua Brindle wrote:
> 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?

I don't think so - we plan to keep them in sync in terms of versions.

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

I would plan to have checkpolicy reject invalid ocons for the specified
target platform, much as it rejects mls statements (or requires them)
depending on the MLS flag.

There really isn't any sharing possible between the Xen policy and the
Linux policy, given the significantly different resources and operations
(thus classes and permissions), so I don't think it would be useful to
support a unified policy.

In the case of Linux, Solaris, and FreeBSD, it isn't clear that they
actually need distinct ocontext records since they do happen to share
the same Unix abstractions for the most part.

-- 
Stephen Smalley
National Security Agency


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

Re: object context records for Xen

[Joshua Brindle]

Stephen Smalley wrote:
> On Mon, 2009-08-24 at 11:05 -0400, Joshua Brindle wrote:
>> Joshua Brindle wrote:
>>> Stephen Smalley wrote:
<snip>>>>
>> 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?
>
> I would plan to have checkpolicy reject invalid ocons for the specified
> target platform, much as it rejects mls statements (or requires them)
> depending on the MLS flag.
>

In retrospect I'm not sure it was a great idea to make it reject mls statements 
rather than just ignoring them :).

> There really isn't any sharing possible between the Xen policy and the
> Linux policy, given the significantly different resources and operations
> (thus classes and permissions), so I don't think it would be useful to
> support a unified policy.
>
> In the case of Linux, Solaris, and FreeBSD, it isn't clear that they
> actually need distinct ocontext records since they do happen to share
> the same Unix abstractions for the most part.
>

So even if they had same/similar policies they'd have to be rebuilt with a new 
--target? Would each have ocon sets that just happen to be the same?

The massive amount of branching in the current reader/writer is fairly 
discouraging, I hope we can do this in a flexible but straightforward way.

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

Re: object context records for Xen

[Stephen Smalley]

On Mon, 2009-08-24 at 11:20 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Mon, 2009-08-24 at 11:05 -0400, Joshua Brindle wrote:
> >> Joshua Brindle wrote:
> >>> Stephen Smalley wrote:
> <snip>>>>
> >> 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?
> >
> > I would plan to have checkpolicy reject invalid ocons for the specified
> > target platform, much as it rejects mls statements (or requires them)
> > depending on the MLS flag.
> >
> 
> In retrospect I'm not sure it was a great idea to make it reject mls statements 
> rather than just ignoring them :).

This way the user gets an error that the source configuration that was
specified won't be honored in the generated policy.  I think you'd at
least want a warning, and we know what usually happens to warning
messages (i.e. they get silenced).

> > There really isn't any sharing possible between the Xen policy and the
> > Linux policy, given the significantly different resources and operations
> > (thus classes and permissions), so I don't think it would be useful to
> > support a unified policy.
> >
> > In the case of Linux, Solaris, and FreeBSD, it isn't clear that they
> > actually need distinct ocontext records since they do happen to share
> > the same Unix abstractions for the most part.
> >
> 
> So even if they had same/similar policies they'd have to be rebuilt with a new 
> --target? Would each have ocon sets that just happen to be the same?
> 
> The massive amount of branching in the current reader/writer is fairly 
> discouraging, I hope we can do this in a flexible but straightforward way.

The branching only needs to happen for ocontext records that differ
between the target platforms.  So for Xen, it would disable all of the
Linux ones except for initial SIDs and add its own set.  For Solaris and
FreeBSD, the ones that are in common could always be enabled and only
the divergent ones (if any) would need to be branched based on the
target.

Realistically though I don't think we can share the same/similar
policies among them regardless.  The SEBSD experience suggested that
only the high level form of application policies could be shared but
much of the core system policy had to be custom and of course the
classes/access vectors will differ at least somewhat for each platform.
So the apache.te file might be the same but the raw statements fed into
checkpolicy/checkmodule and the resulting output will differ.

-- 
Stephen Smalley
National Security Agency


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