>> 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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
