[When last I checked, the HOWTO maintainers were continuing to
ignore _all_ of these corrections. -- RM]

From: rick@linuxmafia.com
To: kevin@tummy.com, dave@linuxsecurity.com
Date: [some time around April 2000]

Hello, guys. You may remember me as the fellow who pointed out the AIDE
integrity-checker (http://www.cs.tut.fi/~rammer/aide.html) for the
Security HOWTO.

In http://www.linuxdoc.org/HOWTO/Security-HOWTO-5.html#ss5.3 , you guys
state: "You can find the open sourced version of Tripwire at
http://www.tripwire.org ...." Um, no, you cannot. Tripwire remains
a PROPRIETARY product, with a _viewable-source_ (as opposed to open
source) licence. This _may_ change, but the signs aren't good.[1]

I therefore hope you will revise the Security HOWTO, to remedy the
impression it gives to the contrary.


[1] To update the above e-mail: Late in the year 2000, Tripwire, Inc.
released a new version of Tripwire under the GNU GPL. Unfortunately,
it turned out to be a poorly portable C++ hairball with no autoconf
support, which accounts in part for the contining popularity of AIDE
and another GPLed newcomer, Integrit.

Date: Sun, 21 May 2000 23:30:42 -0700
To: kevin@tummy.com, dave@linuxsecurity.com
Subject: More suggestions/corrections for Security HOWTO
User-Agent: Mutt/1.1.5i

The list below ended up being a lot longer than I expected. If you'd
like me to just edit your LinuxDoc or DocBook originals, I could --
just after I finish a distribution roundup for Marjorie Richardson.

(Below, quotations from the HOWTO are indented. Comments are

-- Rick M.

    3.3 Boot Loader Security 

lilo password option:  You might want to add that /etc/lilo.conf should
be set to permissions "600", if you use this.

    3.5 Detecting Physical Security Compromises

    The first thing to always note is when your machine was rebooted. 

Might want to suggest that the sysadmin's .bash_profile include invoking

    Make sure you remove inactive accounts 

A few words about how to identify inactive accounts (e.g., using
/usr/bin/lastlog) would be helpful, here.

    Be aware when/where they login from, or should be logging in from. 

You can suggest they control this using hosts.allow & hosts.deny,
including the need to compile sshd to use libwrap.  (I see you cover
this in section 8.2.)

    4.2 Root Security

    Provide your users with a default alias to the rm command to ask for
    confirmation for deletion of files.

You know, personally, I would have included this suggestion only to
stress what a _bad idea_ it is.  Users become accustomed to the alias,
and then suffer disaster when they work in an environment that lacks it.

    Never use the rlogin/rsh/rexec suite of tools (called the
    r-utilities) as root. They are subject to many sorts of attacks, 
    and are downright dangerous when run as root. Never create a 
    .rhosts file for root.

Just a thought:  I'm considering adding a line to /usr/sbin/adduser,
to create a root-owned, zero-length .rhosts file in new users'
directories.  This is useful for sites whose security policy classes
the r-utilities as too dangerous for any user.

(I like your PAM trick, section, 6.5, to do the same thing.  Neat!)

    Any program that offers a shell escape will give root access to a
    user invoking it via sudo. 

An anecdote about sudo:  At Linuxcare, when we rebuilt some of the
servers, one of my sysadmins told me I had no need to possess the root
passwords.  (I was his boss.)  I gave him a funny look, but he was
right:  /etc/sudoers gave me the right to do anything necessary, while
maintaining a superior record of what everyone did as root.

So, sudo _definitely_ provides accountability benefits even on processes
having shell escapes.

    There should never be a reason for users' home directories to allow
    SUID/SGID programs to be run from there. Use the nosuid option in
    /etc/fstab for partitions that are writable by others than root.
    You may also wish to use nodev and noexec on users' home partitions,
    as well as /var, thus prohibiting execution of programs, and
    creation of character or block devices, which should never be
    necessary anyway. 

There are other directories you (arguably) missed.  Here's my

# /etc/fstab: static file system information.

/dev/sda2  /            ext2   defaults,errors=remount-ro           0 1
/dev/sdb3  none         swap   sw                                   0 0
proc       /proc        proc   defaults                             0 0
/dev/sda1  /boot        ext2   ro,noauto,nouser,noexec,nosuid,nodev 0 2
/dev/sda3  /usr         ext2   ro,nodev                             0 2
/dev/sda4  /usr/local   ext2   defaults                             0 2
/dev/sdb1  /var         ext2   rw,nosuid,nodev                      0 2
/dev/sdb2  /tmp         ext2   rw,nosuid,nodev                      0 2
/dev/sdb4  /home        ext2   rw,nosuid,nodev                      0 2
/dev/fd0   /mnt/floppy  ext2   noauto                               0 0

I would argue against noexec for /home, as users should be entitled
to populate ~/bin.
      Set filesystem limits instead of allowing unlimited as is the
      default. You can control the per-user limits using the 
      resource-limits PAM module and /etc/pam.d/limits.conf.

Setting limits via /etc/login.defs provides the exact same facilities.

     5.3 Integrity Checking 

     Another very good way to detect local (and also network) attacks on
     your system is to run an integrity checker like Tripwire, Aide or
     Osiris.  These integrety checkers

Typo alert.  It also repeats, three paragraphs further on.  

     5.4 Trojan Horses

     "Trojan Horses" are named after the fabled ploy in Homer's "Iliad".
     The idea is that a cracker distributes a program or binary that
     sounds great, and encourages other people to download it and run it
     as root. Then the program can compromise their system while they
     are not paying attention.  While they think the binary they just
     pulled down does one thing (and it might very well), it also
     compromises their security. 

    You should take care of what programs you install on your machine.
    Redhat provides MD5 checksums and PGP signatures on it's RPM

Typo alert:  You mean "its".

    6.1 PGP and Public-Key Cryptography


    There is a project working on a free re-implementation of pgp with
    open source. GnuPG is a complete and free replacement for PGP.
    Because it does not use IDEA or RSA it can be used without any
    restrictions.  GnuPG is nearly in compliance with OpenPGP.

It is fully in compliance with OpenPGP, and has reached version 1.0
without exaggeration.  You can thus probably stop referring to it as
"a project working on".

    6.2 SSL, S-HTTP, HTTPS and S/MIME

It might be worth mentioning that _any_ network protocol can be
retrofitted with SSL, including, say, POP3, using Rick Kaseguma's 
sslwrap utility.  It calls Eric Young's ssleay libarry.  

Also, somewhere in the HOWTO, you should consider mentioning that
Security Dynamics's USA patent on the RSA algorithm expires on
2000-09-20, which will improve the USA legal climate for SSL, SSH,
RC5, https, S/MIME, and probably a number of other things.

    6.3 Linux IPSEC Implementations

    As with other forms of cryptography, it is not distributed with the
    kernel by default due to export restrictions. 

As of the 2000-01-14 Export Administration Regulations amendments, 
it's legal again, and the USA kernel.org sites now carry some crypto.
But it might be worth mentioning that some crypto kernel patches are
available only at ftp://ftp.kerneli.org/pub/linux/kerneli/net-source/,
and 2.2 and earlier International Kernel Patches in directories off

(I see you do mention the related Web page in section 7.)

    6.4 ssh (Secure Shell) and stelnet 

    ssh and stelnet are suite's of programs

Typo alert:  You mean "suites".

    There are several ssh implementiations now. The original commercial
    implementation by Data Fellows can be found at The ssh home page can be
    found at http://www.datafellows.com.          ^

Typo alert.

    The excellent Openssh implementation is based on a early version of
    the datafellows ssh and has been totally reworked to not include any
    patented or propriatary peices. It is free and under a BSD liscence.
                      ^      ^                                   ^

Typo typo typo.  ;->

    You can also use ssh from your Windows workstation to your Linux ssh
    server. There are several freely available Windows client implementations,

I have a list of all known versions (server and client) for all
platforms, at http://linuxmafia.com/pub/linux/security/ssh-clients

    6.11 X11, SVGA and display security 

    You can also use ssh (see ssh , above) to allow secure X connections.

It might be worth mentioning that a non-root user can run X programs as
root by first sshing to root@localhost.  ssh X-forwarding works even

    7.2 2.2 Kernel Compile Options 

You realise you're soon going to need a section on netfilter/iptables,
right?  Want me to write one?

    8.2 System services and tcp_wrappers


    If you know you are not going to use some particular package, you
    can also delete it entirely. rpm -e packagename under the Red Hat
    distribution will erase an entire package. Under debian dpkg
    --remove does the same thing.                    ^     ^

Typo alert.  You mean "Debian, ".

    You should check /etc/rc.d/rc[0-9].d (on Red Hat; /etc/rc[0-9].d on
    Debian), and see if any of the servers started in those directories
    are not needed. The files in those directories are actually symbolic
    links to files in the directory /etc/rc.d/init.d (on Red Hat;
    /etc/init.d on Debian).  Renaming the files in the init.d directory
    disables all the symbolic links that point to that file. If you only
    wish to disable a service for a particular run level, rename the
    appropriate symbolic link by replacing the upper-case S with a
    lower-case s, like this: 

That's exactly what I do.  Red Hat now tells admins to use chkconfig,
which disables by turning S into K, enables by turning K into S -- in
all applicable runlevels.  I prefer your method, but you should be
aware of what those guys are doing lately.

    Most Linux distributions ship with tcp_wrappers "wrapping" all your
    TCP services.

Again, if admins add new services such as sshd, they may want to 
configure the source tree to include libwrap (and PAM support).

    8.9 NIS (Network Information Service) (formerly YP).


    There is a much more secure replacement for NIS, called NIS+.

Yes, but there isn't _really_ NIS+ support for Linux.  What little
is in glibc2.1 isn't in any way a decent NIS+ implementation.

I came up with a secure and satisfactory replacement for NIS/NIS+
at Linuxcare:  Set up a master reference /etc/passwd /etc/shadow,
/etc/group set on a designated machine (with backup), and then
propagate it out to all other machines via rsync over ssh.  Replace
/usr/bin/passwd with a wrapper that ssh'es to the master machine,
runs _its_ /usr/bin/passwd, and then forces an rsync update to all
machines.  (There were a few other utilities that had to be replaced
with similar wrappers, including chfn and chsh.)  rsync's efficiency
makes this practical.

    9.1 Make a Full Backup of Your Machine


    If you have less than 650mb of data to store on a partition, a CD-R
    copy of your data is a good way to go

But only if you have a spare 650 MB partition to build the ISO9660
image file.  People tend to overlook that.

Also, any backup regimen needs periodic test restores.  This should be

    9.2 Choosing a Good Backup Schedule 

    A six-tape cycle is easy to maintain. This includes four tapes for
    during the week, one tape for even Fridays, and one tape for odd
    Fridays. Perform an incremental backup every day, and a full backup 
    on the appropriate Friday tape. If you make some particularly 
    important changes or add some important data to your system, a 
    full backup might well be in order. 

I'd strongly recommend differential backups over incremental ones.
With your incremental scheme, the Thursday tape is useless if the
Monday, Tuesday, _or_ Wednesday tape has a defect.  And so on.

    9.3 Backup Your RPM or Debian File Database

FYI, the Debian equivalent of /var/lib/rpm/fileindex.rpm and
/var/lib/rpm/packages.rpm is /var/lib/dpkg/status .  It's an
ASCII text file (and easy to repair if necessary, by the way).

    13. Frequently Asked Questions


    However, in order to load modules, you must be root. The module
    object files are also only writable by root. This means the intruder
    would need root access to insert a module. If the intruder gains
    root access, there are more serious things to worry about than
    whether he will load a module.

I believe the main concern is that the cracker's processes might become
_undetectable_ if implemented as substitutes for real kernel modules.

    2. Why does logging in as root from a remote machine always fail? 

    Answer: See Root Security. This is done intentionally to prevent
    remote users from attempting to connect via telnet to your machine
    as root, which is a serious security vulnerability, because then the
    root password would be transmitted, in cleartext, across the network.

That's not it:  If the user telnets in as a non-root user and su's to
root, the root password will _still_ be transmitted in cleartext 
across the network.  

The real reason is to ensure that a record is kept of which remote
username became root, by forcing the two-step process described above.
Of course, cautious admins will ssh in rather than telnet in -- and
disable root-user ssh access in /etc/sshd_config .

    3.How do I enable shadow passwords on my Red Hat 4.2 or 5.x Linux


    To enable shadow passwords, run pwconv as root,

pwconv and pwunconv are _not_ Red Hat-specific.  They exist for (as far
as I know) all distributions.

    4.How can I enable the Apache SSL extensions?

Good news!  You can remove the references to (specifically) Apache
1.2.5, as your method is valid for later versions, as well.

    5.How can I manipulate user accounts, and still retain security? 

    Answer: The Red Hat distribution, especially RH5.0, contains a
    great number of tools to change the properties of user accounts. 

    o  The pwconv and unpwconv programs can be used to convert
       between shadow and non-shadowed passwords. 
    o  The pwck and grpck programs can be used to verify proper
       organization of the passwd and group files. 
    o  The useradd, usermod, and userdel programs can be used to
       add, delete and modify user accounts. The groupadd, groupmod, and
       groupdel programs will do the same for groups. 
    o  Group passwords can be created using gpasswd. 

Again, none of these utilities is specific to, or original to, Red Hat.