I believe that the current method of distributing the kernel code could be
improved by supplying it as either a single patch, or a tar file with a tiny
patch.
Most kernel code is distributed in the form of a unified diff. This form is easy to separate from other related code (often we need kernel code and user-space code separate for compilation on different machines). It is easy to manipulate in scripts (such as for the Debian packages I am preparing), and is easy to combine with other patches.
A tar file and a small patch would also be easy to deal with.
The current situation of having a Makefile which applies a patch, creates sym-links, etc makes it virtually impossible to automatically do anything with the code. This means I can't use pure upstream source in my kernel-patch package which adds a risk of error, and makes it more difficult for anyone who wants to audit my work.
Could the management of the kernel patch be changed in the next release?
Also could the kernel patch please change the EXTRAVERSION variable in the top-level makefile? Currently the kernel-patch package I am playing with changes it from "-lsm" to "-selinux", but it would be equally valid to change it to "-lsm-selinux" instead. I believe that a change to the EXTRAVERSION is necessary for anyone who is attempting to manage kernel builds for dis-similar machines. The results of installing a non-SE kernel when you want a SE kernel or of installing a SE kernel when you want a non-SE kernel are both unpleasant!
PS Anyone who wants a pre-release Debian kernel-patch-2.4.10-selinux package please contact me off-list.
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
--
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.
On Fri, 28 Sep 2001, Russell Coker wrote:
> I believe that the current method of distributing the kernel code could be
> improved by supplying it as either a single patch, or a tar file with a tiny
> patch.
One of the current download options (Option 3, Everything but Kernel Source) allows you to download the LSM kernel patch against 2.4.10 and the SELinux archive. The SELinux archive includes a small patch to the LSM security/Makefile and security/Config.in files to add an option for building the SELinux kernel module into the kernel, but it doesn't include any patches to the kernel source code. The SELinux code is a kernel module. I suppose we could "merge" our small Makefile/Config.in patch and our kernel module directly into the version of the LSM kernel patch distributed from the NSA site, but I would prefer to keep the LSM kernel patch "pure" relative to some snapshot of the LSM kernel patch from lsm.immunix.org. And, of course, if the LSM kernel patch is adopted into 2.5, we will no longer need to distribute it at all, so we would naturally still need the small patch and kernel module in our separate archive.
> Most kernel code is distributed in the form of a unified diff. This form is
> easy to separate from other related code (often we need kernel code and
> user-space code separate for compilation on different machines). It is easy
> to manipulate in scripts (such as for the Debian packages I am preparing),
> and is easy to combine with other patches.
> A tar file and a small patch would also be easy to deal with.
Option 3 provides the LSM kernel patch and a gzipped tar file.
> The current situation of having a Makefile which applies a patch, creates
> sym-links, etc makes it virtually impossible to automatically do anything
> with the code. This means I can't use pure upstream source in my
> kernel-patch package which adds a risk of error, and makes it more difficult
> for anyone who wants to audit my work.
As mentioned above, the selinux module Makefile only patches the security/Makefile and security/Config.in files. It also sets up some symbolic links used internally by the kernel module. It isn't clear as to how this is an obstacle to using the pure kernel sources.
> Also could the kernel patch please change the EXTRAVERSION variable in the
> top-level makefile? Currently the kernel-patch package I am playing with
> changes it from "-lsm" to "-selinux", but it would be equally valid to change
> it to "-lsm-selinux" instead. I believe that a change to the EXTRAVERSION is
> necessary for anyone who is attempting to manage kernel builds for
> dis-similar machines. The results of installing a non-SE kernel when you
> want a SE kernel or of installing a SE kernel when you want a non-SE kernel
> are both unpleasant!
I suppose we could change the EXTRAVERSION, but I'm not sure why. The kernel itself is just the LSM kernel. The SELinux code is a kernel module. You don't typically change the EXTRAVERSION for kernel modules.
-- 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.From: Russell Coker <russell_at_coker.com.au>
On Fri, 28 Sep 2001 20:50, Stephen Smalley wrote:
> On Fri, 28 Sep 2001, Russell Coker wrote:
> > I believe that the current method of distributing the kernel code could
> > be improved by supplying it as either a single patch, or a tar file with
> > a tiny patch.
>
> One of the current download options (Option 3, Everything but Kernel
> Source) allows you to download the LSM kernel patch against 2.4.10 and the
> SELinux archive. The SELinux archive includes a small patch to the LSM
> security/Makefile and security/Config.in files to add an option for
> building the SELinux kernel module into the kernel, but it doesn't include
> any patches to the kernel source code. The SELinux code is a kernel
> module. I suppose we could "merge" our small Makefile/Config.in patch and
> our kernel module directly into the version of the LSM kernel patch
> distributed from the NSA site, but I would prefer to keep the LSM kernel
> patch "pure" relative to some snapshot of the LSM kernel patch from
> lsm.immunix.org. And, of course, if the LSM kernel patch is adopted into
> 2.5, we will no longer need to distribute it at all, so we would naturally
> still need the small patch and kernel module in our separate archive.
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.
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.
> > The current situation of having a Makefile which applies a patch, creates
> > sym-links, etc makes it virtually impossible to automatically do anything
> > with the code. This means I can't use pure upstream source in my
> > kernel-patch package which adds a risk of error, and makes it more
> > difficult for anyone who wants to audit my work.
>
> As mentioned above, the selinux module Makefile only patches the
> security/Makefile and security/Config.in files. It also sets up some
> symbolic links used internally by the kernel module. It isn't clear
> as to how this is an obstacle to using the pure kernel sources.
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).
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.
The current proceedure for compiling the SE Linux module requires me to do
one of two things to create a Debian kernel package:
1) Create a separate package containing only the module for SE Linux (which
seems hardly worth-while).
2) Hack the kernel package creation scripts to run the SE Linux module build
command, or alternatively hack the SE Linux patch to work in the regular
fashion.
Neither of these options is ideal IMHO.
> > Also could the kernel patch please change the EXTRAVERSION variable in
> > the top-level makefile? Currently the kernel-patch package I am playing
> > with changes it from "-lsm" to "-selinux", but it would be equally valid
> > to change it to "-lsm-selinux" instead. I believe that a change to the
> > EXTRAVERSION is necessary for anyone who is attempting to manage kernel
> > builds for dis-similar machines. The results of installing a non-SE
> > kernel when you want a SE kernel or of installing a SE kernel when you
> > want a non-SE kernel are both unpleasant!
>
> I suppose we could change the EXTRAVERSION, but I'm not sure why.
> The kernel itself is just the LSM kernel. The SELinux code is a kernel
> module. You don't typically change the EXTRAVERSION for kernel modules.
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.
That is a good point though.
-- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- 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.From: Stephen Smalley <sds_at_tislabs.com>
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:
> 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.From: Steve Smalley <sds_at_tislabs.com>
On Mon, 1 Oct 2001, Stephen Smalley wrote:
> 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?
Actually, you probably want #3 to just be the SELinux small archive from Download Option 4 without the kernel module (i.e. the example policy configuration, the setfiles utility and file_contexts configuration, and the new utility programs). For the modified daemons and utilities, you probably just want the individual patches provided under Option 4, but you will need to adapt them to the corresponding Debian daemons and utilities, since we used RedHat as our base platform.
-- 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.From: Russell Coker <russell_at_coker.com.au>
On Mon, 1 Oct 2001 16:12, Steve Smalley wrote:
> For the modified daemons and utilities, you
> probably just want the individual patches provided under Option 4, but you
> will need to adapt them to the corresponding Debian daemons and utilities,
> since we used RedHat as our base platform.
This raises another issue. It's probably a good idea to ship a copy of the un-patched utility programs.
When I first took over Portslave development I had heaps of problems trying to identify changes because it was impossible to find a pppd source tree that matched the version that Portslave was based on.
Hopefully I won't have the same problems here (at least you presumably have the matching upstream source somewhere, and it's too new to have disappeared from all the FTP sites yet). But to save future problems for us it would be good to have a copy of the source without the patches.
Also this makes auditing the code easier.
-- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- 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.From: Stephen Smalley <sds_at_tislabs.com>
On Mon, 1 Oct 2001, Russell Coker wrote:
> This raises another issue. It's probably a good idea to ship a copy of the
> un-patched utility programs.
>
> Hopefully I won't have the same problems here (at least you presumably have
> the matching upstream source somewhere, and it's too new to have disappeared
> from all the FTP sites yet). But to save future problems for us it would be
> good to have a copy of the source without the patches.
We have the original unpatched sources in CVS, so I suppose we could provide unpatched source tar balls for each of the modified daemons and utilities. But I expect that you'll need to port the SELinux daemon and utility patches to the corresponding source package provided with Debian, unless they happen to use the same base sources as RedHat and do not deviate significantly in terms of distribution-specific patches.
Also, unless you want to defer it to your end users, it would be good for you to customize setfiles/file_contexts and the example policy configuration for a typical Debian system.
-- 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.From: Jesse Pollard <pollard_at_tomcat.admin.navo.hpc.mil>
Russell Coker <russell@coker.com.au>:
>
> I believe that the current method of distributing the kernel code could be
> improved by supplying it as either a single patch, or a tar file with a tiny
> patch.
>
> Most kernel code is distributed in the form of a unified diff. This form is
> easy to separate from other related code (often we need kernel code and
> user-space code separate for compilation on different machines). It is easy
> to manipulate in scripts (such as for the Debian packages I am preparing),
> and is easy to combine with other patches.
>
> A tar file and a small patch would also be easy to deal with.
>
> The current situation of having a Makefile which applies a patch, creates
> sym-links, etc makes it virtually impossible to automatically do anything
> with the code. This means I can't use pure upstream source in my
> kernel-patch package which adds a risk of error, and makes it more difficult
> for anyone who wants to audit my work.
>
> Could the management of the kernel patch be changed in the next release?
>
>
> Also could the kernel patch please change the EXTRAVERSION variable in the
> top-level makefile? Currently the kernel-patch package I am playing with
> changes it from "-lsm" to "-selinux", but it would be equally valid to change
> it to "-lsm-selinux" instead. I believe that a change to the EXTRAVERSION is
> necessary for anyone who is attempting to manage kernel builds for
> dis-similar machines. The results of installing a non-SE kernel when you
> want a SE kernel or of installing a SE kernel when you want a non-SE kernel
> are both unpleasant!
Actually, I would prefer the "EXTRAVERSION" be left alone and/or add a new form of EXTRAVERSION (I'll call it "LOCALVERSION") be made generally available.
That way patches could modify "EXTRAVERSION" and I can use "LOCALVERSION" to hold whatever the local site chose.
Currently, I'm using EXTRAVERSION to have thinks like:
-RSBAC -RSBAC.MAINT -RSBAC.SMP -SMP I would also suggest that the name string have a defined format: Linux-MAJORVERSION.PATCHLEVEL.SUBLEVEL-EXTRAVERSION-LOCALVERSION That way it would also be possible to see other items - something like: Linux-2.4.10-ac3-SMP And any missing fields be null: Linux-2.4.10--
It is easy to get carried away with naming things:
Linux-2.4.10-ac3-lsm.27-SMP
(calls for multiple layers of extraversion, one for the ac levels, one for the lsm number, one for localversion..."When I name a thing it means what I mean, and nothing more" (((or something like that))) :-)
Any opinions expressed are solely my own.
-- 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.From: Russell Coker <russell_at_coker.com.au>
On Fri, 28 Sep 2001 21:41, Jesse Pollard wrote:
> > Also could the kernel patch please change the EXTRAVERSION variable in
> > the top-level makefile? Currently the kernel-patch package I am playing
> > with changes it from "-lsm" to "-selinux", but it would be equally valid
>
> Actually, I would prefer the "EXTRAVERSION" be left alone and/or add a new
> form of EXTRAVERSION (I'll call it "LOCALVERSION") be made generally
> available.
That would be OK too. However using a LOCALVERSION would require more patches to the main kernel tree which would need to be separate from what we are doing, which means more patches to juggle.
Sending a patch to Alan that implements LOCALVERSION might be a good idea.
For the moment I think that we have no realistic choice apart from using EXTRAVERSION as it's all we can do.
I take it that you agree that we need some way of knowing from the early boot stages whether we are running selinux, plain lsm, or neither?
-- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- 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.From: Manoj Srivastava <manoj.srivastava_at_stdc.com>
>>"Jesse" == Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> writes:
Jesse> Actually, I would prefer the "EXTRAVERSION" be left alone Jesse> and/or add a new form of EXTRAVERSION (I'll call it Jesse> "LOCALVERSION") be made generally available. The Debian kernel-package provides for such a device; we callit FLAVOURS. I am attaching the FLAVOURS file from the kernel-package package in the hope that people can use the patches in the file. Of course, if you are using kernel-package, the --append_to_version argument to make-kpkg provides a better and more flexible solution.
manoj
ps. The FLAVOURS mechanism predates the EXTRAVERSIONS variable by a
couple of years
-- Tex SEX! The HOME of WHEELS! The dripping of COFFEE!! Take me to Minnesota but don't EMBARRASS me!! Manoj Srivastava <manoj.srivastava@stdc.com> <srivasta@acm.org> 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- 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.
- multipart/mixed attachment: Multiple Flavours of a kernel
This archive was generated by hypermail 2.2.0 on Wed 11 Jun 2008 - 08:10:54 EDT