How to cross install policy store?

How to cross install policy store?

[TaurusHarry]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]


HI SELinux experts,

I am trying to use SELinux on an ARM board with limited RAM <=128m, if I use semodule tool to create policy store on the target it will be terminated by kernel OOM killer. Normally semodule tool will install the policy store on the host, is it possible to cross-install the policy store to the target rootfs image on the host?

Thank you very much!

Best regards,
Harry
 		 	   		  
_________________________________________________________________
想知道明天天气如何？必应告诉你！
http://cn.bing.com/search?q=%E5%A4%A9%E6%B0%94%E9%A2%84%E6%8A%A5&form=MICHJ2

[-- Attachment #2: Type: text/html, Size: 759 bytes --]

Re: How to cross install policy store?

[waqar afridi]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

Try to create Virtual Memory...

2010/5/18 TaurusHarry <harrytaurus2002@hotmail.com>

>  HI SELinux experts,
>
> I am trying to use SELinux on an ARM board with limited RAM <=128m, if I
> use semodule tool to create policy store on the target it will be terminated
> by kernel OOM killer. Normally semodule tool will install the policy store
> on the host, is it possible to cross-install the policy store to the target
> rootfs image on the host?
>
> Thank you very much!
>
> Best regards,
> Harry
>
> ------------------------------
> 搜索本应是彩色的,快来体验新一代搜索引擎-必应,精美图片每天换哦! 立即试用！ <http://cn.bing.com/?form=CRMADS>
>



-- 
Waqar Afridi

Android Developer
SERG IM|Sciences
waqarafridi.wordpress.com
http://imsciences.edu.pk/serg/?page_id=376

[-- Attachment #2: Type: text/html, Size: 1249 bytes --]

Re: How to cross install policy store?

[Shaz]

2010/5/18 waqar afridi <afridi.waqar@gmail.com>:
> Try to create Virtual Memory...
>
> 2010/5/18 TaurusHarry <harrytaurus2002@hotmail.com>
>>
>> HI SELinux experts,
>>
>> I am trying to use SELinux on an ARM board with limited RAM <=128m, if I
>> use semodule tool to create policy store on the target it will be terminated
>> by kernel OOM killer. Normally semodule tool will install the policy store
>> on the host, is it possible to cross-install the policy store to the target
>> rootfs image on the host?

We are doing the same but cross compiled the libraries and building
the policy natively on the device/board. Memory is a big problem. We
moved ahead with creating swap memory but still lots of issues.

Now we are trying to reduce the modules to be built. Still having
problems .... policy.kern does not exist ... weird stuff! We are
planning to document our efforts once we go through the policy build
and runtime tests.

-- 
Shaz

--
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: How to cross install policy store?

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/18/2010 03:07 AM, TaurusHarry wrote:
> 
> HI SELinux experts,
> 
> I am trying to use SELinux on an ARM board with limited RAM <=128m, if I use semodule tool to create policy store on the target it will be terminated by kernel OOM killer. Normally semodule tool will install the policy store on the host, is it possible to cross-install the policy store to the target rootfs image on the host?
> 
> Thank you very much!
> 
> Best regards,
> Harry
>  		 	   		  
> _________________________________________________________________
> 想知道明天天气如何？必应告诉你！
> http://cn.bing.com/search?q=%E5%A4%A9%E6%B0%94%E9%A2%84%E6%8A%A5&form=MICHJ2
You should be able to build the policy on a different maching and just
install it on the ARM box.

Also you can add these flags to /etc/selinux/semanage.conf

    * Enable configuration of bzip behavior from Stephen Smalley.
      bzip-blocksize=0 to disable compression and decompression support.
      bzip-blocksize=1..9 to set the blocksize for compression.
      bzip-small=true to reduce memory usage for decompression
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkvyilkACgkQrlYvE4MpobMRogCeMIWdWC5XYKDWLM6mfeSD/aUC
Bt0AoIsnS4dWW/iLVe0vBV+QKY1OI86o
=5Y3x
-----END PGP SIGNATURE-----

--
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: How to cross install policy store?

[Shaz]

2010/5/18 Daniel J Walsh <dwalsh@redhat.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/18/2010 03:07 AM, TaurusHarry wrote:
>>
>> HI SELinux experts,
>>
>> I am trying to use SELinux on an ARM board with limited RAM <=128m, if I use semodule tool to create policy store on the target it will be terminated by kernel OOM killer. Normally semodule tool will install the policy store on the host, is it possible to cross-install the policy store to the target rootfs image on the host?
>>
>> Thank you very much!
>>
>> Best regards,
>> Harry
>>
>> _________________________________________________________________
>> 想知道明天天气如何？必应告诉你！
>> http://cn.bing.com/search?q=%E5%A4%A9%E6%B0%94%E9%A2%84%E6%8A%A5&form=MICHJ2
> You should be able to build the policy on a different maching and just
> install it on the ARM box.

You mean it does not require to be cross compiled on a different
machine for the target and you can just load it! I cannot agree to
this until I try it. If it means that you cross compile it on a
different machine and then load it on target seems to be what you mean
.... the policy as far as I understand is suppose to be binary when it
builds ...

Today we got modular reference policy installed and loaded
successfully after a weeks effort and crashing my special (most
stable) build system. Setfiles was giving us problem. Tomorrow we do
testing.

-- 
Shaz


--
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: How to cross install policy store?

[Stephen Smalley]

On Tue, 2010-05-18 at 18:17 +0500, Shaz wrote:
> 2010/5/18 Daniel J Walsh <dwalsh@redhat.com>:
> > You should be able to build the policy on a different maching and just
> > install it on the ARM box.
> 
> You mean it does not require to be cross compiled on a different
> machine for the target and you can just load it! I cannot agree to
> this until I try it. If it means that you cross compile it on a
> different machine and then load it on target seems to be what you mean
> .... the policy as far as I understand is suppose to be binary when it
> builds ...

The policy is in a binary format, but the binary format is
architecture-independent.  policy is a .noarch package in Fedora.
Policy is always written little endian and converted to cpu order at
load time.

> Today we got modular reference policy installed and loaded
> successfully after a weeks effort and crashing my special (most
> stable) build system. Setfiles was giving us problem. Tomorrow we do
> testing.

-- 
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: How to cross install policy store?

[Stephen Smalley]

On Tue, 2010-05-18 at 09:20 -0400, Stephen Smalley wrote:
> On Tue, 2010-05-18 at 18:17 +0500, Shaz wrote:
> > 2010/5/18 Daniel J Walsh <dwalsh@redhat.com>:
> > > You should be able to build the policy on a different maching and just
> > > install it on the ARM box.
> > 
> > You mean it does not require to be cross compiled on a different
> > machine for the target and you can just load it! I cannot agree to
> > this until I try it. If it means that you cross compile it on a
> > different machine and then load it on target seems to be what you mean
> > .... the policy as far as I understand is suppose to be binary when it
> > builds ...
> 
> The policy is in a binary format, but the binary format is
> architecture-independent.  policy is a .noarch package in Fedora.
> Policy is always written little endian and converted to cpu order at
> load time.

BTW, as Dan noted, if I were building policy for such a system, I would
do it entirely on the build/development host and then only deploy the
generated policy files to the target system.  Then you don't even
need /etc/selinux/$SELINUXTYPE/modules/* or /usr/share/selinux/* on the
target system, nor do you need libsemanage, semodule, or semanage on it.
When you want to make a change to policy, you do it on the
build/development host, regenerate the policy, and then distribute the
generated policy files to the target systems using your favorite
distribution mechanism.

I'd also consider just building the policy monolithically for such a
system rather than modularly.  Then you can easily just install directly
to the target image without having to touch /etc/selinux on the
build/devel host.

Lastly, I'm not sure I'd start from refpolicy.  It depends on how close
the target environment matches a typical Linux distribution.  If it is
radically different in the userspace and the filesystem layout (e.g.
Android), I'd be tempted to instead start from a minimal policy (e.g.
one generated via scripts/selinux/mdp in the kernel source tree or a
hand-crafted one) and work my way up to construct a working system.

-- 
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: How to cross install policy store?

[Shaz]

>> The policy is in a binary format, but the binary format is
>> architecture-independent.  policy is a .noarch package in Fedora.
>> Policy is always written little endian and converted to cpu order at
>> load time.

I still don't get it.

> BTW, as Dan noted, if I were building policy for such a system, I would
> do it entirely on the build/development host and then only deploy the
> generated policy files to the target system.  Then you don't even
> need /etc/selinux/$SELINUXTYPE/modules/* or /usr/share/selinux/* on the
> target system, nor do you need libsemanage, semodule, or semanage on it.
> When you want to make a change to policy, you do it on the
> build/development host, regenerate the policy, and then distribute the
> generated policy files to the target systems using your favorite
> distribution mechanism.

Indeed the libs you listed are not required on target even for our
current usecase but we have a usecase for it in mind so trying to
figure out all the technical stuff before hand and in one go because
it's tough to change mental set over and over again. I deal with many
things all at the same time. We will have problem of performance but
after all it starts with experiments :) And performance for embedded
systems is improving at a good pace.

> I'd also consider just building the policy monolithically for such a
> system rather than modularly.  Then you can easily just install directly
> to the target image without having to touch /etc/selinux on the
> build/devel host.

The usecase as I mentioned earlier is better this way but our future
usecases need modular policy this and much more then booleans etc.

> Lastly, I'm not sure I'd start from refpolicy.  It depends on how close
> the target environment matches a typical Linux distribution.  If it is
> radically different in the userspace and the filesystem layout (e.g.
> Android), I'd be tempted to instead start from a minimal policy (e.g.
> one generated via scripts/selinux/mdp in the kernel source tree or a
> hand-crafted one) and work my way up to construct a working system.

We work on debian derivatives and I was thinking to look at the
reference policy sister policy for ubuntu to try. I was also thinking
to try the selinux-notebook sources but I am still not sure .... still
too many priority issues before that.

> --
> Stephen Smalley
> National Security Agency
>
>

Anyways, thanks for the tips Steven. We will need your guidance with
more sophisticated issues all along.

-- 
Shaz


--
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: How to cross install policy store?

[Stephen Smalley]

On Tue, 2010-05-18 at 22:40 +0500, Shaz wrote:
> >> The policy is in a binary format, but the binary format is
> >> architecture-independent.  policy is a .noarch package in Fedora.
> >> Policy is always written little endian and converted to cpu order at
> >> load time.
> 
> I still don't get it.

Perhaps you are confusing binary format with executable code.
Many formats are binary (not text) but are portable across
architectures. Consider zip files, on-disk filesystem formats, IP
packets, etc.  It is just a matter of having a standard representation.
The policy data structures are serialized as a sequence of fixed width,
little endian integers when written.  You can compile policy on sparc64
and use it on x86_32 or vice versa.  You'll get the same result.

> > BTW, as Dan noted, if I were building policy for such a system, I would
> > do it entirely on the build/development host and then only deploy the
> > generated policy files to the target system.  Then you don't even
> > need /etc/selinux/$SELINUXTYPE/modules/* or /usr/share/selinux/* on the
> > target system, nor do you need libsemanage, semodule, or semanage on it.
> > When you want to make a change to policy, you do it on the
> > build/development host, regenerate the policy, and then distribute the
> > generated policy files to the target systems using your favorite
> > distribution mechanism.
> 
> Indeed the libs you listed are not required on target even for our
> current usecase but we have a usecase for it in mind so trying to
> figure out all the technical stuff before hand and in one go because
> it's tough to change mental set over and over again. I deal with many
> things all at the same time. We will have problem of performance but
> after all it starts with experiments :) And performance for embedded
> systems is improving at a good pace.
>
> > I'd also consider just building the policy monolithically for such a
> > system rather than modularly.  Then you can easily just install directly
> > to the target image without having to touch /etc/selinux on the
> > build/devel host.
> 
> The usecase as I mentioned earlier is better this way but our future
> usecases need modular policy this and much more then booleans etc.

Sure, it depends on your use case.  But if you find yourself running
afoul of memory or disk space constraints on the target system (which
seem common for such embedded systems), then building policy (whether
modularly or monolithically) on a build/devel host and only distributing
the final generated policy to the target systems will certainly help
with such constraints.  If on the other hand you have adequate memory
and disk space on the target system but are limited in your bandwidth
and need to be able to push policy updates as modules rather than as
complete regenerated policy files, then retaining the modular support on
the target system may be a win.

> > Lastly, I'm not sure I'd start from refpolicy.  It depends on how close
> > the target environment matches a typical Linux distribution.  If it is
> > radically different in the userspace and the filesystem layout (e.g.
> > Android), I'd be tempted to instead start from a minimal policy (e.g.
> > one generated via scripts/selinux/mdp in the kernel source tree or a
> > hand-crafted one) and work my way up to construct a working system.
> 
> We work on debian derivatives and I was thinking to look at the
> reference policy sister policy for ubuntu to try. I was also thinking
> to try the selinux-notebook sources but I am still not sure .... still
> too many priority issues before that.

Ok, just keep in mind that you don't necessarily have to use refpolicy
or one of its derivatives if it proves to be a poor match for your
target environment.

-- 
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: How to cross install policy store?

[TaurusHarry]

[-- Attachment #1: Type: text/plain, Size: 5112 bytes --]




> Subject: Re: How to cross install policy store?
> From: sds@tycho.nsa.gov
> To: shazalive@gmail.com
> CC: dwalsh@redhat.com; harrytaurus2002@hotmail.com; selinux@tycho.nsa.gov
> Date: Tue, 18 May 2010 15:22:26 -0400
> 
> On Tue, 2010-05-18 at 22:40 +0500, Shaz wrote:
> > >> The policy is in a binary format, but the binary format is
> > >> architecture-independent.  policy is a .noarch package in Fedora.
> > >> Policy is always written little endian and converted to cpu order at
> > >> load time.
> > 
> > I still don't get it.
> 
> Perhaps you are confusing binary format with executable code.
> Many formats are binary (not text) but are portable across
> architectures. Consider zip files, on-disk filesystem formats, IP
> packets, etc.  It is just a matter of having a standard representation.
> The policy data structures are serialized as a sequence of fixed width,
> little endian integers when written.  You can compile policy on sparc64
> and use it on x86_32 or vice versa.  You'll get the same result.

Hi Stephen,

Many thanks for your kind help!

It's very true that both SELInux policy and policy store are arch-independent. It takes about 70 minutes to build the policy store from scratch on my embedded target, but I could copy and use the host policy store on the target, only that it will take 20 minutes each time to change SELinux attribute on the fly by the semanage tool, so I think I'd better save all the trouble by committing the changes to SELInux source code on the host instead.

Thanks again!
Harry


> 
> > > BTW, as Dan noted, if I were building policy for such a system, I would
> > > do it entirely on the build/development host and then only deploy the
> > > generated policy files to the target system.  Then you don't even
> > > need /etc/selinux/$SELINUXTYPE/modules/* or /usr/share/selinux/* on the
> > > target system, nor do you need libsemanage, semodule, or semanage on it.
> > > When you want to make a change to policy, you do it on the
> > > build/development host, regenerate the policy, and then distribute the
> > > generated policy files to the target systems using your favorite
> > > distribution mechanism.
> > 
> > Indeed the libs you listed are not required on target even for our
> > current usecase but we have a usecase for it in mind so trying to
> > figure out all the technical stuff before hand and in one go because
> > it's tough to change mental set over and over again. I deal with many
> > things all at the same time. We will have problem of performance but
> > after all it starts with experiments :) And performance for embedded
> > systems is improving at a good pace.
> >
> > > I'd also consider just building the policy monolithically for such a
> > > system rather than modularly.  Then you can easily just install directly
> > > to the target image without having to touch /etc/selinux on the
> > > build/devel host.
> > 
> > The usecase as I mentioned earlier is better this way but our future
> > usecases need modular policy this and much more then booleans etc.
> 
> Sure, it depends on your use case.  But if you find yourself running
> afoul of memory or disk space constraints on the target system (which
> seem common for such embedded systems), then building policy (whether
> modularly or monolithically) on a build/devel host and only distributing
> the final generated policy to the target systems will certainly help
> with such constraints.  If on the other hand you have adequate memory
> and disk space on the target system but are limited in your bandwidth
> and need to be able to push policy updates as modules rather than as
> complete regenerated policy files, then retaining the modular support on
> the target system may be a win.
> 
> > > Lastly, I'm not sure I'd start from refpolicy.  It depends on how close
> > > the target environment matches a typical Linux distribution.  If it is
> > > radically different in the userspace and the filesystem layout (e.g.
> > > Android), I'd be tempted to instead start from a minimal policy (e.g.
> > > one generated via scripts/selinux/mdp in the kernel source tree or a
> > > hand-crafted one) and work my way up to construct a working system.
> > 
> > We work on debian derivatives and I was thinking to look at the
> > reference policy sister policy for ubuntu to try. I was also thinking
> > to try the selinux-notebook sources but I am still not sure .... still
> > too many priority issues before that.
> 
> Ok, just keep in mind that you don't necessarily have to use refpolicy
> or one of its derivatives if it proves to be a poor match for your
> target environment.
> 
> -- 
> 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.
 		 	   		  
_________________________________________________________________
一张照片的自白――Windows Live照片的可爱视频介绍
http://windowslivesky.spaces.live.com/blog/cns!5892B6048E2498BD!889.entry

[-- Attachment #2: Type: text/html, Size: 5997 bytes --]

Re: How to cross install policy store?

[Shaz]

> It's very true that both SELInux policy and policy store are
> arch-independent. It takes about 70 minutes to build the policy store from
> scratch on my embedded target, but I could copy and use the host policy
> store on the target, only that it will take 20 minutes each time to change
> SELinux attribute on the fly by the semanage tool, so I think I'd better
> save all the trouble by committing the changes to SELInux source code on the
> host instead.

Sounds interesting. Let me try it too.

-- 
Shaz

--
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: How to cross install policy store?

[Justin P. Mattock]

On 05/19/2010 03:04 AM, Shaz wrote:
>> It's very true that both SELInux policy and policy store are
>> arch-independent. It takes about 70 minutes to build the policy store from
>> scratch on my embedded target, but I could copy and use the host policy
>> store on the target, only that it will take 20 minutes each time to change
>> SELinux attribute on the fly by the semanage tool, so I think I'd better
>> save all the trouble by committing the changes to SELInux source code on the
>> host instead.
>
> Sounds interesting. Let me try it too.
>


yep.. I built a policy on x86_64
then copied it to all my other machines(i586)
(no problem), but things like libselinux
will probably be a different story.

Justin P. Mattock

--
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: How to cross install policy store?

[Stephen Smalley]

On Wed, 2010-05-19 at 06:21 -0700, Justin P. Mattock wrote:
> On 05/19/2010 03:04 AM, Shaz wrote:
> >> It's very true that both SELInux policy and policy store are
> >> arch-independent. It takes about 70 minutes to build the policy store from
> >> scratch on my embedded target, but I could copy and use the host policy
> >> store on the target, only that it will take 20 minutes each time to change
> >> SELinux attribute on the fly by the semanage tool, so I think I'd better
> >> save all the trouble by committing the changes to SELInux source code on the
> >> host instead.
> >
> > Sounds interesting. Let me try it too.
> >
> 
> 
> yep.. I built a policy on x86_64
> then copied it to all my other machines(i586)
> (no problem), but things like libselinux
> will probably be a different story.

Well, yes, because libselinux is executable code.  policy is just data.

-- 
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: How to cross install policy store?

[Justin P. Mattock]

On 05/19/2010 06:34 AM, Stephen Smalley wrote:
> On Wed, 2010-05-19 at 06:21 -0700, Justin P. Mattock wrote:
>> On 05/19/2010 03:04 AM, Shaz wrote:
>>>> It's very true that both SELInux policy and policy store are
>>>> arch-independent. It takes about 70 minutes to build the policy store from
>>>> scratch on my embedded target, but I could copy and use the host policy
>>>> store on the target, only that it will take 20 minutes each time to change
>>>> SELinux attribute on the fly by the semanage tool, so I think I'd better
>>>> save all the trouble by committing the changes to SELInux source code on the
>>>> host instead.
>>>
>>> Sounds interesting. Let me try it too.
>>>
>>
>>
>> yep.. I built a policy on x86_64
>> then copied it to all my other machines(i586)
>> (no problem), but things like libselinux
>> will probably be a different story.
>
> Well, yes, because libselinux is executable code.  policy is just data.
>


hmm.. I'm wondering if something could be modified
with monolithic policies and the whole policy
version thing i.g. build.conf:

# Policy version
# By default, checkpolicy will create the highest
# version policy it supports.  Setting this will
# override the version.  This only has an
# effect for monolithic policies.
#OUTPUT_POLICY = 18


Justin P. Mattock


--
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: How to cross install policy store?

[Stephen Smalley]

On Wed, 2010-05-19 at 07:18 -0700, Justin P. Mattock wrote:
> On 05/19/2010 06:34 AM, Stephen Smalley wrote:
> > On Wed, 2010-05-19 at 06:21 -0700, Justin P. Mattock wrote:
> >> On 05/19/2010 03:04 AM, Shaz wrote:
> >>>> It's very true that both SELInux policy and policy store are
> >>>> arch-independent. It takes about 70 minutes to build the policy store from
> >>>> scratch on my embedded target, but I could copy and use the host policy
> >>>> store on the target, only that it will take 20 minutes each time to change
> >>>> SELinux attribute on the fly by the semanage tool, so I think I'd better
> >>>> save all the trouble by committing the changes to SELInux source code on the
> >>>> host instead.
> >>>
> >>> Sounds interesting. Let me try it too.
> >>>
> >>
> >>
> >> yep.. I built a policy on x86_64
> >> then copied it to all my other machines(i586)
> >> (no problem), but things like libselinux
> >> will probably be a different story.
> >
> > Well, yes, because libselinux is executable code.  policy is just data.
> >
> 
> 
> hmm.. I'm wondering if something could be modified
> with monolithic policies and the whole policy
> version thing i.g. build.conf:
> 
> # Policy version
> # By default, checkpolicy will create the highest
> # version policy it supports.  Setting this will
> # override the version.  This only has an
> # effect for monolithic policies.
> #OUTPUT_POLICY = 18

I'm not sure what you're asking, but I did mention setting OUTPUT_POLICY
in build.conf or policy-version in semanage.conf to force generation of
an older version of policy when building on a host that supports a newer
policy version than the target system.

-- 
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: How to cross install policy store?

[Justin P. Mattock]

On 05/19/2010 07:39 AM, Stephen Smalley wrote:
> On Wed, 2010-05-19 at 07:18 -0700, Justin P. Mattock wrote:
>> On 05/19/2010 06:34 AM, Stephen Smalley wrote:
>>> On Wed, 2010-05-19 at 06:21 -0700, Justin P. Mattock wrote:
>>>> On 05/19/2010 03:04 AM, Shaz wrote:
>>>>>> It's very true that both SELInux policy and policy store are
>>>>>> arch-independent. It takes about 70 minutes to build the policy store from
>>>>>> scratch on my embedded target, but I could copy and use the host policy
>>>>>> store on the target, only that it will take 20 minutes each time to change
>>>>>> SELinux attribute on the fly by the semanage tool, so I think I'd better
>>>>>> save all the trouble by committing the changes to SELInux source code on the
>>>>>> host instead.
>>>>>
>>>>> Sounds interesting. Let me try it too.
>>>>>
>>>>
>>>>
>>>> yep.. I built a policy on x86_64
>>>> then copied it to all my other machines(i586)
>>>> (no problem), but things like libselinux
>>>> will probably be a different story.
>>>
>>> Well, yes, because libselinux is executable code.  policy is just data.
>>>
>>
>>
>> hmm.. I'm wondering if something could be modified
>> with monolithic policies and the whole policy
>> version thing i.g. build.conf:
>>
>> # Policy version
>> # By default, checkpolicy will create the highest
>> # version policy it supports.  Setting this will
>> # override the version.  This only has an
>> # effect for monolithic policies.
>> #OUTPUT_POLICY = 18
>
> I'm not sure what you're asking, but I did mention setting OUTPUT_POLICY
> in build.conf or policy-version in semanage.conf to force generation of
> an older version of policy when building on a host that supports a newer
> policy version than the target system.
>

I was just wondering if this mechanism is a bit ancient,
since it only applies to monolithic(that's all).

Justin P. Mattock

--
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: How to cross install policy store?

[Christopher J. PeBenito]

On Wed, 2010-05-19 at 09:01 -0700, Justin P. Mattock wrote:
> On 05/19/2010 07:39 AM, Stephen Smalley wrote:
> > On Wed, 2010-05-19 at 07:18 -0700, Justin P. Mattock wrote:
> >> On 05/19/2010 06:34 AM, Stephen Smalley wrote:
> >>> On Wed, 2010-05-19 at 06:21 -0700, Justin P. Mattock wrote:
> >>>> On 05/19/2010 03:04 AM, Shaz wrote:
> >>>>>> It's very true that both SELInux policy and policy store are
> >>>>>> arch-independent. It takes about 70 minutes to build the policy store from
> >>>>>> scratch on my embedded target, but I could copy and use the host policy
> >>>>>> store on the target, only that it will take 20 minutes each time to change
> >>>>>> SELinux attribute on the fly by the semanage tool, so I think I'd better
> >>>>>> save all the trouble by committing the changes to SELInux source code on the
> >>>>>> host instead.
> >>>>>
> >>>>> Sounds interesting. Let me try it too.
> >>>>>
> >>>>
> >>>>
> >>>> yep.. I built a policy on x86_64
> >>>> then copied it to all my other machines(i586)
> >>>> (no problem), but things like libselinux
> >>>> will probably be a different story.
> >>>
> >>> Well, yes, because libselinux is executable code.  policy is just data.
> >>>
> >>
> >>
> >> hmm.. I'm wondering if something could be modified
> >> with monolithic policies and the whole policy
> >> version thing i.g. build.conf:
> >>
> >> # Policy version
> >> # By default, checkpolicy will create the highest
> >> # version policy it supports.  Setting this will
> >> # override the version.  This only has an
> >> # effect for monolithic policies.
> >> #OUTPUT_POLICY = 18
> >
> > I'm not sure what you're asking, but I did mention setting OUTPUT_POLICY
> > in build.conf or policy-version in semanage.conf to force generation of
> > an older version of policy when building on a host that supports a newer
> > policy version than the target system.
> >
> 
> I was just wondering if this mechanism is a bit ancient,
> since it only applies to monolithic(that's all).

As long as the toolchain supports building monolithic policies and
optionally setting a specific policy version, I see no reason to remove
it.  I still do tests of monolithic refpolicy to ensure it builds.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com


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

audit_event list ;was Re: How to cross install policy store?

[Bryan Kropf]

[-- Attachment #1: Type: text/html, Size: 5378 bytes --]

Re: How to cross install policy store?

[Justin P. Mattock]

> As long as the toolchain supports building monolithic policies and
> optionally setting a specific policy version, I see no reason to remove
> it.  I still do tests of monolithic refpolicy to ensure it builds.
>

no.. wasn't wanting to remove, just querying
what might be modified with this

Justin P. Mattock

--
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: How to cross install policy store?

[Shaz]

On Wed, May 19, 2010 at 12:22 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>
> On Tue, 2010-05-18 at 22:40 +0500, Shaz wrote:
> > >> The policy is in a binary format, but the binary format is
> > >> architecture-independent.  policy is a .noarch package in Fedora.
> > >> Policy is always written little endian and converted to cpu order at
> > >> load time.
> >
> > I still don't get it.
>
> Perhaps you are confusing binary format with executable code.
> Many formats are binary (not text) but are portable across
> architectures. Consider zip files, on-disk filesystem formats, IP
> packets, etc.  It is just a matter of having a standard representation.
> The policy data structures are serialized as a sequence of fixed width,
> little endian integers when written.  You can compile policy on sparc64
> and use it on x86_32 or vice versa.  You'll get the same result.

This is much clearer to understand. Thanks.

> > > BTW, as Dan noted, if I were building policy for such a system, I would
> > > do it entirely on the build/development host and then only deploy the
> > > generated policy files to the target system.  Then you don't even
> > > need /etc/selinux/$SELINUXTYPE/modules/* or /usr/share/selinux/* on the
> > > target system, nor do you need libsemanage, semodule, or semanage on it.
> > > When you want to make a change to policy, you do it on the
> > > build/development host, regenerate the policy, and then distribute the
> > > generated policy files to the target systems using your favorite
> > > distribution mechanism.
> >
> > Indeed the libs you listed are not required on target even for our
> > current usecase but we have a usecase for it in mind so trying to
> > figure out all the technical stuff before hand and in one go because
> > it's tough to change mental set over and over again. I deal with many
> > things all at the same time. We will have problem of performance but
> > after all it starts with experiments :) And performance for embedded
> > systems is improving at a good pace.
> >
> > > I'd also consider just building the policy monolithically for such a
> > > system rather than modularly.  Then you can easily just install directly
> > > to the target image without having to touch /etc/selinux on the
> > > build/devel host.
> >
> > The usecase as I mentioned earlier is better this way but our future
> > usecases need modular policy this and much more then booleans etc.
>
> Sure, it depends on your use case.  But if you find yourself running
> afoul of memory or disk space constraints on the target system (which
> seem common for such embedded systems), then building policy (whether
> modularly or monolithically) on a build/devel host and only distributing
> the final generated policy to the target systems will certainly help
> with such constraints.  If on the other hand you have adequate memory
> and disk space on the target system but are limited in your bandwidth
> and need to be able to push policy updates as modules rather than as
> complete regenerated policy files, then retaining the modular support on
> the target system may be a win.

What if there is a difference of policy versions between the host and
target :) Even difference of selinux libs?

> > > Lastly, I'm not sure I'd start from refpolicy.  It depends on how close
> > > the target environment matches a typical Linux distribution.  If it is
> > > radically different in the userspace and the filesystem layout (e.g.
> > > Android), I'd be tempted to instead start from a minimal policy (e.g.
> > > one generated via scripts/selinux/mdp in the kernel source tree or a
> > > hand-crafted one) and work my way up to construct a working system.
> >
> > We work on debian derivatives and I was thinking to look at the
> > reference policy sister policy for ubuntu to try. I was also thinking
> > to try the selinux-notebook sources but I am still not sure .... still
> > too many priority issues before that.
>
> Ok, just keep in mind that you don't necessarily have to use refpolicy
> or one of its derivatives if it proves to be a poor match for your
> target environment.

Is'nt handcrafted too heavy a task instead of reducing the modules and
changing them a bit?

> --
> Stephen Smalley
> National Security Agency
>



--
Shaz


--
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: How to cross install policy store?

[Stephen Smalley]

On Wed, 2010-05-19 at 15:01 +0500, Shaz wrote:
> On Wed, May 19, 2010 at 12:22 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > Sure, it depends on your use case.  But if you find yourself running
> > afoul of memory or disk space constraints on the target system (which
> > seem common for such embedded systems), then building policy (whether
> > modularly or monolithically) on a build/devel host and only distributing
> > the final generated policy to the target systems will certainly help
> > with such constraints.  If on the other hand you have adequate memory
> > and disk space on the target system but are limited in your bandwidth
> > and need to be able to push policy updates as modules rather than as
> > complete regenerated policy files, then retaining the modular support on
> > the target system may be a win.
> 
> What if there is a difference of policy versions between the host and
> target :) Even difference of selinux libs?

Can you run the following on the target system:
$ cat /selinux/policyvers

And the following on the build host:
$ checkpolicy -V

The first command shows you the highest policy version that can be
understood by your kernel.  The kernel can also understand any lower
version, down to the first version ever supported by Linux 2.6.0
(version 15), as it provides full backward compatibility.

The second command shows you the policy version range that can be read
or written by your libraries and policy compiler.

Any policy version supported by the libraries on the target should also
be loadable on the target, even if the kernel only supports an older
version.  This is because the libraries will automatically downgrade the
policy file to the version supported by the kernel at policy load time
if necessary.  However, given the option, I would directly generate a
policy version that can be loaded by your kernel without requiring such
runtime downgrading in order to eliminate a potential cause of failure
at runtime and an extra in-memory copy of the policy during the
downgrade process.

If checkpolicy on the build host supports a newer version of policy than
the kernel on the target, then you can just force it to generate an
older version.  To specify an older version, you use the -c option to
checkpolicy, which is automatically used if you specify an
OUTPUT_POLICY= setting in build.conf for a monolithic policy build.  For
modular builds, you can specify a policy-version
in /etc/selinux/semanage.conf to force generation of an older policy
version, or you can run checkpolicy by hand to later convert the policy,
e.g.
checkpolicy -M -c 20 -b policy.24 -o policy.20
will take a policy.24 file and downgrade it to a policy.20 file for you.

If checkpolicy on the build host supports an older version of policy
than the kernel on the target, then you have two options:
1) Just generate the older policy version - the target will still be
able to load it due to the backward compatibility.  This is fine as long
as you don't actually need any of the features introduced in the newer
policy version. -or-
2) Install a private copy of a newer version of the selinux userspace on
the build host (not overwriting the ones the build host normally uses,
but e.g. under some other path; we sometimes do this via make
DESTDIR=/path), and use that private copy to build the policy for the
target.  That just requires setting up your LD_LIBRARY_PATH, PATH, and
similar variables when building policy for the target.  Then you can
generate newer policy versions on the build host for the target without
affecting anything else on the build host.

> > Ok, just keep in mind that you don't necessarily have to use refpolicy
> > or one of its derivatives if it proves to be a poor match for your
> > target environment.
> 
> Is'nt handcrafted too heavy a task instead of reducing the modules and
> changing them a bit?

It depends on how divergent your userspace environment, size
requirements, and goals are from the ones used for refpolicy.
Nakamura et al found it difficult to prune refpolicy for their embedded
SELinux work.

-- 
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: How to cross install policy store?

[Shaz]

>> What if there is a difference of policy versions between the host and
>> target :) Even difference of selinux libs?
>
> Can you run the following on the target system:
> $ cat /selinux/policyvers
>
> And the following on the build host:
> $ checkpolicy -V
>
> The first command shows you the highest policy version that can be
> understood by your kernel.  The kernel can also understand any lower
> version, down to the first version ever supported by Linux 2.6.0
> (version 15), as it provides full backward compatibility.
>
> The second command shows you the policy version range that can be read
> or written by your libraries and policy compiler.
>
> Any policy version supported by the libraries on the target should also
> be loadable on the target, even if the kernel only supports an older
> version.  This is because the libraries will automatically downgrade the
> policy file to the version supported by the kernel at policy load time
> if necessary.  However, given the option, I would directly generate a
> policy version that can be loaded by your kernel without requiring such
> runtime downgrading in order to eliminate a potential cause of failure
> at runtime and an extra in-memory copy of the policy during the
> downgrade process.
>
> If checkpolicy on the build host supports a newer version of policy than
> the kernel on the target, then you can just force it to generate an
> older version.  To specify an older version, you use the -c option to
> checkpolicy, which is automatically used if you specify an
> OUTPUT_POLICY= setting in build.conf for a monolithic policy build.  For
> modular builds, you can specify a policy-version
> in /etc/selinux/semanage.conf to force generation of an older policy
> version, or you can run checkpolicy by hand to later convert the policy,
> e.g.
> checkpolicy -M -c 20 -b policy.24 -o policy.20
> will take a policy.24 file and downgrade it to a policy.20 file for you.
>
> If checkpolicy on the build host supports an older version of policy
> than the kernel on the target, then you have two options:
> 1) Just generate the older policy version - the target will still be
> able to load it due to the backward compatibility.  This is fine as long
> as you don't actually need any of the features introduced in the newer
> policy version. -or-
> 2) Install a private copy of a newer version of the selinux userspace on
> the build host (not overwriting the ones the build host normally uses,
> but e.g. under some other path; we sometimes do this via make
> DESTDIR=/path), and use that private copy to build the policy for the
> target.  That just requires setting up your LD_LIBRARY_PATH, PATH, and
> similar variables when building policy for the target.  Then you can
> generate newer policy versions on the build host for the target without
> affecting anything else on the build host.

Very useful information. I have another question ... will a module
built on build host with one version of policy compatible to load with
another policy version running on the target?

> It depends on how divergent your userspace environment, size
> requirements, and goals are from the ones used for refpolicy.
> Nakamura et al found it difficult to prune refpolicy for their embedded
> SELinux work.

Can we have policy modules, interfaces and booleans without reference policy?


-- 
Shaz


--
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: How to cross install policy store?

[Stephen Smalley]

On Wed, 2010-05-19 at 19:03 +0500, Shaz wrote:
> >> What if there is a difference of policy versions between the host and
> >> target :) Even difference of selinux libs?
> >
> > Can you run the following on the target system:
> > $ cat /selinux/policyvers
> >
> > And the following on the build host:
> > $ checkpolicy -V
> >
> > The first command shows you the highest policy version that can be
> > understood by your kernel.  The kernel can also understand any lower
> > version, down to the first version ever supported by Linux 2.6.0
> > (version 15), as it provides full backward compatibility.
> >
> > The second command shows you the policy version range that can be read
> > or written by your libraries and policy compiler.
> >
> > Any policy version supported by the libraries on the target should also
> > be loadable on the target, even if the kernel only supports an older
> > version.  This is because the libraries will automatically downgrade the
> > policy file to the version supported by the kernel at policy load time
> > if necessary.  However, given the option, I would directly generate a
> > policy version that can be loaded by your kernel without requiring such
> > runtime downgrading in order to eliminate a potential cause of failure
> > at runtime and an extra in-memory copy of the policy during the
> > downgrade process.
> >
> > If checkpolicy on the build host supports a newer version of policy than
> > the kernel on the target, then you can just force it to generate an
> > older version.  To specify an older version, you use the -c option to
> > checkpolicy, which is automatically used if you specify an
> > OUTPUT_POLICY= setting in build.conf for a monolithic policy build.  For
> > modular builds, you can specify a policy-version
> > in /etc/selinux/semanage.conf to force generation of an older policy
> > version, or you can run checkpolicy by hand to later convert the policy,
> > e.g.
> > checkpolicy -M -c 20 -b policy.24 -o policy.20
> > will take a policy.24 file and downgrade it to a policy.20 file for you.
> >
> > If checkpolicy on the build host supports an older version of policy
> > than the kernel on the target, then you have two options:
> > 1) Just generate the older policy version - the target will still be
> > able to load it due to the backward compatibility.  This is fine as long
> > as you don't actually need any of the features introduced in the newer
> > policy version. -or-
> > 2) Install a private copy of a newer version of the selinux userspace on
> > the build host (not overwriting the ones the build host normally uses,
> > but e.g. under some other path; we sometimes do this via make
> > DESTDIR=/path), and use that private copy to build the policy for the
> > target.  That just requires setting up your LD_LIBRARY_PATH, PATH, and
> > similar variables when building policy for the target.  Then you can
> > generate newer policy versions on the build host for the target without
> > affecting anything else on the build host.
> 
> Very useful information. I have another question ... will a module
> built on build host with one version of policy compatible to load with
> another policy version running on the target?

Policy modules have their own versioning; you can see what module
versions are supported by your libraries and policy compiler via
checkmodule -V on both the build host and the target host.

If checkmodule on the build host supports a newer version of modules
than the libraries on the target host, then (just like the corresponding
case for kernel policy versions) you'd need to generate the older module
version for the target system.  While that should be supported already
by the libraries, I don't think we have a build.conf or a semanage.conf
setting today that would specify the output module version, and
checkmodule doesn't appear to support the -c switch.  So someone would
have to code up the support for doing that.  In the interim, I think
your only option for this case is to install a private copy of the same
selinux userspace as the target on the build host and use that to
compile your modules so that the versions will be compatible.

If checkmodule on the build host supports an older version of modules
than the libraries on the target host, you have two options as with the
corresponding case for kernel policy versions.  You can just generate
the older module version and use that on the target system (at a
possible cost in newer features in the newer module format), or you can
install a private copy of the selinux userspace from the target on the
build host and use that to generate the newer module version.

> > It depends on how divergent your userspace environment, size
> > requirements, and goals are from the ones used for refpolicy.
> > Nakamura et al found it difficult to prune refpolicy for their embedded
> > SELinux work.
> 
> Can we have policy modules, interfaces and booleans without reference policy?

Booleans are a policy primitive directly supported by the kernel.
Modules are an abstraction supported by the policy toolchain (selinux
userspace).  Interfaces are an abstraction supported by the refpolicy,
but they are implemented just via m4 macros.

So you can certainly use booleans and modules apart from refpolicy, and
whatever policy you create is free to define and use macros for
convenience (hence interfaces).

Reference policy is just a specific policy configuration and associated
build infrastructure.

-- 
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: How to cross install policy store?

[Shaz]

>> Very useful information. I have another question ... will a module
>> built on build host with one version of policy compatible to load with
>> another policy version running on the target?
>
> Policy modules have their own versioning; you can see what module
> versions are supported by your libraries and policy compiler via
> checkmodule -V on both the build host and the target host.
>
> If checkmodule on the build host supports a newer version of modules
> than the libraries on the target host, then (just like the corresponding
> case for kernel policy versions) you'd need to generate the older module
> version for the target system.  While that should be supported already
> by the libraries, I don't think we have a build.conf or a semanage.conf
> setting today that would specify the output module version, and
> checkmodule doesn't appear to support the -c switch.  So someone would
> have to code up the support for doing that.  In the interim, I think
> your only option for this case is to install a private copy of the same
> selinux userspace as the target on the build host and use that to
> compile your modules so that the versions will be compatible.

How can we deny the usefulness of building the module on the target at
this point? This is where my mind is stuck. I query the available
interfaces on target and send a policy that will build with those
interfaces using package manager and it's post and pre scripts for the
package in context. Are there any weaknesses here that I am
overlooking.

> If checkmodule on the build host supports an older version of modules
> than the libraries on the target host, you have two options as with the
> corresponding case for kernel policy versions.  You can just generate
> the older module version and use that on the target system (at a
> possible cost in newer features in the newer module format), or you can
> install a private copy of the selinux userspace from the target on the
> build host and use that to generate the newer module version.

>> Can we have policy modules, interfaces and booleans without reference policy?
>
> Booleans are a policy primitive directly supported by the kernel.
> Modules are an abstraction supported by the policy toolchain (selinux
> userspace).  Interfaces are an abstraction supported by the refpolicy,
> but they are implemented just via m4 macros.
>
> So you can certainly use booleans and modules apart from refpolicy, and
> whatever policy you create is free to define and use macros for
> convenience (hence interfaces).

Before I can learn m4 or something similar and get command over policy
writing I think experimenting with reference policy is suitable.

Performance is not an issue as such on our end.

> Reference policy is just a specific policy configuration and associated
> build infrastructure.


-- 
Shaz


--
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: How to cross install policy store?

[Stephen Smalley]

On Wed, 2010-05-19 at 20:27 +0500, Shaz wrote:
> >> Very useful information. I have another question ... will a module
> >> built on build host with one version of policy compatible to load with
> >> another policy version running on the target?
> >
> > Policy modules have their own versioning; you can see what module
> > versions are supported by your libraries and policy compiler via
> > checkmodule -V on both the build host and the target host.
> >
> > If checkmodule on the build host supports a newer version of modules
> > than the libraries on the target host, then (just like the corresponding
> > case for kernel policy versions) you'd need to generate the older module
> > version for the target system.  While that should be supported already
> > by the libraries, I don't think we have a build.conf or a semanage.conf
> > setting today that would specify the output module version, and
> > checkmodule doesn't appear to support the -c switch.  So someone would
> > have to code up the support for doing that.  In the interim, I think
> > your only option for this case is to install a private copy of the same
> > selinux userspace as the target on the build host and use that to
> > compile your modules so that the versions will be compatible.
> 
> How can we deny the usefulness of building the module on the target at
> this point? This is where my mind is stuck. I query the available
> interfaces on target and send a policy that will build with those
> interfaces using package manager and it's post and pre scripts for the
> package in context. Are there any weaknesses here that I am
> overlooking.

I simply answered your question about compatibility if you were to build
the modules on a build host and then ship them to the target system.
Remember that my proposal was to instead build the complete policy on
the build host and only ship the final generated policy to the target
system, thereby avoiding the need for libsemanage, semodule/semanage,
and the module store on the target system at all.  Then we don't care
about module version compatibility (no modules on the target), only
kernel policy version compatibility.

If you are going to require the target system to support modules, then
yes, you could just ship it the source text of the module and compile it
there as long as you are willing to require the target system to have
checkmodule and the policy interface headers installed.  In fact, that
is the current trend in selinux userspace development (look for Source
Policy Support and src-policy in the list archives), although I think
we're still a ways from making that transition.

> Before I can learn m4 or something similar and get command over policy
> writing I think experimenting with reference policy is suitable.

That's fine - I'm not trying to convince you to not use refpolicy, just
making sure you understand that you have other options if it doesn't fit
your goals.

> Performance is not an issue as such on our end.

-- 
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: How to cross install policy store?

[Shaz]

>> How can we deny the usefulness of building the module on the target at
>> this point? This is where my mind is stuck. I query the available
>> interfaces on target and send a policy that will build with those
>> interfaces using package manager and it's post and pre scripts for the
>> package in context. Are there any weaknesses here that I am
>> overlooking.
>
> I simply answered your question about compatibility if you were to build
> the modules on a build host and then ship them to the target system.
> Remember that my proposal was to instead build the complete policy on
> the build host and only ship the final generated policy to the target
> system, thereby avoiding the need for libsemanage, semodule/semanage,
> and the module store on the target system at all.  Then we don't care
> about module version compatibility (no modules on the target), only
> kernel policy version compatibility.
>
> If you are going to require the target system to support modules, then
> yes, you could just ship it the source text of the module and compile it
> there as long as you are willing to require the target system to have
> checkmodule and the policy interface headers installed.  In fact, that
> is the current trend in selinux userspace development (look for Source
> Policy Support and src-policy in the list archives), although I think
> we're still a ways from making that transition.
>
>> Before I can learn m4 or something similar and get command over policy
>> writing I think experimenting with reference policy is suitable.
>
> That's fine - I'm not trying to convince you to not use refpolicy, just
> making sure you understand that you have other options if it doesn't fit
> your goals.

Thank you Stephen. Reasoning with you makes me sure that I am on the
right track.


-- 
Shaz


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