Mailinglist Archive: opensuse-security (499 mails)

< Previous Next >
Re: [suse-security] How to go about mixing kernel patches...
  • From: Roman Drahtmueller <draht@xxxxxxx>
  • Date: Mon, 3 Jun 2002 04:52:47 +0200 (MEST)
  • Message-id: <Pine.LNX.4.44.0206030435490.27763-100000@xxxxxxxxxxxx>
Hi,

> > My first difficulty is applying the SE Linux patch to the
> > SuSE-patched kernel.
> >
> > I applied lsm-2.4-2002050211.patch.gz to vanila 2.4.18 and they apply
> > perfectly.
> >
> > I applied it to linux-2.4.18-SuSE and got some errors, producing the
> > following rejects:
> Hello,
>
> I would not do this, because this means unecessary work. I don't know if
> and what SuSE changed to the kernel (maybe someone from SuSE could clear
> that point), but using a vanilla kernel and applying LSM is a better
> solution. It works and it is not necessary to update every SuSE kernel
> in order to have the latest SuSE *and* LSM/SELinux enhancements.
>
> Better stick with a normal kernel, make adjustments with make menuconfig
> before compiling and let's wait until LSM finds its way into the
> standard kernel. Then SuSE will have LSM by default - no need for
> patching anymore.
>
> Mark
>


This is correct - I don't know of any difficulties when running a vanilla
kernel on a SuSE product. Exceptions: reiserfs (in the past), alsa, DRM
g/x modules, minor ISDN glitches and some other minor problems that only
show up in corner cases.

The SuSE kernel is different in two ways:

* It has additional drivers that are not included in the mainstream kernel
because of licensing issues, because people didn't argue with Linus enough
yet (including drivers is a political issue), or due to some other more
political rather than technical problem.

* It has modifications that we thought are beneficial for the kernel as a
whole. In particular, Andrea's memory management changes usually find
their way into the SuSE kernel. He also sends these patches to Linus and
Alan at the same time, but here at SuSE his guessing is trusted more than
many other people's advice. Therefore, the stuff gets added at once
without any delay. You can see the most intrusive changes in the rejects:
mm, vfs, scheduler and architecture dependent asm code. Here you can see
the influence of SuSE's kernel people.

It would be interesting to see how the latest patch applies to a SuSE
kernel of an older version.

I used to install a vanilla kernel on a fresh SuSE installation, basically
as the first thing I did. That was at a time when some kB made a
difference, both in RAM and on disk. Today, with machines of more than
64MB RAM, I don't think it makes a difference. Most drivers are contained
in modules, and most modules don't consume memory as long as they are not
loaded. The few bytes for symbols that are registered in the core don't
really count. Since some bright people found out how to patch/alter a
running (monolithic!) kernel without any modules support, it doesn't make
a difference any more in terms of security. If you are in a postition
where you can load kernel modules, you have already passed the root of
your security problem.

Then: The LSM patch. The patch is very intrusive, but it is easy to see
that it barely does anything. Applying it is a matter of plain work, and
this can be done. I can't make any promises - there may turn up a reason
that we couldn't see in advance. But I am quite sure that we'll have it in
the future. Hubert is prepared...

Thanks,
Roman.
--
- -
| Roman Drahtmüller <draht@xxxxxxx> // "You don't need eyes to see, |
SuSE Linux AG - Security Phone: // you need vision!"
| Nürnberg, Germany +49-911-740530 // Maxi Jazz, Faithless |
- -





< Previous Next >
References