Re: Kernel upgrades = security upgrades - a possible solution?
Quoting Marcin Owsiany ([EMAIL PROTECTED]): On Wed, Sep 29, 1999 at 05:24:54PM +0300, Martin Fluch wrote: On Wed, 29 Sep 1999, Marcin Owsiany wrote: I guess this kind of kernel packages would be for people quite concerned about security but also quite lazy :) I guess, this is mutual exclusive. People which are lazy will leave many (and I think also bigger) security holes some where else on the system, so that it won't matter, if you keep your kernel that much secure... well, yes you are right. :) I guess i didn't really think of it before writing :( Also if you administer a lot of boxes, and if they work ok with the default kernel you will find it _a lot_ more convenient to automatically upgrade kernel than to compile it for each box... Ever considerd the package 'kernel-package'. This makes out of any kernel source debian packages, which then can be installed with dpkg, apt-get or what ever ... sure, since i had discovered it, i've never made a kernel without using it. But still you have to make the kernel, and if you compile it, you can't resist tweaking it to each particular system's needs, can you? :) But this is where modules can help you. I have several machines that need slightly different configurations because they have different built-in sound mobos. I compile the kernel on one of them but with all the modules I need. Then I fine tune /etc/modules for soundcard, ppa, joystick etc. But I think that the separation of kernel and distribution is a valuable property of linux and should be preserved at all costs. Otherwise there is the temptation to introduce subtle dependencies between them, which increases complexity and decreases robustness. On a slightly different but related tack, now that NT is an Intel-only OS, how long before Intel architecture specific code creeps into the kernel. How hard will it be to extract those dependencies when transferring it to a new platform. Cheers, -- Email: [EMAIL PROTECTED] Tel: +44 1908 653 739 Fax: +44 1908 655 151 Snail: David Wright, Earth Science Dept., Milton Keynes, England, MK7 6AA Disclaimer: These addresses are only for reaching me, and do not signify official stationery. Views expressed here are either my own or plagiarised.
Re: Kernel upgrades = security upgrades - a possible solution?
On Tue, Sep 28, 1999 at 05:05:21PM -0500, Brian Servis wrote: *- On 28 Sep, Fraser Campbell wrote about Re: Kernel upgrades = security upgrades Brian Servis wrote: Notice that the version is part of the package name. Thus a kernel-image-2.0.34 and kernel-image-2.0.36 are two totally different packages as far as Debian is concerned, except that they both provide the virtual package kernel-image and that fact is not determined until it is being installed. Ok. To my way of thinking it should be called kernel-image_2.0.34, kernel-image_2.0.36-3, etc. That way apt-get upgrade would grab updated kernels for the user. IMO kernels are a very critical part of security and that they should be upgradeable as part of the normal process. I realize the kernel is a very special piece of software but still see no reason why it is treated differently from normal software. Perhaps the If kernel-images did not have the version in the package name then you could not have two different versions of the kernel installed at the same time. There are instances where having two different kernels is needed. Such as for development machines where code must be checked under various kernel versions. This is especially true for the case when a new stable kernel branch is released and not all programs are compatible with the newer kernel, such as was the case with 2.0.x and 2.2.x kernels. upgrade process depends on the virtual package kernel-image which I don't seem to have installed? The Debian-policy best describes how virtual packages work: 2.3.5. Virtual packages --- Sometimes, there are several packages doing more-or-less the same job. In this case, it's useful to define a _virtual package_ who's name describes the function the packages have. (The virtual packages just exist logically, not physically--that's why they are called _virtual_.) The packages with this particular function will then _provide_ the virtual package. Thus, any other package requiring that function can simply depend on the virtual package without having to specify all possible packages individually. the way to solve the problem would be to create a package called e.g. secure-kernel, which would depend on the most secure kernel-image-ver. Then if the security team has newer kernel with security bugfixes, they would make a new version of secure-kernel which would depend on the fixed kernel. any objections? Marcin -- Marcin Owsiany [EMAIL PROTECTED]
Re: Kernel upgrades = security upgrades - a possible solution?
On Tue, 28 Sep 1999, Marcin Owsiany wrote: the way to solve the problem would be to create a package called e.g. secure-kernel, which would depend on the most secure kernel-image-ver. Then if the security team has newer kernel with security bugfixes, they would make a new version of secure-kernel which would depend on the fixed kernel. I, for one, wouldn't want my kernel upgraded automatically, no matter what the fixes involved are. Here's why: I have compiled my own kernel with my hardware selected (sound, tape drive, scsi card, network card) and Debian simply can't afford to make all possible combinations of kernel configurations to provide an easy upgrade path for users. Now, possibly there could be some kind of secure-kernel package which would do nothing more than simply inform you during upgrade that a newer kernel with such-and-such security patches is available and recommend how to upgrade, that's seems more reasonable to me at least. -- Ashley Clark
Re: Kernel upgrades = security upgrades - a possible solution?
On Tue, Sep 28, 1999 at 09:41:26PM -0500, Ashley Clark wrote: On Tue, 28 Sep 1999, Marcin Owsiany wrote: the way to solve the problem would be to create a package called e.g. secure-kernel, which would depend on the most secure kernel-image-ver. Then if the security team has newer kernel with security bugfixes, they would make a new version of secure-kernel which would depend on the fixed kernel. I, for one, wouldn't want my kernel upgraded automatically, no matter what the fixes involved are. Here's why: I have compiled my own kernel with my hardware selected (sound, tape drive, scsi card, network card) and Debian simply can't afford to make all possible combinations of kernel configurations to provide an easy upgrade path for users. Now, possibly there could be some kind of secure-kernel package which would do nothing more than simply inform you during upgrade that a newer kernel with such-and-such security patches is available and recommend how to upgrade, that's seems more reasonable to me at least. That is the point of this idea. If you want your kernel to be upgraded automatically, you install secure-kernel, if you only want to be informed, you install secure-kernel-info, if you don't care at all, you instal neither. regards Marcin -- - Marcin Owsiany [EMAIL PROTECTED] -
Re: Kernel upgrades = security upgrades - a possible solution?
On Wed, Sep 29, 1999 at 10:27:43AM +, Marcin Owsiany wrote: On Tue, Sep 28, 1999 at 09:41:26PM -0500, Ashley Clark wrote: On Tue, 28 Sep 1999, Marcin Owsiany wrote: the way to solve the problem would be to create a package called e.g. secure-kernel, which would depend on the most secure kernel-image-ver. Then if the security team has newer kernel with security bugfixes, they would make a new version of secure-kernel which would depend on the fixed kernel. I, for one, wouldn't want my kernel upgraded automatically, no matter what the fixes involved are. Here's why: I have compiled my own kernel with my hardware selected (sound, tape drive, scsi card, network card) and Debian simply can't afford to make all possible combinations of kernel configurations to provide an easy upgrade path for users. Now, possibly there could be some kind of secure-kernel package which would do nothing more than simply inform you during upgrade that a newer kernel with such-and-such security patches is available and recommend how to upgrade, that's seems more reasonable to me at least. That is the point of this idea. If you want your kernel to be upgraded automatically, you install secure-kernel, if you only want to be informed, you install secure-kernel-info, if you don't care at all, you instal neither. I am still very leery of automatic kernel updating... I do rather like the idea of secure-kernel-info, as Marcin has described it, but it needs a better name; secure-kernel just won't do it. kernel-update-watcher perhaps. However, if security is enough of an issue for you that you think a kernel package should be made around it, maybe you should keep an eye on bugtraq and freshmeat, or a cron-job to grab the LATEST-VERSION-IS file from the kernel.org servers -- no matter which approach is taken, it will be faster than waiting for a new kernel package to come along... -- Seth Arnold | http://www.willamette.edu/~sarnold/ Hate spam? See http://maps.vix.com/rbl/ for help Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Re: Kernel upgrades = security upgrades - a possible solution?
On Wed, Sep 29, 1999 at 02:42:38AM -0700, Seth R Arnold wrote: On Wed, Sep 29, 1999 at 10:27:43AM +, Marcin Owsiany wrote: On Tue, Sep 28, 1999 at 09:41:26PM -0500, Ashley Clark wrote: On Tue, 28 Sep 1999, Marcin Owsiany wrote: the way to solve the problem would be to create a package called e.g. secure-kernel, which would depend on the most secure kernel-image-ver. Then if the security team has newer kernel with security bugfixes, they would make a new version of secure-kernel which would depend on the fixed kernel. I, for one, wouldn't want my kernel upgraded automatically, no matter what the fixes involved are. Here's why: I have compiled my own kernel with my hardware selected (sound, tape drive, scsi card, network card) and Debian simply can't afford to make all possible combinations of kernel configurations to provide an easy upgrade path for users. Now, possibly there could be some kind of secure-kernel package which would do nothing more than simply inform you during upgrade that a newer kernel with such-and-such security patches is available and recommend how to upgrade, that's seems more reasonable to me at least. That is the point of this idea. If you want your kernel to be upgraded automatically, you install secure-kernel, if you only want to be informed, you install secure-kernel-info, if you don't care at all, you instal neither. I am still very leery of automatic kernel updating... I do rather like the idea of secure-kernel-info, as Marcin has described it, but it needs a better name; secure-kernel just won't do it. kernel-update-watcher perhaps. but of course, i know the names need improving However, if security is enough of an issue for you that you think a kernel package should be made around it, maybe you should keep an eye on bugtraq and freshmeat, or a cron-job to grab the LATEST-VERSION-IS file from the kernel.org servers -- no matter which approach is taken, it will be faster than waiting for a new kernel package to come along... I guess this kind of kernel packages would be for people quite concerned about security but also quite lazy :) Also if you administer a lot of boxes, and if they work ok with the default kernel you will find it _a lot_ more convenient to automatically upgrade kernel than to compile it for each box... Just my 0.02 Marcin -- - Marcin Owsiany [EMAIL PROTECTED] -
Re: Kernel upgrades = security upgrades - a possible solution?
On Wed, 29 Sep 1999, Marcin Owsiany wrote: That is the point of this idea. If you want your kernel to be upgraded automatically, you install secure-kernel, if you only want to be informed, you install secure-kernel-info, if you don't care at all, you instal neither. I had read nothing of this secure-kernel-info package, but that would be reasonable to me. -- Ashley Clark
Re: Kernel upgrades = security upgrades - a possible solution?
On Wed, 29 Sep 1999, Marcin Owsiany wrote: I guess this kind of kernel packages would be for people quite concerned about security but also quite lazy :) I guess, this is mutual exclusive. People which are lazy will leave many (and I think also bigger) security holes some where else on the system, so that it won't matter, if you keep your kernel that much secure... Also if you administer a lot of boxes, and if they work ok with the default kernel you will find it _a lot_ more convenient to automatically upgrade kernel than to compile it for each box... Ever considerd the package 'kernel-package'. This makes out of any kernel source debian packages, which then can be installed with dpkg, apt-get or what ever ... Martin -- If the box says 'Windows 95 or better', it should run on Linux, right? - anonymous
Re: Kernel upgrades = security upgrades - a possible solution?
On Wed, Sep 29, 1999 at 10:46:20AM +, Marcin Owsiany wrote: I guess this kind of kernel packages would be for people quite concerned about security but also quite lazy :) Also if you administer a lot of boxes, and if they work ok with the default kernel you will find it _a lot_ more convenient to automatically upgrade kernel than to compile it for each box... Heh, this is where the kernel-package package comes into play. :) You compile the kernel once into a .deb, and install that using dpkg or apt-get. :) -- Seth Arnold | http://www.willamette.edu/~sarnold/ Hate spam? See http://maps.vix.com/rbl/ for help Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
