Network Security - Monolithic or Modular?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Hello Linux Greybeards,

I am interested in your input on the issue of which of the following makes
for better network security under Linux.

a) compile everything you need into the kernel proper, eliminating any
module loading.  Please confirm that it is possible to completely turn off
module loading in the kernel.

b) compile as little as possible into the kernel proper, with most
functionality provided by loadable modules.

From my reading, the second alternative allows for better tunability since
you can unload and reload the modules (perhaps with different parameters)
without having to reboot.  Apparently there is room for an
unauthorized module to get loaded though.  How would that be prevented?
On the other hand, even if everything is contained inside the kernel, it
is still possible to alter the behavior of the running kernel on the fly
by writing to /proc.  Is that absolutely necessary for linux to run
properly and if not, how is a rogue process prevented from doing it?

Assuming the objective is to maximize network security, which is the better
approach and why?  It seems as if either alternative is possible these
days when a gigabyte of memory costs a hundred dollars, so which is best?

Re: Network Security - Monolithic or Modular?

John wrote:

Quoted text here. Click to load it

Dumb speculative question.

There is big long list of questions one should be asking to decide how
secure one's system is. This is way near the bottom and the answer really
depends on the previous answers. You've also omitted a possible answer
which will often be the the 'right' one i.e.

c) don't mess about with things with things the support staff don't fully

But assuming that you are justified in trying to differentiate between a & b
- AFAIK there is no planned way to insert code into a running kernel via
the proc interface. But that's no excuse not to be hardening your system,
scanning for rootkits, running IDS and anti-sniff etc.


Re: Network Security - Monolithic or Modular?

John sez:
Quoted text here. Click to load it

Irrelevant: if an evil hacker can get to the kernel, your network
security's already been r0073d beyond repair.

Yes, Java is so bulletproofed that to a C programmer it feels like being in a
straightjacket, but it's a really comfy and warm straightjacket, and the world
would be a safer place if everyone was straightjacketed most of the time.
                                                      -- Mark 'Kamikaze' Hughes

Re: Network Security - Monolithic or Modular?

Quoted text here. Click to load it

This question cannot be answered right away, and it is not related to
security.  There are a lot of things to consider, before you can make
that decision.  Firstly, what kind of host is it?  If it is a
workstation, then you are not going to turn off module loading anyway,
because many third party drivers come as kernel modules.

If you are that afraid of kernel module loading, but you cannot turn it
off, then you can harden your system with SELinux or grsecurity.
Personally I use the latter one (but not because of module loading).
They have in common that you can destroy the possibility to load modules
as root.  So you add some kind of user, which is 'above root', and the
root user becomes less privileged.

Now to the /proc interface, and as of Linux 2.6, also to the /sys
interface.  Important configuration options can be changed there, and
many system informations can be read.  This is the intention of those
interfaces, so it is not a threat by itself.  Nobody could harm your
system via /proc or /sys as a normal user.  By using one of the two
packages mentioned above, you can restrict write access (and also read
access) to those pseudo-filesystems.  E.g. on my system, only root can
read /proc/sys.  Normal users can't even read it.

To secure your system, all you have to do is to prevent privilege
escalation (this includes not only system privileges, but also network
privileges).  So normal users must not have the possibility to become
root, or read network traffic not intended for them.  If this is the
case, then you don't even need the security packages, and you don't have
to worry about /proc or /sys.

Short:  Configure your system properly, so it doesn't matter whether you
allow module loading or not, or how much read access normal users have
to /proc and /sys.  Securing your system by disclosing system
informations is security by obscurity.  And 'securing' your system by
restricting the root user is even worse.


Re: Network Security - Monolithic or Modular?

On Thu, 30 Mar 2006 12:09:52 +0200, Ertugrul Soeylemez wrote:

Quoted text here. Click to load it
Quoted text here. Click to load it

My system is a standalone workstation, connected to the internet.  I
have no servers running on public interfaces.  I also do not have local
security issues since I am the only user.  I do make backups and store
them offsite for files I don't want to lose.

I'm not building missiles here, just curious about security.

I've read that *most* or *many* rootkits use the loadable kernel mechanism
to "install".  If this happens as a result of a buffer overflow
vulnerability in a program used to access the internet eg a web browser
then it is a fundamental risk that depends on things outside of my
control.  To do my best against that risk I will watch security reports.
If it happens as a result of some system weakness that I can control
then I want to find out what weakness that is.

I'd like to read your "short list" of things to do to prevent
privilege escalation.  I'm going to start by eliminating as many "suid"
permissions as possible and by eliminating the ability for normal users to
execute "su" and "sudo".  What else do you suggest?  Set permissions on
certain executables to 700?

Thanks for your (positive and useful) post.  Your comments about
preventing privelege escalation have focussed my thinking on that as the
fundamental issue - assuming of course that the basic permissions on the
system are sound.  It should be possible to access the internet without
getting a "root kit" or "key logger" installed (in the absence of an
unknown buffer overflow vulnerability).  That's the risk that I'm trying
to reduce.

Thanks again.

Re: Network Security - Monolithic or Modular?

Quoted text here. Click to load it

This already opens a few holes, if you are as paranoid as I am.  Your
backups are offsite.  Are they encrypted?  If yes, are you using proper
encryption methods and a strong key?  If not, then this is already a
security hazard.  Anybody could get their hands on your data.  Now
imagine your hard disk crashes and you have to switch to the backup.
Somebody could have modified it.  In any case, you are going to encrypt
at least your home directory or the whole /home tree (as I do).  As long
as /home has its own partition, this is very easy to setup.

There is always the risk of your password being intercepted (by your
'best friend', when he sits besides you, for example).  There are ways
to defend against this, but they come with other problems.  You might
want to use key-based authentication.  Save your key on a USB stick or
floppy and use it to login.  The key itself should be encrypted as well.
However, I would not do this.  It may well be the case that the disk
gets lost or becomes unreadable, effectively locking you out of your own
system.  It's far better to just make sure that nobody looks over your
shoulder when typing your password.  However, of course there are
keyboard wiretaps.  You can't defend against any possible security

Quoted text here. Click to load it

Yes, and you are certainly not doing wrong being concerned about
security.  In fact, it's just my privacy I want to protect.  Sure, the
government is not going to be interested in my data.  But if I make sure
even they can't get to it, then I'm also secured against my 'best

Quoted text here. Click to load it

Rootkits use kernel modules and a bunch of other things to hide their
presence.  They still give an attacker access without kernel modules.
So preventing kernel module loading is no gain in security, it just
makes online rootkit detection easier.  If anyone gets to root access to
your system, then it's lost anyway.  As already said, better don't rely
on security by obscurity.

Quoted text here. Click to load it

Depends.  By eliminating SUID permissions you theoretically don't gain
any security, because SUID programs are (or should be) written properly
to not allow normal users to do things they are not supposed to do.
Most SUID programs drop their enhanced privileges after initialization.
Personally I don't do this.

Setting executables' permissions to 700 is also no gain in security.  I
assume you are meaning non-SUID programs here.  They are going to be
executed with the user's (reduced) privileges anyway.  It's not only
useless, it even makes things more difficult.  I don't do this either.

Allow 'su' only for persons, who are intended to become other users
(including root).  In your case, this is only you.  Allow the same group
of users full 'sudo' access, but with proper authentication mechanisms.
If you use password authentication for your root account, then sudone
commands should require the same.  To make things more comfortable, sudo
can be configured to remember the login, so you don't have to type the
password each time again.

Now to the 'short list'.  You can express it with a single sentence:
Don't be stupid.  To be more verbose, ...
  * don't run services you don't use
  * don't do things you don't understand
  * configure every service you use by hand; don't rely on the default
  * read the FAQs and manuals; they have good reasons to be
  * if you give remote access to other users, make sure they don't get
    to your data, i.e. set proper permissions on $HOME
  * don't rely on local laws
  * better keep also privacy in mind, instead of only system security,
    because you cannot prevent your system from being compromised

The last item is the most important.  When configuring your system,
always assume the worst case.  Assume someone stealing your hard-disk.
Your system is already compromised then.  He can do far more than some
remote attacker.  If even he cannot get to your data, then your system
is secure.

Quoted text here. Click to load it

There are a few quite different threats, but they are closely related.
In the workstation case, you are going to defend against:
  * privilege escalation (by proper configuration and secure software)
  * information disclosure (by encryption)
  * identity forging (by authentication)
  * denial of service (by various techniques like filtering)
  * physical problems, i.e. theft or damage (by locking your door)

For a workstation, in most cases it's enough to use the 'right'
software, and do frequent backups.  This leads to a little decision
problem, because there is no 'right' program for mail reading.  You use
the 'right' program by not using the 'wrong' program.  So again, this is
not a list of dos, but a list of donts.  So ...
  * don't use Sendmail as your MTA (use Postfix or Exim instead; I don't
    use any MTA)
  * don't use Thunderbird as your mail-reader (I use sylpheed-claws)
  * don't use PGP for mail privacy/authenticity (I use GnuPG)

In fact, you shouldn't even use Firefox, because from time to time
security flaws are found in it.  But I use it, because it's
full-featured and still faster than most other (full-featured) clients.
The security flaws are seldom critical.  When paranoid, add a second
user for web browsing and sudo Firefox.


Re: Network Security - Monolithic or Modular?

Thank you for your post.  I think we share the same attitudes but I don't
think of myself as paranoid.  I'm just *highly offended* at the notion of
unauthorized access to my stuff, which amounts to the same thing.

The toughest step to put in practice is "don't do things you don't
understand" so I am going to read a lot.

Thanks again.  If you wrote a book on this subject I would buy it, by the

Re: Network Security - Monolithic or Modular?

Quoted text here. Click to load it

I for myself don't think, that this is paranoia, too.  Unfortunately
most other people do.  I think, there is a huge difference between
paranoia and security awareness.

Quoted text here. Click to load it

If I would, then it would be a freely available tutortial anyway.  =)


Re: Network Security - Monolithic or Modular?

On Fri, 31 Mar 2006 12:46:41 +0200, Ertugrul Soeylemez wrote:

Quoted text here. Click to load it

True, (for instance and atacker could install a PCI bus sniffer (device))
but you can try, and for instance the new Intel chipsets _do_ in fact try.

However the one talked about here, _can_ effectively be defended against
using either hardware tolkens (for one: banks do) or some kind of S/Key
like one-time-password system.

A free one maybe the OTP support of KTH/Heimdal Kerberos: /

'The' free implementation (defaultly used in *BSD) is OPIE:

For which this trivial patch to get it to build here:

--- opieinfo.c.std      1999-03-11 03:09:53.000000000 +0100
+++ opieinfo.c  2006-04-02 14:41:56.000000000 +0200
@@ -40,9 +40,10 @@
 #include <pwd.h>
 #endif /* HAVE_PWD_H */
 #include "opie.h"
+#include <errno.h>
 /* extern char *optarg; */
-extern int errno, optind;
+int errno, optind;
 static char *getusername FUNCTION_NOARGS

An article on how to use:

And a (some) PAM module(s) for it:


Re: Network Security - Monolithic or Modular?

On Thu, 30 Mar 2006 17:14:54 +0000, John wrote:
Quoted text here. Click to load it

Hope ya'll don't mind me posting to your discussion, but here goes...

* Put /home, /var and /tmp on a seperate partition and mount: nosuid,nodev
* Add some users and groups, for your apps to run under.

If any of those are X11 applications set them up to have desktop access.
To do that, add them to the same group as the user that starts the
X server, 'users' in my case, and put the following in excuteable file:



And in the .xinitrc of the user from which the X server gets started the
following snipped (although one could put it in the 'startx' script too):

if [ -z $XAUTHORITY ]; then

if [ ! -f $XAUTHORITY ]; then
  if ! /bin/touch $XAUTHORITY ; then
    echo "Error: /bin/touch $XAUTHORITY" >&2

if ! /bin/chmod g+r $XAUTHORITY ; then
  echo "Error: /bin/chmod g+r $XAUTHORITY" >&2

* Add groups for suid-bin ownership (please read-on for a script).

Put only users that need the functionality in those groups.

* Set TMP and TMPDIR env-vars to dirs only the user can write to.

On my distro of choise (Slackware) probably put the following in
/etc/profile.d/ - and set it executeable ofcource - on other
distros maybe add it to /etc/profile, or just your ~/.bash


if [ ! -d $HOME/tmp -a "$HOME" != "/" ]; then
  rm -rf $HOME/tmp
  mkdir -p $HOME/tmp

chown $USER $HOME/tmp
chmod 0750 $HOME/tmp

export TMPDIR=$HOME/tmp
export TMP=$TMPDIR

* Create a group for X11 DRI and put only the local-desktop user(s) in it.

In /etc/X11/xorg.conf something like:

Section "DRI"
        Group "dri"
        Mode 0660

groupadd dri
gpasswd -a menno dri

Quoted text here. Click to load it

I just run 'find / -mount -perm +4000 -ls >std_suid.txt' plus the
following script, and put 'menno' in some (atleast: 'xorg', 'su',
'passwd', 'ping' and 'progmail' say) and 'firefox' in none of those.

#   Search for suid binaries, and put them in thier own groups.
# * Note we enable read-access allong with execute for the group
#   as this should allow us to do filesystem backups under an abitrary
#   account, provided that it is a member of all groups ...

if [ -z "$1" ]; then
  echo "Usage: $0 <directory>"
  exit 1

for f in `find "/$DIR" -mount -type f -perm +4000 -print`; do
  # Convert file names to lowercase and stuff it in F
  F=`echo $f |tr '[A-Z]' '[a-z]'`

  # Create groups if they don't already exist
  if ! grep -q "^`basename $F`:" /etc/group; then
    if ! groupadd `basename $F` ; then
      echo "Error: groupadd `basename $F`" >&2

  # See if it's suid
  if [ "`ls -l $f |awk '{print $1}' |cut -c4`" == "s" ]; then

  # See if sgid
  if [ "`ls -l $f |awk '{print $1}' |cut -c7`" == "s" ]; then

  # Change group ownership to our group
  if ! chgrp `basename $F` $f ; then
    echo "Error: chgrp `basename $F` $f" >&2

  # Set the file protection bits:
  if [ "$SUIDEXEC" == "yes" -a "$SGIDEXEC" == "yes" ]; then
    # Both SUID and SGID:
    if ! chmod 6750 $f ; then
      echo "Error: chmod 6750 $f" >&2
  elif [ "$SUIDEXEC" == "yes" ]; then
    # Just SUID:
    if ! chmod 4750 $f ; then
      echo "Error: chmod 4750 $f" >&2
    echo "Warning: this is odd: `ls -l $f`" >&2


Print result:
find  /bin /sbin /usr/bin /usr/sbin -mount -type f -perm +4000 -ls

(Test it out first and) have fun.


Re: Network Security - Monolithic or Modular?

On Sat, 01 Apr 2006 18:07:31 +0200, Menno Duursma wrote:

Quoted text here. Click to load it

You are welcome, of course.  I don't have any comments or questions on
your suggestions right now but I will go away and study them.

I will say that X doesn't give me a warm feeling.  I would like to be able
to install just the video configuration aspects on my system and leave out
all the networking machinery.  I think that would fit under the heading of
"don't install services you don't use".  Perhaps that will soon be
possible - I've read that XOrg is working to break the code into pieces.
That may offer this opportunity.  If so, I will be the first to test it.

Thanks for your input.

Re: Network Security - Monolithic or Modular?

Quoted text here. Click to load it

Networking concepts are the very fundamental nature of X.

Re: Network Security - Monolithic or Modular?

On Sat, 01 Apr 2006 08:46:47 -0800, ynotssor wrote:
Quoted text here. Click to load it

Provided the applications you probably want to use are X11 clients, and
X11 is a network protocol, there isn't much of a way around running a
(network) server to use them... You could however have it use only Unix
domain sockets to connect by starting the server with '-nolisten tcp'

BTW: for access control other then the XAUTHORITY file you could instead
use 'xhost +si:localgroup:users' (maybe put that in ~/.xinitrc then).

IMO it would be nicer if the umask for crateing /tmp/.X11-unix/X*
socket(s) could be set (as Linux file-acces could then disallow 'others')
in like /etc/X11/xorg.conf or some such. The only way i know of to do that
now would be to edit Xtranssock.c in the Xorg source and recompile i guess.

Quoted text here. Click to load it

Indeed (and that is/hasbeen very useful, atleast to me). There are some
ports/forks of the Xorg server that might allow for some thighter
security (or so i read) such as IIUC the OpenBSD one does priv-sep, and
the XGGI one can run non-root entirely: /
(I had to edit '' though, and it took al day to build.)


Re: Network Security - Monolithic or Modular?

On Sat, 01 Apr 2006 16:40:03 +0000, John wrote:
Quoted text here. Click to load it

Well i (myself) have. As daemons ofcource sit on a security boundary
aswell, hence they should be 'secure(ed)'. Most still-maintained network
service provideing ones can drop privileges, however not all default to
doing that (take CUPS for example, to get that to work, add "RunAsUser
yes", "User lp", "Group shadow" (beats be: why it doesn't use initgroups()
or similar to allow primary group "lp" and secondary "shadow" ...))

A good idee also maybe to have SSHd, CUPS, etc, listen _only_ on the
external interface (plus have them use libwrap (tcpwrappers) to boot).

And for (local) privileage escalation even 'syslogd' (although syslog-ng,
wich can drop-privs, exists), 'crond', or the like might be exploitable.

Quoted text here. Click to load it

I have not tryed this (yet), but if nothing else; it some major scores
kewlness points:

(Never mind the papers there to be interesting).


Site Timeline