On Tue, 2008-06-17 at 16:12 -0400, Vikram Ambrose wrote: > Stephen Smalley wrote: > > On Tue, 2008-06-17 at 10:52 -0400, Vikram Ambrose wrote: > > > >> Stephen Smalley wrote: > >> > >>> On Tue, 2008-06-17 at 09:52 -0400, Vikram Ambrose wrote: > >>> > >>> > >>>> Stephen Smalley wrote: > >>>> > >>>> > >>>>> On Mon, 2008-06-16 at 17:35 -0400, Vikram Ambrose wrote: > >>>>> > >>>>> > >>>>> > >>>>>> Stephen Smalley wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On Mon, 2008-06-16 at 13:56 -0400, Vikram Ambrose wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> Stephen Smalley wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> Note that they get installed to $DESTDIR/usr/share/selinux/$SELINUXTYPE > >>>>>>>>> by make install. In Fedora, they are packaged as such, then when you > >>>>>>>>> install the package on the target host, they are unpacked > >>>>>>>>> to /usr/share/selinux/$SELINUXTYPE by the package manager and then a % > >>>>>>>>> post scriptlet runs semodule on them to install them under /etc/selinux > >>>>>>>>> and load them. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> In Fedora, does anaconda chroot into the sysroot and call semodule > >>>>>>>> during installation? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> Some combination of anaconda and rpm, yes. semodule runs from a %post > >>>>>>> scriptlet in the selinux-policy-targeted package at package install > >>>>>>> time. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> Options for you might include: > >>>>>>>>> 1) Run semodule_link and semodule_expand at build time to link and > >>>>>>>>> expand the modules to a kernel policy up front. Then you can just put > >>>>>>>>> the files into place without running semodule later. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> I will investigate this option further, thank you. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> Ok. You can see an example of it in the 'make validate' target, > >>>>>>> although that is just to check that they will link and expand > >>>>>>> successfully; it isn't used to install the policy normally and likely > >>>>>>> doesn't keep the final result around. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> I am getting a bit confused between "modular" and "monolithic", in both > >>>>>> cases a policy.X file is needed to load the policy into the kernel, right? > >>>>>> > >>>>>> and in the modular case, the policy.X file simply points to the various > >>>>>> .pp files and in the monolithic case everything is in the policy.X file? > >>>>>> Analogous to shared library and static library link (modular/monolithic)? > >>>>>> > >>>>>> > >>>>>> > >>>>> In either case, we ultimately need a complete policy.N file that > >>>>> contains all of the information for loading into the kernel. The kernel > >>>>> only knows about the policy.N format; it knows nothing of policy > >>>>> modules. > >>>>> > >>>>> The difference is whether we need to compile a complete set of policy > >>>>> sources directly into the policy.N file, or whether we can separately > >>>>> compile and package each policy module into a .pp file and then later > >>>>> link and expand the set of installed policy modules to create a policy.N > >>>>> file. > >>>>> > >>>>> The modular policy support was introduced later (first appeared in > >>>>> Fedora Core 5), to allow for local customization of policy without > >>>>> requiring complete policy sources and to enable third party policy and > >>>>> decomposition of distribution policy among the packages. > >>>>> > >>>>> In a monolithic policy build, you take the entire set of policy sources, > >>>>> apply various preprocessing steps, combine the result into a single > >>>>> policy.conf file, and then feed that to the checkpolicy program to > >>>>> generate the policy.N file for the kernel. And you likewise preprocess > >>>>> and combine the .fc files to form the complete file_contexts > >>>>> configuration. Later if you want to add more policy, you drop it into > >>>>> the policy source tree and repeat the entire process. > >>>>> > >>>>> In the modular policy build, you take each policy module's sources (.te > >>>>> file), apply various preprocessing steps, feed the result to the > >>>>> checkmodule program to generate a binary module (.mod) file, then feed > >>>>> the .mod file and the .fc file to semodule_package to generate the > >>>>> policy package (.pp) file. Then you ship the .pp files to the target > >>>>> host, run semodule to insert them into the policy module store, link > >>>>> them together, and expand them into a policy.N file on that host. Later > >>>>> if you want to add more policy, you compile it as a module separately, > >>>>> ship the resulting .pp file to the target host, and then run semodule on > >>>>> it, which will add it to the policy store and generate an updated > >>>>> policy.N file. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> hmm, that somewhat explains it, but the terminology used across man > >>>> pages and the internet doesn't seem to be consistent so it's a bit > >>>> difficult to understand whats what. > >>>> So to avoid semodule's affinity for /etc/selinux i can get away with > >>>> semodule_link and semodule_expand? > >>>> I don't understand what the output of each command is. I did a > >>>> semodule_link of all my .pp files and then did a senodule_expand of that > >>>> file into another file, and then cat'ed that into /selinux/load and i > >>>> got an error about a map. > >>>> > >>>> [600793.305757] security: ebitmap: truncated map > >>>> > >>>> Also, once the policy.X file is loaded, does the system need access to > >>>> /etc/selinux/$POLICY ? > >>>> > >>>> > >>> You can do that, but I'm still not clear on why you are doing it. It > >>> seems like you should be doing one of the following instead: > >>> 1) run semodule on the target system to install the .pp files and load > >>> the resulting policy rather than trying to do it all on the build host, > >>> -or- > >>> > >>> > >> Yes this works, however i'd like to have it running out of the box > >> without this step. > >> > > > > Up to you, of course, but note that at least in Fedora, this happens > > naturally via a %post scriptlet in the selinux-policy packages and isn't > > fundamentally different than other %post actions performed for system > > setup when a package is installed. > > > > > >>> 2) run semodule within a chroot on the build system to install the .pp > >>> files and create the kernel policy. Eric Paris has been getting such > >>> builds to work for Fedora live CD creation. > >>> > >>> > >> I'm not a fan of the chroot environment, but now that i have learned > >> that i can manually semodule_link/expand to create my policy.X file, i > >> can do the whole operation without using /etc/, this makes > >> packaging/building out of the target system much easier, as well as > >> deployment is a simple: > >> 1. untar the .pp files to /usr/share/selinux/policy/ for devs to use > >> 2. refpolicy make install, stuff untar'ed to > >> /etc/selinux/policy/contexts and > >> 3. copy my policy.X file that was produced by link/expand (also from the > >> build host), to /etc/selinux/policy/policy > >> 4. edit semanage.conf and selinux.conf, throw in load_policy into > >> sysvinit and i'm done! > >> > > > > You may also need to manually generate the file_contexts file and put it > > into place, as semodule_link/expand doesn't presently handle that for > > you. > > > > > How is that file created? Normally libsemanage creates it from the .pp files by combining the individual .fc files, sorting the result based on specificity of the regexes, then splits the result into two files, the file_contexts file and the homedir_template. semodule_link doesn't do that for you presently. One option would be to just build the file_contexts config "monolithically" i.e. make MONOLITHIC=y file_contexts. I expect that would yield the same result as the libsemanage version. -- 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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
