From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id o4I77IWh030835 for ; Tue, 18 May 2010 03:07:18 -0400 Received: from bay0-omc3-s20.bay0.hotmail.com (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id o4I76aX8003880 for ; Tue, 18 May 2010 07:06:37 GMT Message-ID: Content-Type: multipart/alternative; boundary="_d50bf9ee-8b98-42e2-ad1f-58dec1e391fd_" From: TaurusHarry To: selinux-mailing-list Subject: How to cross install policy store? Date: Tue, 18 May 2010 07:07:16 +0000 MIME-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov --_d50bf9ee-8b98-42e2-ad1f-58dec1e391fd_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit 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 --_d50bf9ee-8b98-42e2-ad1f-58dec1e391fd_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit 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

搜索本应是彩色的,快来体验新一代搜索引擎-必应,精美图片每天换哦! 立即试用！ --_d50bf9ee-8b98-42e2-ad1f-58dec1e391fd_-- -- 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id o4I7cZ9J032263 for ; Tue, 18 May 2010 03:38:36 -0400 Received: from mail-qy0-f199.google.com (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id o4I7btX8017506 for ; Tue, 18 May 2010 07:37:55 GMT Received: by qyk37 with SMTP id 37so9327033qyk.22 for ; Tue, 18 May 2010 00:38:35 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: waqar afridi Date: Tue, 18 May 2010 12:38:15 +0500 Message-ID: Subject: Re: How to cross install policy store? To: TaurusHarry Cc: selinux-mailing-list Content-Type: multipart/alternative; boundary=00163630eda7ced47e0486d96d9a Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov --00163630eda7ced47e0486d96d9a Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Try to create Virtual Memory... 2010/5/18 TaurusHarry > HI SELinux experts, > > I am trying to use SELinux on an ARM board with limited RAM <=3D128m, if = I > use semodule tool to create policy store on the target it will be termina= ted > by kernel OOM killer. Normally semodule tool will install the policy stor= e > on the host, is it possible to cross-install the policy store to the targ= et > rootfs image on the host? > > Thank you very much! > > Best regards, > Harry > > ------------------------------ > =CB=D1=CB=F7=B1=BE=D3=A6=CA=C7=B2=CA=C9=AB=B5=C4,=BF=EC=C0=B4=CC=E5=D1=E9= =D0=C2=D2=BB=B4=FA=CB=D1=CB=F7=D2=FD=C7=E6-=B1=D8=D3=A6,=BE=AB=C3=C0=CD=BC= =C6=AC=C3=BF=CC=EC=BB=BB=C5=B6! =C1=A2=BC=B4=CA=D4=D3=C3=A3=A1 > --=20 Waqar Afridi Android Developer SERG IM|Sciences waqarafridi.wordpress.com http://imsciences.edu.pk/serg/?page_id=3D376 --00163630eda7ced47e0486d96d9a Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

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 <=3D128m, if I use semodule tool to create policy store on t= he target it will be terminated by kernel OOM killer. Normally semodule too= l will install the policy store on the host, is it possible to cross-instal= l the policy store to the target rootfs image on the host?

Thank you very much!

Best regards,
Harry

<= hr>=CB=D1=CB=F7=B1=BE=D3=A6=CA=C7=B2=CA=C9=AB=B5=C4,=BF=EC=C0=B4=CC=E5=D1= =E9=D0=C2=D2=BB=B4=FA=CB=D1=CB=F7=D2=FD=C7=E6-=B1=D8=D3=A6,=BE=AB=C3=C0=CD= =BC=C6=AC=C3=BF=CC=EC=BB=BB=C5=B6! =C1=A2=BC=B4=CA=D4=D3=C3=A3=A1

--
Waqar Afridi

And= roid Developer
SERG IM|Sciences
waqarafridi.wordpress.com
http://imsciences.edu.pk/serg/?page_id=3D376

--00163630eda7ced47e0486d96d9a-- -- 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id o4I92oCo004654 for ; Tue, 18 May 2010 05:02:50 -0400 Received: from mail-pv0-f181.google.com (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id o4I929ke013462 for ; Tue, 18 May 2010 09:02:10 GMT Received: by pvf33 with SMTP id 33so266194pvf.12 for ; Tue, 18 May 2010 02:02:49 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 18 May 2010 14:02:48 +0500 Message-ID: Subject: Re: How to cross install policy store? From: Shaz To: TaurusHarry , selinux-mailing-list Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 2010/5/18 waqar afridi : > Try to create Virtual Memory... > > 2010/5/18 TaurusHarry >> >> 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id o4ICdOdE017486 for ; Tue, 18 May 2010 08:39:24 -0400 Received: from mx1.redhat.com (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id o4ICcPTZ012155 for ; Tue, 18 May 2010 12:38:26 GMT Message-ID: <4BF28A59.402@redhat.com> Date: Tue, 18 May 2010 08:38:49 -0400 From: Daniel J Walsh MIME-Version: 1.0 To: TaurusHarry CC: selinux-mailing-list Subject: Re: How to cross install policy store? References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov -----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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id o4IDHQXi021418 for ; Tue, 18 May 2010 09:17:26 -0400 Received: from mail-pz0-f178.google.com (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id o4IDGhTZ027275 for ; Tue, 18 May 2010 13:16:43 GMT Received: by pzk8 with SMTP id 8so422998pzk.18 for ; Tue, 18 May 2010 06:17:20 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4BF28A59.402@redhat.com> References: <4BF28A59.402@redhat.com> Date: Tue, 18 May 2010 18:17:20 +0500 Message-ID: Subject: Re: How to cross install policy store? From: Shaz To: Daniel J Walsh Cc: TaurusHarry , selinux-mailing-list Content-Type: text/plain; charset=GB2312 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 2010/5/18 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. 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: How to cross install policy store? From: Stephen Smalley To: Shaz Cc: Daniel J Walsh , TaurusHarry , selinux-mailing-list In-Reply-To: References: <4BF28A59.402@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 18 May 2010 09:20:41 -0400 Message-ID: <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Tue, 2010-05-18 at 18:17 +0500, Shaz wrote: > 2010/5/18 Daniel J Walsh : > > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: How to cross install policy store? From: Stephen Smalley To: Shaz Cc: Daniel J Walsh , TaurusHarry , selinux-mailing-list In-Reply-To: <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> References: <4BF28A59.402@redhat.com> <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> Content-Type: text/plain; charset="UTF-8" Date: Tue, 18 May 2010 09:45:59 -0400 Message-ID: <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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 : > > > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> References: <4BF28A59.402@redhat.com> <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> Date: Tue, 18 May 2010 22:40:00 +0500 Message-ID: Subject: Re: How to cross install policy store? From: Shaz To: Stephen Smalley Cc: Daniel J Walsh , TaurusHarry , selinux-mailing-list Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov >> The policy is in a binary format, but the binary format is >> architecture-independent. 爌olicy 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. 燭hen 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. 燭hen 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. 營t depends on how close > the target environment matches a typical Linux distribution. 營f 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: How to cross install policy store? From: Stephen Smalley To: Shaz Cc: Daniel J Walsh , TaurusHarry , selinux-mailing-list In-Reply-To: References: <4BF28A59.402@redhat.com> <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> Content-Type: text/plain; charset="UTF-8" Date: Tue, 18 May 2010 15:22:26 -0400 Message-ID: <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Content-Type: multipart/alternative; boundary="_52085562-6d32-43a0-aff8-35ff4994407d_" From: TaurusHarry To: Stephen Smalley , CC: , selinux-mailing-list Subject: RE: How to cross install policy store? Date: Wed, 19 May 2010 09:39:35 +0000 In-Reply-To: <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> References: ,<4BF28A59.402@redhat.com>,,<1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil>,<1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil>,,<1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> MIME-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov --_52085562-6d32-43a0-aff8-35ff4994407d_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit > 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 --_52085562-6d32-43a0-aff8-35ff4994407d_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit

> 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 struct! ures 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/selinu x/$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 o! n 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.

使用Messenger保护盾2.0，支持多账号登录！现在就下载！ --_52085562-6d32-43a0-aff8-35ff4994407d_-- -- 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. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> References: <4BF28A59.402@redhat.com> <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> Date: Wed, 19 May 2010 15:01:36 +0500 Message-ID: Subject: Re: How to cross install policy store? From: Shaz To: Stephen Smalley Cc: Daniel J Walsh , TaurusHarry , selinux-mailing-list Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Wed, May 19, 2010 at 12:22 AM, Stephen Smalley 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. 爌olicy 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. 營t 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. 燳ou can compile policy on sparc64 > and use it on x86_32 or vice versa. 燳ou'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. 燭hen 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. 燭hen 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. 燘ut 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. 營f 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. 營t depends on how close > > > the target environment matches a typical Linux distribution. 營f 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. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <4BF28A59.402@redhat.com> <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> Date: Wed, 19 May 2010 15:04:32 +0500 Message-ID: Subject: Re: How to cross install policy store? From: Shaz To: TaurusHarry Cc: Stephen Smalley , dwalsh@redhat.com, selinux-mailing-list Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4BF3E5C4.4070004@gmail.com> Date: Wed, 19 May 2010 06:21:08 -0700 From: "Justin P. Mattock" MIME-Version: 1.0 To: Shaz CC: TaurusHarry , Stephen Smalley , dwalsh@redhat.com, selinux-mailing-list Subject: Re: How to cross install policy store? References: <4BF28A59.402@redhat.com> <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: How to cross install policy store? From: Stephen Smalley To: Shaz Cc: Daniel J Walsh , TaurusHarry , selinux-mailing-list In-Reply-To: References: <4BF28A59.402@redhat.com> <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> Content-Type: text/plain; charset="UTF-8" Date: Wed, 19 May 2010 09:33:23 -0400 Message-ID: <1274276003.1143.74.camel@moss-pluto.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Wed, 2010-05-19 at 15:01 +0500, Shaz wrote: > On Wed, May 19, 2010 at 12:22 AM, Stephen Smalley 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: How to cross install policy store? From: Stephen Smalley To: "Justin P. Mattock" Cc: Shaz , TaurusHarry , dwalsh@redhat.com, selinux-mailing-list In-Reply-To: <4BF3E5C4.4070004@gmail.com> References: <4BF28A59.402@redhat.com> <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> <4BF3E5C4.4070004@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 19 May 2010 09:34:14 -0400 Message-ID: <1274276054.1143.75.camel@moss-pluto.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1274276003.1143.74.camel@moss-pluto.epoch.ncsc.mil> References: <4BF28A59.402@redhat.com> <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> <1274276003.1143.74.camel@moss-pluto.epoch.ncsc.mil> Date: Wed, 19 May 2010 19:03:57 +0500 Message-ID: Subject: Re: How to cross install policy store? From: Shaz To: Stephen Smalley Cc: Daniel J Walsh , TaurusHarry , selinux-mailing-list Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov >> 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. 燭he 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. 燭his is because the libraries will automatically downgrade the > policy file to the version supported by the kernel at policy load time > if necessary. 燞owever, 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. 燭o 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. 燜or > 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. 燭his 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. 燭hat just requires setting up your LD_LIBRARY_PATH, PATH, and > similar variables when building policy for the target. 燭hen 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4BF3F338.4040604@gmail.com> Date: Wed, 19 May 2010 07:18:32 -0700 From: "Justin P. Mattock" MIME-Version: 1.0 To: Stephen Smalley CC: Shaz , TaurusHarry , dwalsh@redhat.com, selinux-mailing-list Subject: Re: How to cross install policy store? References: <4BF28A59.402@redhat.com> <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> <4BF3E5C4.4070004@gmail.com> <1274276054.1143.75.camel@moss-pluto.epoch.ncsc.mil> In-Reply-To: <1274276054.1143.75.camel@moss-pluto.epoch.ncsc.mil> Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: How to cross install policy store? From: Stephen Smalley To: "Justin P. Mattock" Cc: Shaz , TaurusHarry , dwalsh@redhat.com, selinux-mailing-list In-Reply-To: <4BF3F338.4040604@gmail.com> References: <4BF28A59.402@redhat.com> <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> <4BF3E5C4.4070004@gmail.com> <1274276054.1143.75.camel@moss-pluto.epoch.ncsc.mil> <4BF3F338.4040604@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 19 May 2010 10:39:34 -0400 Message-ID: <1274279974.1143.114.camel@moss-pluto.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: How to cross install policy store? From: Stephen Smalley To: Shaz Cc: Daniel J Walsh , TaurusHarry , selinux-mailing-list In-Reply-To: References: <4BF28A59.402@redhat.com> <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> <1274276003.1143.74.camel@moss-pluto.epoch.ncsc.mil> Content-Type: text/plain; charset="UTF-8" Date: Wed, 19 May 2010 11:12:11 -0400 Message-ID: <1274281931.1143.148.camel@moss-pluto.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1274281931.1143.148.camel@moss-pluto.epoch.ncsc.mil> References: <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> <1274276003.1143.74.camel@moss-pluto.epoch.ncsc.mil> <1274281931.1143.148.camel@moss-pluto.epoch.ncsc.mil> Date: Wed, 19 May 2010 20:27:49 +0500 Message-ID: Subject: Re: How to cross install policy store? From: Shaz To: Stephen Smalley Cc: Daniel J Walsh , TaurusHarry , selinux-mailing-list Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov >> 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. 燱hile 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. 燬o someone would > have to code up the support for doing that. 營n 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. 燳ou 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). 營nterfaces 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4BF40B40.6090405@gmail.com> Date: Wed, 19 May 2010 09:01:04 -0700 From: "Justin P. Mattock" MIME-Version: 1.0 To: Stephen Smalley CC: Shaz , TaurusHarry , dwalsh@redhat.com, selinux-mailing-list Subject: Re: How to cross install policy store? References: <4BF28A59.402@redhat.com> <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> <4BF3E5C4.4070004@gmail.com> <1274276054.1143.75.camel@moss-pluto.epoch.ncsc.mil> <4BF3F338.4040604@gmail.com> <1274279974.1143.114.camel@moss-pluto.epoch.ncsc.mil> In-Reply-To: <1274279974.1143.114.camel@moss-pluto.epoch.ncsc.mil> Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: How to cross install policy store? From: Stephen Smalley To: Shaz Cc: Daniel J Walsh , TaurusHarry , selinux-mailing-list In-Reply-To: References: <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> <1274276003.1143.74.camel@moss-pluto.epoch.ncsc.mil> <1274281931.1143.148.camel@moss-pluto.epoch.ncsc.mil> Content-Type: text/plain; charset="UTF-8" Date: Wed, 19 May 2010 12:46:53 -0400 Message-ID: <1274287613.1143.212.camel@moss-pluto.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1274287613.1143.212.camel@moss-pluto.epoch.ncsc.mil> References: <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> <1274276003.1143.74.camel@moss-pluto.epoch.ncsc.mil> <1274281931.1143.148.camel@moss-pluto.epoch.ncsc.mil> <1274287613.1143.212.camel@moss-pluto.epoch.ncsc.mil> Date: Wed, 19 May 2010 21:49:54 +0500 Message-ID: Subject: Re: How to cross install policy store? From: Shaz To: Stephen Smalley Cc: Daniel J Walsh , TaurusHarry , selinux-mailing-list Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov >> 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. 燭hen 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. 營n 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: How to cross install policy store? From: "Christopher J. PeBenito" To: "Justin P. Mattock" Cc: Stephen Smalley , Shaz , TaurusHarry , dwalsh@redhat.com, selinux-mailing-list In-Reply-To: <4BF40B40.6090405@gmail.com> References: <4BF28A59.402@redhat.com> <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> <4BF3E5C4.4070004@gmail.com> <1274276054.1143.75.camel@moss-pluto.epoch.ncsc.mil> <4BF3F338.4040604@gmail.com> <1274279974.1143.114.camel@moss-pluto.epoch.ncsc.mil> <4BF40B40.6090405@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 May 2010 13:49:52 -0400 Message-ID: <1274291392.2093.276.camel@gorn.columbia.tresys.com> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 In-Reply-To: <1274291392.2093.276.camel@gorn.columbia.tresys.com> References: <4BF28A59.402@redhat.com> <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> <4BF3E5C4.4070004@gmail.com> <1274276054.1143.75.camel@moss-pluto.epoch.ncsc.mil> <4BF3F338.4040604@gmail.com> <1274279974.1143.114.camel@moss-pluto.epoch.ncsc.mil> <4BF40B40.6090405@gmail.com>, <1274291392.2093.276.camel@gorn.columbia.tresys.com> Subject: audit_event list ;was Re: How to cross install policy store? MIME-Version: 1.0 From: Bryan Kropf To: "Christopher J. PeBenito" Cc: "Justin P. Mattock" , Stephen Smalley , Shaz , TaurusHarry , dwalsh@redhat.com, selinux-mailing-list Message-ID: Date: Wed, 19 May 2010 14:17:23 -0400 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov

One and all,

My apologies for crashing= in on this thread and for asking something a bit off topic from SELinux sp= ecific to Linux auditing in general.

I am trying= to compile a list of (Fedora/RHEL) Linux audit=5Fevent information and I a= m wondering it this has been done before and where I may find it.

We are trying to document/compile Linux audit configurati= on information and a catalog of events for these configs.

&n= bsp;

Can anyone help point me to a list of all the Linux audit=5F= events, descriptions, id numbers, etc.?

Your hel= p is greatly appreciated.

Bryan Kropf,= CISSP, NSA-IAM/IEM
Raytheon Systems Engineering
443 445-8936 (O= ffice)
Brya= n=5FKropf@raytheon.com

-----owner-selinux@tycho.nsa.gov wrote: -----

To: "Justin P. Mattock" <justi= nmattock@gmail.com>
From: "Christopher J. PeBenito" <cpebenito@tre= sys.com>
Sent by: owner-selinux@tycho.nsa.gov
Date: 05/19/2010 01:= 49PM
cc: Stephen Smalley <sds@tycho.nsa.gov>, Shaz <shazalive@g= mail.com>, TaurusHarry <harrytaurus2002@hotmail.com>, dwalsh@redha= t.com, selinux-mailing-list <selinux@tycho.nsa.gov>
Subject: Re: H= ow to cross install policy store?

On Wed, 2010-05-19 at 09:01 -0700, Ju= stin P. Mattock wrote:
> On 05/19/2010 07:39 AM, Stephen Smalley wrot= e:
> > On Wed, 2010-05-19 at 07:18 -0700, Justin P. Mattock wrote:=
> >> On 05/19/2010 06:34 AM, Stephen Smalley wrote:
> &g= t;>> On Wed, 2010-05-19 at 06:21 -0700, Justin P. Mattock wrote:
&= gt; >>>> On 05/19/2010 03:04 AM, Shaz wrote:
> >>&g= t;>>> It's very true that both SELInux policy and policy store are=
> >>>>>> arch-independent. It takes about 70 minut= es 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 minute= s each time to change
> >>>>>> SELinux attribute on= the fly by the semanage tool, so I think I'd better
> >>>&g= t;>> save all the trouble by committing the changes to SELInux source= code on the
> >>>>>> host instead.
> >>= ;>>>
> >>>>> Sounds interesting. Let me try i= t too.
> >>>>>
> >>>>
> >&g= t;>>
> >>>> yep.. I built a policy on x86=5F64
&= gt; >>>> then copied it to all my other machines(i586)
> = >>>> (no problem), but things like libselinux
> >>&= gt;> will probably be a different story.
> >>>
> &g= t;>> Well, yes, because libselinux is executable code. policy i= s just data.
> >>>
> >>
> >>
>= >> hmm.. I'm wondering if something could be modified
> >&g= t; with monolithic policies and the whole policy
> >> version t= hing i.g. build.conf:
> >>
> >> # Policy version> >> # By default, checkpolicy will create the highest
> &g= t;> # version policy it supports. Setting this will
> >&g= t; # override the version. This only has an
> >> # effect= for monolithic policies.
> >> #OUTPUT=5FPOLICY =3D 18
> = >
> > I'm not sure what you're asking, but I did mention settin= g OUTPUT=5FPOLICY
> > in build.conf or policy-version in semanage.= conf to force generation of
> > an older version of policy when bu= ilding 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(tha= t's all).

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

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

--
This message was distributed to su= bscribers of the selinux mailing list.
If you no longer wish to subscrib= e, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe seli= nux" without quotes as the message.

= -- 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4BF46A7F.3030605@gmail.com> Date: Wed, 19 May 2010 15:47:27 -0700 From: "Justin P. Mattock" MIME-Version: 1.0 To: "Christopher J. PeBenito" CC: Stephen Smalley , Shaz , TaurusHarry , dwalsh@redhat.com, selinux-mailing-list Subject: Re: How to cross install policy store? References: <4BF28A59.402@redhat.com> <1274188841.8879.2.camel@moss-pluto.epoch.ncsc.mil> <1274190359.8879.28.camel@moss-pluto.epoch.ncsc.mil> <1274210546.8879.139.camel@moss-pluto.epoch.ncsc.mil> <4BF3E5C4.4070004@gmail.com> <1274276054.1143.75.camel@moss-pluto.epoch.ncsc.mil> <4BF3F338.4040604@gmail.com> <1274279974.1143.114.camel@moss-pluto.epoch.ncsc.mil> <4BF40B40.6090405@gmail.com> <1274291392.2093.276.camel@gorn.columbia.tresys.com> In-Reply-To: <1274291392.2093.276.camel@gorn.columbia.tresys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov > 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.