On Sat, 29 Sep 2001, Russell Coker wrote:

> I agree that keeping the LSM kernel patch separate is a good idea. I have
> just discovered that the LSM patch on the site is not the upstream 2001_09_26
> version, but the previous version plus some CVS patches. I think that it
> would be beneficial to have an original upstream release of LSM with an
> additional patch. Currently there is an LSM patch on the NSA site with a
> version number implying (to me at least) that it is the same as the current
> LSM upstream release.

A few points of clarification about the relationship between the LSM kernel patch on the NSA web site and the one at lsm.immunix.org:

1. As the download page mentions, the current SELinux kernel is based on the lsm-2001_09_23 snapshot patch against 2.4.10, but incorporates a few additional changes (in particular, a bug fix that was necessary to even boot the LSM kernel plus some new documentation). The LSM kernel patch on the NSA web site is identical to revision 1.219 in the BitKeeper tree accessible via lsm.immunix.org. Sorry for not mentioning the precise revision number on the download page.
2. At the time that we generated the SELinux release, the lsm-2001_09_26 snapshot patch had not yet been generated by WireX. However, there is only one difference between the LSM kernel patch on the NSA web site and lsm-2001_09_26, and that difference is merely a comment, so you can use the SELinux archive with the pure lsm-2001_09_26 patch if you want. The lsm-2001_09_26 patch is revision 1.220 in the BitKeeper tree.
3. There have been no official releases of the LSM kernel patch by WireX yet. The snapshot patches available at lsm.immunix.org are merely snapshots provided periodically by WireX for people who aren't directly using the BitKeeper tree.
4. The LSM kernel patch is a joint development effort by several security projects, including us (SELinux), that is being coordinated by WireX. Since LSM is still under active development, our internal snapshot doesn't always coincide with a particular snapshot at lsm.immunix.org (e.g. our snapshot may include changes that haven't made their way back into the lsm.immunix.org version, or vice versa). However, the LSM kernel patch does seem to be stabilizing, so I expect that this will be less of a problem in the future.

> Now for the kernel patch for selinux I was not requesting that it be merged
> into a single patch with the LSM code (that's the last thing I want). What I
> would like is a single unified diff containing all the selinux kernel code
> without any LSM code. So the proceedure should be:
> Extract upstream kernel source.
> Apply upstream LSM patch.
> Apply SE Linux LSM add-on patch for CVS LSM code.
> Apply SE Linux kernel patch.
> Compile.

> Yes, I can write a script that runs that script on a directory containing the
> security sub-directory from the LSM patch and then generates a unified diff
> containing the minor patch to the LSM security sub-directory and the
> security_plugin sub-dir. But it's painful, nasty, more error prone than
> other methods of achieving the same result, and it makes things more
> difficult for anyone who wants to audit my work (much easier if they can just
> see me using files from the NSA site and move on to the next item in the
> check list).

So, you want a new download option that consists of: 1) A "pure" LSM kernel patch relative to some snapshot from lsm.immunix.org, 2) A SELinux kernel patch that modifies the LSM security/{Makefile, Config.in} and that drops the SELinux kernel module into security/selinux_plug, and
3) A SELinux archive that contains everything except the module subdirectory, plus an alternate README for this situation?

I doubt that any of our direct users would want this download option, but I suppose it is a possibility for redistributors.

> Another issue is that the kernel module doesn't get generated in the same way
> as other modules. I've got 246 regular kernel modules in my kernel build and
> an SE Linux module that has to be compiled differently. I think it would
> really make sense to have the same y/n/m question as for other modules.

We only recommend building SELinux as part of the kernel. Keep in mind that SELinux was originally designed and implemented as a direct kernel patch. Although we have adapted SELinux to work as a kernel module using the LSM security hooks, dynamically loading it as a module into a running kernel poses some thorny problems that are not fully resolved.

Although we only recommend building as part of the kernel, the patch to the security/Config.in file for SELinux does provide the same 'y/n/m' question as other modules. But we also provide instructions and Makefiles for building it as a module without needing to patch LSM or the kernel, since someone may wish to build it for an existing LSM kernel, particularly if LSM becomes integrated into the mainstream kernel. However, we don't currently recommend or support SELinux as a dynamically loaded module into a running kernel.

> However there is the option to compile the module into the kernel, in which
> case it is not a regular kernel and will not successfully boot a system
> without the rest of the SE code installed.

Actually, the SELinux modified daemons and utilities test for the presence of the SELinux module (via the new system calls it implements) and fall back to their ordinary behavior if SELinux is not present. So you can still boot an ordinary Linux kernel with the rest of the SELinux code.

Personally, I don't care whether we change EXTRAVERSION or not. I'll have to see what my colleagues at the NSA think.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com





--
You have received this message because you are subscribed to the selinux 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.