Steve Youngs wrote:
>
<snip>
> MM> True, but then it just opens another door to attackers, because it is
> MM> surely easier to modify a file (/etc/modules.conf) to load
> MM> trojan_horse.o instead of ppp.o than poke around directly in the kernel
> MM> image.
>
> Okay, granted, it would be far easier to modify /etc/modules.conf than it
> would be to poke around in a kernel image. But to do this the attacker
> would need to gain access to your box in the first place. And
<snip>
Unfortunately you snipped the answer to your question. I said that this
would be a hypothetical attack, because there are other things you could
break when you can write to the root partition. Note that I'm not only
speaking of attacks when Linux is up'n'running. There are attacks
possible much more easily if you have physical access to the box and
e.g. boot dos to fiddle around in Linux's peritions.
>
> I think that the advantages of modules far outweigh the so called security
> risk that you are talking about. And besides if you are that paranoid
> about it you could always set the immutable bit on /etc/modules.conf. (man
> chattr, man lsattr).
See above.
>
> MM> but if you don't really need modules, why keep one more door open?
>
> How about...because it saves RAM ?
>
What good are 100k on a 64M machine?
> What about all the people out there (and I definately fall into this
> category) who want to play? Say for example you think that one day you
> might like to play around with ramdisks or with loopback devices
> (filesystems in a file), or with a slip connection... In my kernel those
> things would be modules and would only get loaded if and when I ever get
> around to playing with them. But in your kernel, they are all in the
> kernel all the time. Now that seems to me to be a huge waste of
> resources.
What do you call 'huge'? I have in my kernel
- SCSI
- encryption over loopback dev's
- ISDN
- IP FW & MASQ
to name but the not-so-common and it is still only 617K in image form.
I have 128M of RAM, so my kernel takes far less than 1% of it. Why
should I bother myself with 0.2% of my RAM? That's less than an instance
of rc5des uses. If I need more RAM, I have other, more useful options:
- buy more
- disable unused permanent deamons and make them slaves to inetd
- reduce the number of concurrent instances of apache from 5 (the SuSE
default) to 4, which gives me something between 1M and 2M of free RAM.
>
> Lets look at another example... a soundcard. Not many people constantly
> access their soundcard, it usually only gets used a small fraction of the
> time the computer is up. So where is the logic behind having the
> soundcard drivers permanently in the kernel?
>
If you run many different kernel versions like I do, you don't want the
modules to come in your way:
# /sbin/lilo
Added linux *
Added linux-2.2.7
Added linux-2.2.9-md
Added linux-2.3.8
Added linux-2.3.9
Added linux-2.2.10i
Note that I have just yesterday removed kernel versions 2.0.36, 2.2.5 in
different versions.
> When you are home alone at night, do you have all the lights on, the TV in
> the living room on, TV in the bedroom on? And when you go to bed do you
> leave all the lights etc on or do you turn things on and off as the need
> arises? Why should your kernel be any different? If it will save on
> resources and RAM, why not use modules?
>
That's not a comparison that makes sense.
If I switch off all the lights and entertainmaent electronics, I reduce
my power comsumption to around 10 to 20%. If I did everything I could as
modules and compared the unloaded with the fully (module-)loaded kernel,
I would gain perhaps 20% difference. That's not worth writing a new init
script for... and it becomes even less so if you consider the maximum
amount of power/RAM you could theoretically use. Also saving power saves
me money, saving 100K of RAM saves me not a single swapped page :-)
Bottomline: You have your philosophy, that many others share with you
(mostly "end users" for want of a better term), I have mine that also
many people share (mostly "kernel hackers" FWOABT).
Marc
--
Marc Mutz <[EMAIL PROTECTED]> http://marc.mutz.com/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics
PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)
