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?
-or-
3) perform a monolithic policy build in the first place and thus avoid
the entire indirection of modules and semodule in the first place.
Also, you said you didn't want to load the policy on the build host so
I'm not sure why you are trying to do that. The reason that it is
failing is not that the policy is invalid but because the cat program
writes it in fixed size chunks rather than atomically in one write call,
and /selinux/load requires that the entire policy be fed to it in a
single write call. The load_policy program does this by opening the
policy file, fstat'ing it to get the size, mmap'ing it into memory, and
then write'ing the entire memory region to /selinux/load in a single
write() call. You can see that logic in libselinux/src/load_policy.c;
it was once directly implemented in the load_policy program but later
moved into the library and further encapsulated.
Yes i just found out myself too. so I used dd with a big block size and
it worked beautifully.
Ok, a useful workaround to know.
semodule_link/expand are developer tools for manually applying the link
+expand phases, and thus will operate on whatever inputs you provide
rather than only operating on a policy store under /etc/selinux.
The kernel doesn't care where the policy originates; it is only
userspace that has the convention that it lives under /etc/selinux.
thanks Stephen. I think I have found my solution.
--
Vikram Ambrose | Linux Products Division | WindRiver Corporation
--
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.
