  LIDS FAQ
  Steve Bremer, steve@clublinux.org
  v.13, May 20th, 2001

  This is the Linux Intrusion Detection System (LIDS) FAQ.
  ______________________________________________________________________

  Table of Contents


























































  1. Introduction to LIDS

     1.1 What is LIDS?
     1.2 Why use LIDS?
     1.3 Where can I obtain LIDS?
     1.4 Which versions of the Linux kernel are supported?
     1.5 Is there a LIDS mailing list?
     1.6 What about an archive?
     1.7 Copyright & Disclaimer
     1.8 Feedback
     1.9 Credit
     1.10 To Do
     1.11 Change Log

  2. Installing LIDS

     2.1 How do I apply the LIDS kernel patch?
     2.2 How do I install the LIDS administration utility lidsadm?
     2.3 What next?
     2.4 When I try to compile lidsadm, gcc reports that lidstext.h doesn't exist.  How do I fix this problem?
     2.5 When I

  3. lidsadm

     3.1 What is lidsadm?
     3.2 What options are available for lidsadm?
     3.3 Gee, thanks.  What are all these options?

  4. LIDS Administration

     4.1 How do I set my LIDS password?
     4.2 How do I change my LIDS password once it is set?
     4.3 What is a LIDS free session and how do I create one?
     4.4 I created a LIDS free session, but LIDS still appears to be active!  What's wrong?
     4.5 How do I tell LIDS to reload its configuration files?
     4.6 Help!!! My system is totally unusable! What do I do?
     4.7 I've updated/moved a system binary.  How do I tell LIDS that the file changed/moved?
     4.8 OK, without rebooting, how do I completely disable LIDS?
     4.9 What does it mean to "seal the kernel"?
     4.10 How do I view the status of my LIDS system?
     4.11 How do I configure the port scan detector in LIDS?
     4.12 What are the subject and object in a LIDS ACL?
     4.13 Can I enable/disable a system capability without modifying /etc/lids/lids.cap and reloading the configuration files?
     4.14 I've reconfigured my LIDS ACLs, but my changes don't seem to take effect.  What's wrong?
     4.15 Why won't lidsadm -L list my ACLs?
     4.16 Is there anyway to reduce the number of LIDS violations that get reported on the console?
     4.17 Should I be concerned about the LD_PRELOAD environment variable with LIDS?
     4.18 When I boot up, the message "read password file error" appears.  How do I fix the problem?

  5. Configuring LIDS

     5.1 How do I protect a file as read only?
     5.2 OK, so how do I protect a directory as read only?
     5.3 How can I hide a file/directory from everyone?
     5.4 How can I protect log files so they can only be appended to?
     5.5 If nothing is allowed to read my /etc/shadow file, how can I authenticate myself to the system?
     5.6 If I protect /etc as read only, how will mount be able to write to /etc/mtab?
     5.7 LIDS complains that it can't write to my modules.dep file during startup.  What's wrong?
     5.8 If I protect my logs as append only, how will logrotated rotate my logs?
     5.9 Why can't I just give my log rotation utility write access to the directory containing my log files so it can rotate them?
     5.10 When LIDS is active, my file systems won't unmount during shutdown.  What do I do?
     5.11 Why can't I start a service that runs on a privileged port as root?
     5.12 Why can't I start a service that runs on a privileged port from an LFS?
     5.13 How do I disable/enable capabilities?
     5.14 Why won't the X Window System work with LIDS enabled?
     5.15 With all of these ACLs, how can I possibly keep track of my configuration?
     5.16 I can't see my /etc/lids directory when LIDS is enabled.  What's going on?
     5.17 How can I give init write access to /etc/initrunlvl so LIDS doesn't complain about it during startup and shutdown?
     5.18 Can a process inherit file ACLs from its parent?
     5.19 Help! I can't seem to get program xyz to work under LIDS.  How do I determine what files/capabilities it needs access to?
     5.20 How do I give passwd the proper permissions to update the /etc/shadow file?
     5.21 Why doesn't ssh or scp work when LIDS is enabled?
     5.22 OpenSSH won't start at boot time.  LIDS reports that
     5.23 Some of my file systems won't unmount at shutdown because I have hidden processes running.  How can I kill them?
     5.24 I just want to start with a basic configuration.  Can you recommend a setup that will provide additional protection and still leave most of my system functioning as normal?

  6. Configuring Security Alerts

     6.1 Which kernel configuration options do I need to select in order to send security alerts through the network?
     6.2 Where do I specify the mail server information and e-mail address to send the LIDS alerts to?
     6.3 LIDS can't seem to deliver alerts to my qmail SMTP server.  Is there a fix for this?

  7. Sample Configurations

     7.1 Basic System Setup
     7.2 Apache
     7.3 qmail
     7.4 dnscache & tinydns (djbdns)
     7.5 Courier-imap
     7.6 MySQL
     7.7 OpenSSH
     7.8 OpenLDAP (slapd)
     7.9 Port Sentry
     7.10 Samba
     7.11 Linux HA heartbeat

  8. LIDS Technical

     8.1 Will LIDS work with a file system other than ext2?
     8.2 Will LIDS run on an SMP system?
     8.3 Will LIDS coexist with Solar Designer's Openwall patch?
     8.4 Will LIDS run on non-Intel hardware?
     8.5 What is the difference between the 0.9.x and 1.0.x versions of LIDS?


  ______________________________________________________________________

  1.  Introduction to LIDS


  1.1.  What is LIDS?

  LIDS is an enhancement for the Linux kernel written by Xie Huagang and
  Philippe Biondi.  It implements several security features that are not
  in the Linux kernel natively.  Some of these include: mandatory access
  controls (MAC), a port scan detector, file protection (even from
  root), and process protection.


  1.2.  Why use LIDS?

  The current Linux setup has many problems that are inherent in many
  versions of *nix.  Probably the single largest problem is the "all
  powerful" root account.  When a process or user has root privileges,
  there is little if nothing to prevent that process or user from
  completely destroying the system.  A malicious user/intruder with root
  access can cause much heartache for us hard working sysadmins.  LIDS
  implements access control lists (ACLs) that will help prevent even
  those with access to the mighty root account from wreaking havoc on a
  system.  These ACLs allow LIDS to protect files as well as processes.


  1.3.  Where can I obtain LIDS?

  www.lids.org


  1.4.  Which versions of the Linux kernel are supported?

  Currently, LIDS supports the latest 2.2.x kernels as well as the new
  2.4  kernel.  Xie has expressed interest in making 2.4 the primary
  kernel for LIDS support.  However, he also has stated he would
  maintain a stable version of LIDS for the 2.2.x series.


  1.5.  Is there a LIDS mailing list?

  Yes.  You can post to the list at any time by e-mailing lids-
  users@lists.sourceforge.net.  However, if you wish to receive messages
  posted to the mailing list, you must subscribe to it.  To subscribe,
  go to http://lists.sourceforge.net/lists/listinfo/lids-user and fill
  out the form.  You will then receive a confirmation request that you
  must reply to.  You can also unsubscribe and change your mailing list
  options from that page.


  1.6.  What about an archive?

  The mailing list archive is located at
  http://www.geocrawler.com/lists/3/SourceForge/9348/0/ The old archive
  can be found at http://groups.yahoo.com/group/lids.


  1.7.  Copyright & Disclaimer

  This document is copyright(c) 2000, 2001 Steve Bremer  and it is a
  FREE document. You may redistribute it under the terms of the GNU
  General Public License.


  The information here in this document is, to the best of Steve's
  knowledge, correct.  However, being human, there is the chance that
  mistakes, bugs, etc. might happen from time to time.

  No person, group, or other body is responsible for any damage to your
  computer(s) and any other losses by using the information in this
  document. i.e.


       THE AUTHORS AND ALL MAINTAINERS ARE NOT RESPONSIBLE FOR ANY
       DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE INFORMA-
       TION IN THIS DOCUMENT.



  1.8.  Feedback

  If you have any questions, comments, suggestions, or corrections for
  this document, please feel free to contact me at steve@clublinux.org.
  I always welcome feedback whether it's good or bad!


  1.9.  Credit

  Special thanks go to:

  o  Xie Huagang - Technical editor and LIDS author.

  o  ``LIDS version'' question.

  o  ``Subject/object'' question.

  o  Philippe Biondi - LIDS author.

  o  Andy Harrelson - Grammar/spelling editor.

  o  Rob Willis - ``OpenSSH'', ``OpenLDAP'', and ``Port Sentry''
     configuration examples.

  o  Fred Mobach - Inspiration and corrections.

  o  David Ranch - I used his excellent Linux IP Masquerade HOWTO as an
     sgml template.  His disclaimer also proved useful.

  o  Austin Gonyou -

  o  Valuable feedback on FAQ.

  o  Alternative fix to the ``lidsadm compile problem''.

  o  ``Warning'' about updating the inode of the /etc/passwd file.

  o  Pavel Epifanov - For a simple fix to the ``lidsadm compile
     problem''.

  o   Justus Pendleton  - ``Samba'' configuration example.

  o   Nenad Micic

  o  For the ``hidden process kill script'' example.

  o  His ``C program'' to kill hidden processes at shutdown.

  o  ``LD_PRELOAD warning.''

  o   Bill Phillips  - For pointing out many reference errors in the PDF
     version.

  o   Szymon Juraszczyk

  o  ``LD_PRELOAD warning.''

  o  Lorn Kay - ``Heartbeat configuration'' for Linux HA.

  o  Bill McKenzie - Additions to ``Portsentry configuration''.


        Linux is a trademark of Linus Torvalds



  1.10.  To Do


  o  Exec domain feature (-d).

  o  Kernel configuration options.

  o  LIDS Debug.





  1.11.  Change Log

  The latest version of this FAQ can be found at
  http://www.clublinux.org/lids/.  Please check the latest version
  before reporting any bugs.

  o  May 20th, 2001.  Version .13


  o  Added ``heartbeat configuration'' for HA Linux.

  o  Added ``read password error'' question.

  o  Added ``basic configuration'' question.

  o  Minor additions to ``portsentry configuration''.

  o  Enhanced (yet again) ``passwd update'' question.

  o  Other minor corrections.


  o  April 1st, 2001.  Version .12


  o  Updated FAQ for new versions of LIDS (1.0.6+ and 0.9.14+).

  o  Added ``warning'' about LD_PRELOAD environment variable.

  o  Updated ``hardware'' question.


  o  March 10th, 2001.  Version .11


  o  Fixed several reference errors in the PDF version (there are still
     a few document conversion problems that need looked at).

  o  Clarified the ``Basic System Setup'' configuration.

  o  Updated the mailing list ``information''

  o  Updated ``passwd'' and ``log rotation'' questions.


  o  March 1st, 2001.  Version .10


  o  Added ``Samba'' configuration example.

  o  Added ``example'' on how to kill hidden processes at shutdown.

  o  Added ``ssh keygen question''.

  o  Enhanced ``passwd update'' question.


  o  February 10th, 2001.  Version .09


  o  Added ``ssh/scp'' question.

  o  Updated ``mailing list'' information.

  o  ``LIDS SMP status'' update.

  o  January 27th, 2001.  Version .08


  o  Modified ``Apache'' configuration so the server root is protected
     as DENY.

  o  Modified ``mysql'' and ``courier-imap'' so their default
     directories are protected as DENY.

  o  Modified ``ssh'' config to work with password authentication.

  o  Added question regarding ``ACL reconfiguration''.


  o  January 25th, 2001.  Version .07

     Added a much simpler fix to the ``lidsadm compile problem''.
     Clarified the ``sealing the kernel'' question (hopefully).  Minor
     corrections.


  o  January 24th, 2001.  Version .06


  o  Removed ACL example from ``/etc/mtab mount'' question because
     /etc/mtab is recreated at system boot and each time a file system
     is unmounted.

  o  Added alternative fix to the ``lidsadm compile problem''.

  o  Minor corrections.


  o  January 22nd, 2001.  Version .05

     Minor additions to Basic System Setup sample configuration.  Added
     section on configuring e-mail alerts.


  o  January 19th, 2001.  Version .04

     Minor correction to ``lidsadm compile problem'' question.


  o  January 17th, 2001.  Version .03

     Added information about the new file ACL inheritance "-i" option in
     LIDS-0.9.12.  Also updated the configuration examples to use the
     "-i" option when required.  Other minor updates including
     information about lidsadm compile problems, enabling/disabling
     capabilities, and how to setup ACLs for a new program.


  o  January 15th, 2001.  Version .02

     Minor corrections.


  o  January 15th, 2001.  Version .01

     Initial release.





  2.  Installing LIDS

  2.1.  How do I apply the LIDS kernel patch?

  Xie has included instructions on how to patch the kernel in the LIDS
  download.  However, I will briefly cover  the necessary steps.  This
  example assumes your kernel sources are installed in /usr/src/linux.



  o  First you need to download the LIDS patch from
     www.lids.org/download.html.  Make sure you get the version that
     matches your kernel.

  o  Then, expand the tarball:


     $ tar zxvf lids-<lids_version>-<kernel_version>.tar.gz



  o  Apply the lids patch to the existing kernel sources:


     $ cd /usr/src/linux
     $ patch -p1 < /path/to/lids/patch/lids-<lids_version>-<kernel_version>.patch



  o  Then configure your kernel.  For an excellent source of information
     on recompiling your Linux kernel, see the Linux Kernel HOW-TO.

     There are several kernel configuration options for LIDS.  In order
     for LIDS to work, you must make sure the following options are
     enabled:

       [*]   Prompt for development and/or incomplete code/drivers
       [*]   Sysctl Support





  2.2.  How do I install the LIDS administration utility lidsadm?

  The source for the lidsadm utility is located in the directory
  containing your LIDS source and is called:

  lidsadm-<lids_version>



  (NOTE: If you are upgrading lidsadm, you should backup everything in
  the /etc/lids directory first!)



  To compile and install lidsadm, simply:

  $ make
  $ su -
  # make install




  from the lidsadm source directory. This will install lidsadm in the
  /sbin directory.  It will also create an /etc/lids directory and place
  a few default configuration files in it for you.

  If you wish to use the view option with lidsadm, replace the

  $ make



  with

  $ make VIEW=1




  2.3.  What next?

  Before you reboot into your LIDS enhanced kernel, you should configure
  your LIDS ACLs first.  Otherwise your system may be unusable when you
  reboot.  Configuring LIDS ACLs is covered ``later''.


  2.4.  When I try to compile lidsadm, gcc reports that lidstext.h
  doesn't exist.  How do I fix this problem?

  This happens on systems where /usr/include/linux is not a symbolic
  link to /usr/src/linux/include/linux.  The complete error message is:

   lidsadm.c:30: linux/lidsext.h: No such file or directory make: *** [lidsadm.o] Error 1



  To fix this problem, edit the Makefile in the lidsadm source directory
  and add -I/usr/src/linux/include to the CFLAGS option.

  At this point, you should be able to compile lidsadm normally.


  2.5.  When I upgraded  to LIDS version 0.9.14, 0.9.15, 1.0.6, or 1.0.7
  my system panics during reboot.  How do I fix it?

  The format of the /etc/lids/lids.conf file changed in these releases.
  You need to recreate the file using the new version of lidsadm.



  3.  lidsadm

  3.1.  What is lidsadm?

  lidsadm is the LIDS administration utility that you will use to
  configure LIDS to enhance your system security.


  3.2.  What options are available for lidsadm?

  To get a list of the available options, enter the following:

  # lidsadm -h



  This will return the following output:

  ./lidsadm v1.0.6 for LIDS project
          Huagang Xie<xie@gnuchina.org>
                  Philippe Biondi <philippe.biondi@webmotion.net>

  Usage: ./lidsadm -A [-s subject] -o object [-d] -j ACTION
         ./lidsadm -D [-s file] [-o file]
         ./lidsadm -Z
         ./lidsadm -U
         ./lidsadm -L
         ./lidsadm -P
         ./lidsadm -[S|I] -- [+|-][LIDS_FLAG] [...]
         ./lidsadm -V
         ./lidsadm -h

  Commands:
         -A  To add an entry
         -D  To delete an entry
         -Z  To delete all entries
         -U  To update dev/inode numbers
         -L  To list all entries
         -P  To encrypt a password with RipeMD-160
         -S  To submit a password to switch some protections
         -I  To switch some protections without submitting password (sealing time)
         -V  To view current LIDS state (caps/flags)
         -h  To list this help

  subject:
          can be any program,must be file
  object:
          can be file,directory, or special device
          such as MEM,HD,NET,IO,HIDDEN,KILL
  ACTION:
          READ    read only
          APPEND  append only
          WRITE   writable
          GRANT   grant capability to subject
  TYPE:
              -d  the object is a EXEC Domain

  Available capabilities:
             CAP_CHOWN chown(2)/chgrp(2)
      CAP_DAC_OVERRIDE DAC access
   CAP_DAC_READ_SEARCH DAC read
            CAP_FOWNER owner ID not equal user ID
            CAP_FSETID effective user ID not equal owner ID
              CAP_KILL real/effective ID not equal process ID
            CAP_SETGID setgid(2)
            CAP_SETUID set*uid(2)
           CAP_SETPCAP transfer capability
   CAP_LINUX_IMMUTABLE immutable and append file attributes
  CAP_NET_BIND_SERVICE binding to ports below 1024
     CAP_NET_BROADCAST broadcasting/listening to multicast
         CAP_NET_ADMIN interface/firewall/routing changes
           CAP_NET_RAW raw sockets
          CAP_IPC_LOCK locking of shared memory segments
         CAP_IPC_OWNER IPC ownership checks
        CAP_SYS_MODULE insertion and removal of kernel modules
         CAP_SYS_RAWIO ioperm(2)/iopl(2) access
        CAP_SYS_CHROOT chroot(2)
        CAP_SYS_PTRACE ptrace(2)
         CAP_SYS_PACCT configuration of process accounting
         CAP_SYS_ADMIN tons of admin stuff
          CAP_SYS_BOOT reboot(2)
          CAP_SYS_NICE nice(2)
      CAP_SYS_RESOURCE setting resource limits
          CAP_SYS_TIME setting system time
    CAP_SYS_TTY_CONFIG tty configuration
            CAP_HIDDEN Hidden process
         CAP_INIT_KILL Kill init children

  Available flags:
           LIDS_GLOBAL LIDS itself

           RELOAD_CONF reload config. file and inode/dev of special programs
                  LIDS (de)activate LIDS locally (the shell & childs)




  3.3.  Gee, thanks.  What are all these options?

  lidsadm has a syntax similar to IPCHAINS.  Some of the command line
  switches are the same.


  o   -A  = Add a rule.

  o   -D  = Delete a rule.

  o   -L  = List all existing rules.

  o   -h  = lidsadm help.

  o   -Z  = Delete all existing rules.

  o   -U  = Update the device/inode numbers of all files.

  o   -P  = Create/update the LIDS password.

  o   -V  = View current LIDS state (capabilities/flags).

  o   -S  = Make changes to your LIDS enabled system (requires LIDS
     password set by option "-P").

  o   -s  = Specifies a subject file.

  o   -o  = Specifies an object file.

  o   -j  = Specifies a target.

  o   -I  = Seals the kernel.  Used at the end of the startup process.

  o   -i  = Specifies that children of the subject will inherit this
     file ACL or capability (NOTE: "-i" options isn't listed above).


  lidsadm also uses "TARGETS" similar to ipchains.  The following
  targets are allowed:


  o   READ        -  Set access permissions to read only.

  o   APPEND      -  Set access permissions to append only (includes
     read access).

  o   WRITE       -  Set access permissions to read/write.

  o   DENY        -  Deny access to this object.

  o   IGNORE      -  Ignore any permissions set on this object.


  o   GRANT       -  Grant the specified capability to the subject.

  NOTE: The first five TARGETS apply to file ACLs, and the last TARGET
  only applies to capabilities.



  4.  LIDS Administration

  4.1.  How do I set my LIDS password?

  Before you reboot into your LIDS enhanced kernel, enter the following
  at the command prompt:

  # lidsadm -P



  You will then be prompted for a LIDS password:

  MAKE
  enter password:
  Verifying enter password:



  This will write your RipeMD-160 encrypted password to the
  /etc/lids/lids.pw  file.


  4.2.  How do I change my LIDS password once it is set?

  You must first create a ``LIDS free session''.  Then set your password
  using the "-P" option just like you did ``the first time'' (you will
  not be prompted for your current password).  After resetting your LIDS
  password, you must tell LIDS to ``reload its configuration files''.


  4.3.  What is a LIDS free session and how do I create one?

  A LIDS free session (LFS) is a terminal session that is not restricted
  by LIDS.  This option is available so you can administer your system
  without having to reboot into a non-LIDS kernel.  In order for this to
  work, you must have selected this option when you compiled your LIDS
  enhanced kernel:

    [*] Allow switching LIDS protections


  To create an LFS, enter the following at the prompt:


  # lidsadm -S -- -LIDS



  You will then be prompted for your LIDS password.  This terminal is
  now LIDS free.  It will remain LIDS free until you:


  o  Enable LIDS again (lidsadm -S -- +LIDS).

  o  Log out of the terminal.

  You can only have one LFS active at any one time.  Even though
  lidsadm -S -- -LIDS  will not fail if entered on another terminal, you
  can have only one LFS.


  4.4.  I created a LIDS free session, but LIDS still appears to be
  active!  What's wrong?

  This can happen if you create an LFS on a virtual console and then
  switch to another virtual console and try to administer your machine.
  To clear it up, try enabling LIDS and then disabling it again
  (entering passwords when prompted):


  # lidsadm -S -- +LIDS
  # lidsadm -S -- -LIDS




  4.5.  How do I tell LIDS to reload its configuration files?

  In order for LIDS to be able to reload its configuration files, you
  must enable this option when you configure your LIDS enhanced kernel:

    [*]  Allow switching LIDS protections
    (3)    Number of attempts to submit password
    (30)     Time to wait after a fail (seconds)
    [ ]    Allow remote users to switch LIDS protections
    [ ]    Allow any program to switch LIDS protections
    [*]    Allow reloading config. file   <----------------------------



  NOTE: You must allow switching LIDS protections in order to enable
  reloading of configuration files.

  From an LFS (or with LIDS_GLOBAL disabled), execute the following
  command to instruct LIDS to reload its configuration files:

  # lidsadm -S -- +RELOAD_CONF



  This will reload the following configuration files:

  o   /etc/lids/lids.conf  -  LIDS ACL configuration file.

  o   /etc/lids/lids.cap   -  LIDS capabilities file.

  o   /etc/lids/lids.pw    -  LIDS password file.

  o   /etc/lids/lids.net   -  LIDS mail alert configuration file.


  4.6.  Help!!! My system is totally unusable! What do I do?

  You can reboot into a non-LIDS enhanced kernel, or boot into your LIDS
  enhanced kernel with LIDS disabled to try and patch things up.  To
  boot with LIDS disabled, specify  security=0  at the lilo prompt.  For
  example, if your LIDS enhanced kernel is called  lids-kernel  you
  would enter the following at the lilo prompt:


  lilo: lids-kernel security=0



  That's the easy part.  The difficult part is getting your LIDS enabled
  system to shutdown.  You may not be able to shutdown successfully
  depending on your LIDS configuration.

   WARNING:   Rebooting your LIDS enabled system when it is not properly
  configured can cause file system corruption and/or loss of data!!


  4.7.  I've updated/moved a system binary.  How do I tell LIDS that the
  file changed/moved?

  Whenever the device that a file resides on, or a file's inode number
  changes, you must update your  /etc/lids/lids.conf  file with the
  proper information.  Fortunately, Xie has provided us with an option
  just for this occasion:


  # lidsadm -U



  You must then ``reload the configuration files''.


  4.8.  OK, without rebooting, how do I completely disable LIDS?

  Besides using an LFS, LIDS can be turned off globally.  This will only
  work if you compiled the option into your kernel.

  # lidsadm -S -- -LIDS_GLOBAL



  When  LIDS_GLOBAL  is disabled, your system will operate like a
  "normal" Linux system.  To re-enable LIDS globally, perform the
  opposite:


  #lidsadm -S -- +LIDS_GLOBAL



  NOTE: This will not affect your LFS if you currently have one enabled.


  4.9.  What does it mean to "seal the kernel"?

  At the end of the bootup process, you should seal the kernel.  This
  sets the global capabilities on your system according to your
  /etc/lids/lids.cap file.  File ACLs are enforced even before the
  kernel is sealed, however.  To seal the kernel, put the following at
  the end of your rc.local (assuming SysV style init):


  /sbin/lidsadm -I



  The "-I" option is only used to seal the kernel.  After it's sealed,
  you must use the "-S" option to make changes to your system.

   WARNING:  If you do not seal your kernel at boot time, you will not
  receive the full benefits of a LIDS enhanced system.



  4.10.  How do I view the status of my LIDS system?

  In order to use the "-V" option, you must have compiled lidsadm with
  make VIEW=1  ``(see above)''.

  At the command line, enter:

  # lidsadm -V



  This will produce output similar to the following on a 2.2.x kernel:


  VIEW
                       CAP_CHOWN 0
                CAP_DAC_OVERRIDE 0
             CAP_DAC_READ_SEARCH 0
                      CAP_FOWNER 0
                      CAP_FSETID 0
                        CAP_KILL 0
                      CAP_SETGID 0
                      CAP_SETUID 0
                     CAP_SETPCAP 0
             CAP_LINUX_IMMUTABLE 0
            CAP_NET_BIND_SERVICE 0
               CAP_NET_BROADCAST 0
                   CAP_NET_ADMIN 0
                     CAP_NET_RAW 0
                    CAP_IPC_LOCK 0
                   CAP_IPC_OWNER 0
                  CAP_SYS_MODULE 0
                   CAP_SYS_RAWIO 0
                  CAP_SYS_CHROOT 0
                  CAP_SYS_PTRACE 0
                   CAP_SYS_PACCT 0
                   CAP_SYS_ADMIN 0
                    CAP_SYS_BOOT 1
                    CAP_SYS_NICE 0
                CAP_SYS_RESOURCE 1
                    CAP_SYS_TIME 0
              CAP_SYS_TTY_CONFIG 0
                      CAP_HIDDEN 1
                   CAP_INIT_KILL 0
                     LIDS_GLOBAL 1
                                 0
                     RELOAD_CONF 0
                            LIDS 0



  As you can see from the output above, this system has an LFS active.
  However, LIDS is enabled globally.  The items with a "1" next to them
  are enabled, and those items with a "0" next to them are disabled.
  Except for the last two capabilities, root normally has all of the
  above capabilities.  Thanks to LIDS, root only has capabilities
  CAP_SYS_BOOT, CAP_SYS_RESOURCE, and CAP_HIDDEN in this particular case
  (NOTE: CAP_HIDDEN isn't a capability provided by the standard Linux
  kernel).


  4.11.  How do I configure the port scan detector in LIDS?

  You don't.  As long as you selected the option when you configured
  your LIDS enhanced kernel, the port scan detector is enabled.

     [*]  Port Scanner Detector in kernel




  4.12.  What are the subject and object in a LIDS ACL?

  The subject is a program that can run on a Linux system, such as a
  binary or shell script.  The object is what the subject wants to
  access.  This includes files, directories, capabilities, etc.


  4.13.  Can I enable/disable a system capability without modifying
  /etc/lids/lids.cap and reloading the configuration files?

  Yes.  However, this method will not save the changes past system
  shutdown.

  To enable a capability:

  # lidsadm -S -- +CAP_SYS_ADMIN



  To disable a capability:

  # lidsadm -S -- -CAP_SYS_ADMIN




  4.14.  I've reconfigured my LIDS ACLs, but my changes don't seem to
  take effect.  What's wrong?

  There are two things you should do when re-configuring LIDS:

  1. ``Reload'' the configuration files.

  2. Restart the service or services that your changes affected.


  4.15.  Why won't lidsadm -L list my ACLs?

  lidsadm -L must be used from an LFS or when LIDS_GLOBAL is disabled.
  If neither of those conditions are true, you will see the following
  error message:

  lidsadm: can not open conf file
  reason:: Permission denied
  LIST




  4.16.  Is there anyway to reduce the number of LIDS violations that
  get reported on the console?

  Yes.  The syslog init script can be modified to start klogd with the
  "-c" option.  This options sets the default level of system messages
  that get logged to the console.  Any message with a value less than
  the value specified will appear on the console (see
  include/linux/kernel.h).

  For example:


  klogd -c 4



  Tells klogd to log all messages below level 4 will be logged to the
  console.


  4.17.  Should I be concerned about the LD_PRELOAD environment variable
  with LIDS?

  Yes.  For setuid programs, the LD_PRELOAD env var is "cleansed" so
  that it can't affect the libraries loaded by a program (with the
  exception of recent glibc vulnerabilities).

  Problems arise when you grant special capabilities or file access
  permissions to non-setuid binaries.  Since the LD_PRELOAD env var
  isn't "cleansed" before loading libraries, someone with malicious
  intent could load a trojaned library and it would have the same
  special capabilities/file access permissions that were given to the
  original program.

  Possible options to reduce your risk:


  o  Any program with special capabilities or file access permissions
     should be restricted with the standard unix file permiUNIXns so
     that not everyone is allowed to execute it (e.g. chmod o-rwx
     /path/to/program )

  o  Another option may be to make the file setuid and change the
     ownerhip to a non-root user.  That way the LD_PRELOAD env var is
     "cleansed" before the program is executed.


  4.18.  When I boot up, the message "read password file error" appears.
  How do I fix the problem?

  This happens when you forget to set the LIDS password before booting
  into LIDS the first time.  To fix the problem, reboot your machine
  (see ``booting an unusable system'') and set your ``LIDS password''.


  5.  Configuring LIDS

  5.1.  How do I protect a file as read only?


  # lidsadm -A -o /some/file      -j READ



  This will prevent anyone (including root) from modifying or deleting
  /some/file  as long as LIDS is enabled.  If you are in an LFS, you are
  free to modify  /some/file  assuming you have appropriate file system
  permissions and the partition isn't mounted read-only.


  5.2.  OK, so how do I protect a directory as read only?

  Same as above, only specify  /some/directory

  # lidsadm -A -o /some/directory  -j READ



  When the object is a directory, LIDS protects the directory itself,
  and it recursively protects everything underneath it  within the same
  file system. (e.g. LIDS ACLs do not cross file system boundaries!)
  This is very important to remember so you don't accidentally leave
  part of your system unprotected.

  A directory that you may want to protect as read only is the /etc
  directory.

  # lidsadm -A -o /etc -j READ




  5.3.  How can I hide a file/directory from everyone?


  # lidsadm -A -o /some/file_or_directory   -j DENY


  Again, this will prevent even root from accessing it.  And, if it is a
  directory, all files and directories underneath it are also hidden
  (within the same file system, of course).


  5.4.  How can I protect log files so they can only be appended to?


  # lidsadm -A -o /some/log/file  -j APPEND


  This will allow someone to write to the end of the file while at the
  same time preventing him/her from erasing or modifying its existing
  contents.

  An easy way to protect your system logs as append only would be:

  # lidsadm -A -o /var/log  -j APPEND



  This will protect all files under  /var/log  as append only.  As with
  READ and DENY, this target is also recursive.


  5.5.  If nothing is allowed to read my /etc/shadow file, how can I
  authenticate myself to the system?

  In order to allow users to authenticate themselves to the system, it
  is necessary to give certain programs read only access to the
  /etc/shadow.  Some of the programs you may want to consider giving
  read access to are: login, sshd, su, and vlock.

  To allow the login program to read /etc/shadow, use the following ACL:

  # lidsadm -A -s /bin/login -o /etc/shadow -j READ


  The "-s" option specifies a subject, which is /bin/login in this case.
  We are giving the subject read only access to the object (/etc/shadow
  in this case).





  5.6.  If I protect /etc as read only, how will mount be able to write
  to /etc/mtab?

  It won't. To fix this problem, you can remove the /etc/mtab file and
  replace it with a symbolic link to /proc/mounts.  In order for this to
  work, you must modify your startup scripts to use the "-n" option with
  every mount and umount command.  This tells mount and umount not to
  update the /etc/mtab file.

  For example, if you find:

  mount -av -t nonfs,noproc



  in your init scripts, you will need to change it to:

  mount -av -n -t nonfs,noproc



  These mount commands may be scattered throughout your init scripts.
  Use grep to make sure you catch them all.  You will also want to
  modify all of the umount commands in the same manner.


  5.7.  LIDS complains that it can't write to my modules.dep file during
  startup.  What's wrong?

  This happens when you protect /lib as read only (a good thing to do).
  The error received is something similar to:


       LIDS: depmod (3 12 inode 16119) pid 13203 user (0/0) on
       tty2: Try to open /lib/modules/2.2.18/modules.dep for writ-
       ing,flag=578



  This occurs during startup because the /etc/rc.d/rc.sysinit init
  script tries to recreate all of your module dependencies.  Normally
  this is not needed because the module dependencies don't change unless
  you add, change, or delete modules.  The error is harmless, but if you
  don't like seeing it, you can simply comment out the line in your
  /etc/rc.d/rc.sysinit script that recreates the module dependencies
  (Look for depmod -a or something similar).


  5.8.  If I protect my logs as append only, how will logrotated rotate
  my logs?


  It won't.  Log rotation is something that will have to be done
  manually by executing your log rotation utility when LIDS_GLOBAL is
  disabled.  You should disable the cron job that initiates log
  rotation.  (See ``below'' for a possible alternative).


  5.9.  Why can't I just give my log rotation utility write access to
  the directory containing my log files so it can rotate them?

  You can, but it's not recommended.  If someone were to break into your
  system, even though they couldn't modify your logs, they could rotate
  them enough times (by executing the log rotation utility manually)
  that the log containing the information gathered during the intrusion
  is dropped off the face of the earth.  This is part of the price you
  pay for high security.


  An alternative solution to giving your log rotation utility write
  access to /var/log, is to give the cron daemon write access to
  /var/log and make it inheritable:

  lidsadm -A -s /usr/sbin/crond -i -o /var/log    -j WRITE



  This prevents someone from manually executing your log rotation
  utility, but  will allow it to work when it is executed by the cron
  daemon.

   WARNING:  If a vulnerability is found in your cron daemon, someone
  could exploit it and wipe your logs since cron would have write access
  to /var/log.  This defeats the purpose of using MAC in the first place
  since your access controls can now be circumvented if a vulnerability
  is found.  Use this option at your own discretion!


  5.10.  When LIDS is active, my file systems won't unmount during shut-
  down.  What do I do?

  This happens when you have disabled the CAP_SYS_ADMIN capability
  globally and have not given the proper authority to unmount your file
  systems to your shutdown script(s).  For example, on Red Hat 6.2, the
  /etc/rc.d/init.d/halt script unmounts your file systems.  You must
  give it the CAP_SYS_ADMIN capability so it can unmount your file
  systems:

  # lidsadm -A -s /etc/rc.d/init.d/halt -o CAP_SYS_ADMIN -i 1 -j GRANT



  The target "GRANT" tells LIDS to grant the subject
  (/etc/rc.d/init.d/halt in this case) the CAP_SYS_ADMIN capability.
  The "-i 1" option sets the "inheritance level" of the ACL to 1.

  Beware that this also allows anyone who can execute your
  /etc/rc.d/init.d/halt script to unmount your file systems.  If you
  have physical access to your box, you may just want to turn off
  LIDS_GLOBAL before shutting down your system rather than grant
  capabilities to your shutdown scripts.  However, if you have a UPS
  that can shutdown your system in case of power failure, you may not be
  around to disable LIDS_GLOBAL.


  5.11.  Why can't I start a service that runs on a privileged port as
  root?

  Services that run a privileged port (those below 1024) require the
  CAP_NET_BIND_SERVICE capability in order to bind to the port.  If you
  have disabled this capability globally in the /etc/lids/lids.cap file,
  you must either grant the program that capability

  # lidsadm -A -s /usr/local/bin/apache -o CAP_NET_BIND_SERVICE -j GRANT


  or, start the service when LIDS_GLOBAL is disabled.





  5.12.  Why can't I start a service that runs on a privileged port from
  an LFS?

  An LFS applies to a single terminal session.  A daemon forks itself in
  order to separate itself from the controlling terminal.  Once this
  happens, it is no longer connected to the LFS on your terminal and is
  now protected by LIDS.


  5.13.  How do I disable/enable capabilities?

  The /etc/lids/lids.cap file contains a list of all the capabilities
  available under a LIDS enhanced Linux kernel.  Those that have a "+"
  in front of them are enabled, and those with a "-" in front of them
  are disabled.  To change the status of a capability, simply edit the
  text file and change the "+" to a "-" to disable a capability and
  vice-versa to enable it.  After you're done editing the file, you must
  tell LIDS to ``reload'' the configuration files.


  5.14.  Why won't the X Window System work with LIDS enabled?

  The X server that you are using requires the CAP_SYS_RAWIO capability.
  Try

  # lidsadm -A -s /path/to/your/X_server -o CAP_SYS_RAWIO -j GRANT




  5.15.  With all of these ACLs, how can I possibly keep track of my
  configuration?

  It is recommended that you create a shell script of all the ACLs that
  you wish to add to your system.  That way you don't accidentally leave
  something unprotected when you make changes to your system.  You can
  start the script out by flushing your old ACLs so you don't create
  duplicates.

  # lidsadm -Z



  To protect this shell script, you can either create an ACL to DENY
  access to it, or put it in the /etc/lids directory since it is
  automatically protected as DENY.


  5.16.  I can't see my /etc/lids directory when LIDS is enabled.
  What's going on?

  LIDS automatically protects the /etc/lids directory with DENY.


  5.17.  How can I give init write access to /etc/initrunlvl so LIDS
  doesn't complain about it during startup and shutdown?

  Unfortunately, there isn't much you can do about this.  Because init
  recreates this file each time you boot, it will have a different inode
  number every time.  This makes it difficult for LIDS to handle.  It is
  a harmless error, and your system will still function properly without
  /etc/initrunlvl.




  5.18.  Can a process inherit file ACLs from its parent?

  Yes.  Up until version 0.9.12-2.2.18, this was the default behavior.
  Now the default is for children not to inherit the file ACLs from
  their parents.  To allow a file ACL to be passed from a parent process
  to a child process, you must use the "-i <inheritance level>" option.

  Where "inheritance level" (a.k.a. TTL) determines how far the ACL is
  inherited.  If the TTL specified is 1, then the subject specified in
  the ACL and all of its children will inherit the ACL.  However, the
  children's children (a.k.a. a grandchild of the subject in the ACL)
  will not inherit the ACL (a TTL of 2 would be needed for this to
  occur).

  Note: These same inheritance rules apply to ACLs that grant
  capabilities.


  5.19.  Help! I can't seem to get program xyz to work under LIDS.  How
  do I determine what files/capabilities it needs access to?

  The first thing to do is simply try running the program and see what
  violations get reported by LIDS.  However, many times this doesn't
  give you enough information.  When this happens, you can try using
  strace to follow the program through and see which system call fails.
  This will usually give you a good indication as to which capability is
  being violated.

  NOTE: If you have disabled CAP_SYS_PTRACE globally, you will need to
  temporarily give strace the CAP_SET_PTRACE capability so it can trace
  your program while LIDS is enabled.


  5.20.  How do I give passwd the proper permissions to update the
  /etc/shadow file?

  Unfortunately there isn't an easy solution.  This is because the
  passwd utility recreates the /etc/shadow file every time you change
  your password.  Because of this, it will start on a different inode
  each time you use the passwd utility successfully.

  For the system administrator, there is an easy work around.  Start an
  LFS and use the passwd utility from within the LFS.  If there are
  users that need to change their passwords, LDAP can provide an
  alternate means of client authentication that will allow users to
  change their passwords.

  There is an option available that will allow users to change their
  system passwords when using the standard unix system filesUNIX
  authentication, but it's not recommended.  /usr/bin/passwd can be
  given write access to /etc so it can always modify the shadow file
  regardless of it's inode number.

   WARNING: If someone were to find a vulnerability in /usr/bin/passwd,
  or any of the libraries/PAM modules that it uses, he/she could
  potentially gain write access to your /etc directory.  This defeats
  the purpose of using MAC in the first place since your access controls
  can now be circumvented if a vulnerability is found.  Use this option
  at your own discretion!

  If you are going to give /usr/bin/passwd write access to /etc, it is
  recommended that you create ACLs to protect every file and directory
  under /etc that you don't want /usr/bin/passwd to be able to modify.
  This will significantly reduce the risk (and possibly completely
  remove it if done correctly) mentioned above.  For example:

  /sbin/lidsadm -A -s /usr/bin/passwd -o /etc/hosts.allow         -j READ
  /sbin/lidsadm -A -s /usr/bin/passwd -o /etc/hosts.deny          -j READ
  /sbin/lidsadm -A -s /usr/bin/passwd -o /etc/rc0.d               -j READ
  /sbin/lidsadm -A -s /usr/bin/passwd -o /etc/rc1.d               -j READ
  /sbin/lidsadm -A -s /usr/bin/passwd -o /etc/rc2.d               -j READ
  /sbin/lidsadm -A -s /usr/bin/passwd -o /etc/rc3.d               -j READ
  /sbin/lidsadm -A -s /usr/bin/passwd -o /etc/rc4.d               -j READ
  /sbin/lidsadm -A -s /usr/bin/passwd -o /etc/rc5.d               -j READ
  /sbin/lidsadm -A -s /usr/bin/passwd -o /etc/rc6.d               -j READ
  /sbin/lidsadm -A -s /usr/bin/passwd -o /etc/init.d              -j READ
  /sbin/lidsadm -A -s /usr/bin/passwd -o /etc/cron.d              -j READ
  /sbin/lidsadm -A -s /usr/bin/passwd -o /etc/pam.d               -j READ
  ...



  The above is not a complete list by any stretch of the imaginiation,
  but it's a start.  Also keep in mind that anytime you add a file or
  directory to /etc that you don't want passwd to have access to, you
  must create a new ACL to protect it.



   A note about updating inodes:


  If you have defined ACLs to grant access to /etc/shadow or /etc/passwd
  you must make sure to tell lids to ``update the inodes'' and then
  ``reload'' it's config files.  Otherwise you may encounter problems.

  For example: Assume /etc/passwd is protected as DENY, and /bin/login
  can read /etc/passwd.  If the inodes aren't updated after changing a
  password, problems may arise the next time someone tries to log in.
  /bin/login won't be able to read /etc/passwd and you won't be able to
  log in, or worse yet, you will be able to login by just pressing the
  <ENTER> key.



  5.21.  Why doesn't ssh or scp work when LIDS is enabled?

  By default, ssh/scp try to use a privileged port for the source port
  when creating an outgoing connection.  This requires the
  CAP_NET_BIND_SERVICE capability.  However, you can specify the
  following option in the ssh_config file to force it to use a port
  above 1023 for the source port:


  UsePrivilegedPort No



  Or, you can grant CAP_NET_BIND_SERVICE to ssh (since scp uses ssh, it
  will work also):


  lidsadm -A -s /usr/bin/ssh -o CAP_NET_BIND_SERVICE      -j GRANT




  5.22.  OpenSSH won't start at boot time.  LIDS reports that bash
  tried to access a hidden file.  How can I fix this?

  This can happen when you protect your private keys with a default
  policy of DENY.  The init script provided in the openssh-server rpm
  checks to see if the private key files exist under /etc/ssh.  If the
  script can't find them, it executes ssh-kegen to generate them.
  Beckeygenthe keys are actually there, ssh-keygen fails and the startup
  script exits.

  To fix this, remove the check for the key files in the startup script:

  start)
        # Create keys if necessary
        #do_rsa_keygen;  <------------ Comment out these lines
        #do_dsa_keygen;

        echo -n "Starting sshd: "
        if [ ! -f $PID_FILE ] ; then
                sshd
                RETVAL=$?
                if [ "$RETVAL" = "0" ] ; then
                        success "sshd startup"
                        touch /var/lock/subsys/sshd
                else
                        failure "sshd startup"
                fi
        fi
        echo
        ;;



   NOTE:  This means the private keys will have to be generated manually
  prior to starting sshd.  Otherwise, it will fail to start.


  5.23.  Some of my file systems won't unmount at shutdown because I
  have hidden processes running.  How can I kill them?

  A hidden process can still be killed if you know it's process id
  (pid).  Many systems store the pid of all the processes started at
  boot time somewhere under /var (/var/run is commonly used).  Your
  shutdown scripts can be modified to read the pids from these files and
  send them the appropriate signals.

  For example, if your system stores the pids in
  /var/run/<process_name>.pid, then you can add the following lines to
  your shutdown scripts:

  for p in `ls /var/run/*.pid`
  do
     kill -15 `cat $p`
  done
  sleep 5
  sync;sync;sync

  for p in `ls /var/run/*.pid`
  do
     kill -9 `cat $p`
  done
  sleep 5
  sync;sync;sync


  The CAP_KILL and CAP_INIT_KILL capabilities must be granted to the
  shutdown script containing these lines.  It is probably a good idea to
  hide the /var/run directory from everything but the init scripts too.

  Another option would be to just send every process the TERM and KILL
  signals.
  MAX_PROC=65535
  trap : 1 2 15
  I=1;while (( $I < $MAX_PROC ));do
          I=$(($I+1));
          if (( $$ != $I ));then
                  kill -15 $I;
          fi;
  done
  sleep 5
  sync;sync;sync;
  I=1;
  while (( $I < $MAX_PROC ));do
          I=$(($I+1));
          if (( $$ != $I ));then
                  kill -9 $I;
          fi;
  done
  sync;sync;sync



  Nenad Micic wrote his own C program to kill hidden processes at
  shutdown.


  5.24.  I just want to start with a basic configuration.  Can you rec-
  ommend a setup that will provide additional protection and still leave
  most of my system functioning as normal?

  A good starting point would be to protect your system binaries and
  libraries:

  /sbin/lidsadm -A -o /bin                        -j READ
  /sbin/lidsadm -A -o /sbin                       -j READ
  /sbin/lidsadm -A -o /lib                        -j READ

  /sbin/lidsadm -A -o /usr/bin                    -j READ
  /sbin/lidsadm -A -o /usr/sbin                   -j READ
  /sbin/lidsadm -A -o /usr/lib                    -j READ



  If /usr/local is on a separate partition, add the following ACLs also:

  /sbin/lidsadm -A -o /usr/local/bin              -j READ
  /sbin/lidsadm -A -o /usr/local/sbin             -j READ
  /sbin/lidsadm -A -o /usr/local/lib              -j READ




  You should also disable CAP_SYS_RAWIO and CAP_SYS_PTRACE in the
  /etc/lids/lids.cap file.  If you don't disable CAP_SYS_RAWIO, then
  someone can override the above file protections by writing directly to
  your devices.

  If you are running the X Window System, please see ``above'' about
  getting X to work under LIDS.




  6.  Configuring Security Alerts



  6.1.  Which kernel configuration options do I need to select in order
  to send security alerts through the network?


  [*]   Send security alerts through network
  [ ]      Hide klids kernel thread
  (3)      Number of connection tries before giving up
  (30)     Sleep time after a failed connection
  (16)     Message queue size
  [*]      Use generic mailer pseudo-script



  The first option enables the use of security alerts.  The second
  option allows you to hide the process that sends the alerts.  Until
  you have your mail notification working, it is recommended that you
  leave this option disabled because it will also prevents error
  messages from being logged.  The last option tells LIDS to use the
  generic mailer script provided with LIDS to send any alert messages to
  your mail server.  This is currently the only option.


  6.2.  Where do I specify the mail server information and e-mail
  address to send the LIDS alerts to?

  All information required for sending security alerts must be
  configured in the /etc/lids/lids.net file.  A description of each
  option is provided in the configuration file itself.  When specifying
  an e-mail address, be sure not to leave any leading or trailing spaces
  around the e-mail address.  This may cause problems with delivery.
  For example, the following two MAIL_TO examples won't work:

  "MAIL_TO= steve@clublinux.org"
  "MAIL_TO=steve@clublinux.org "



  NOTE: The double quotes are used only to show you the trailing space.
  They should not be included in your configuration.

  After making changes to the /etc/lids/lids.net file, you must tell
  LIDS to ``reload'' it's configuration files.


  6.3.  LIDS can't seem to deliver alerts to my qmail SMTP server.  Is
  there a fix for this?

  Yes.  For LIDS versions 0.9.12 and older, a patch is required in order
  to make LIDS e-mail alerts work with a qmail SMTP mail server.  The
  patch can be found here: http://www.egroups.com/message/lids/1896.



  7.  Sample Configurations

  7.1.  Basic System Setup

  The following is a sample configuration for basic system setup.








  # Protect System Binaries
  #
  /sbin/lidsadm -A -o /sbin                               -j READ
  /sbin/lidsadm -A -o /bin                                -j READ

  # Protect all of /usr and /usr/local
  # (This assumes /usr/local is on a separate file system).
  #
  /sbin/lidsadm -A -o /usr                                -j READ
  /sbin/lidsadm -A -o /usr/local                          -j READ

  # Protect the System Libraries
  #(/usr/lib is protected above since /usr/lib generally isn't
  # on a separate file system than /usr)
  #
  /sbin/lidsadm -A -o /lib                                -j READ

  # Protect /opt
  #
  /sbin/lidsadm -A -o /opt                                -j READ

  # Protect System Configuration files
  #
  /sbin/lidsadm -A -o /etc                                -j READ
  /sbin/lidsadm -A -o /usr/local/etc                      -j READ
  /sbin/lidsadm -A -o /etc/shadow                         -j DENY
  /sbin/lidsadm -A -o /etc/lilo.conf                      -j DENY

  # Enable system authentication
  #
  /sbin/lidsadm -A -s /bin/login -o /etc/shadow           -j READ
  /sbin/lidsadm -A -s /usr/bin/vlock -o /etc/shadow       -j READ
  /sbin/lidsadm -A -s /bin/su -o /etc/shadow              -j READ
  /sbin/lidsadm -A -s /bin/su \
                   -o CAP_SETUID                          -j GRANT
  /sbin/lidsadm -A -s /bin/su \
                   -o CAP_SETGID                          -j GRANT

  # Protect the boot partition
  #
  /sbin/lidsadm -A -o /boot                               -j READ

  # Protect root's home dir, but allow bash history
  #
  /sbin/lidsadm -A -o /root                               -j READ
  /sbin/lidsadm -A -s /bin/bash -o /root/.bash_history    -j WRITE

  # Protect system logs
  #
  /sbin/lidsadm -A -o /var/log                            -j APPEND
  /sbin/lidsadm -A -s /bin/login -o /var/log/wtmp         -j WRITE
  /sbin/lidsadm -A -s /bin/login -o /var/log/lastlog      -j WRITE
  /sbin/lidsadm -A -s /sbin/init -o /var/log/wtmp         -j WRITE
  /sbin/lidsadm -A -s /sbin/init -o /var/log/lastlog      -j WRITE
  /sbin/lidsadm -A -s /sbin/halt -o /var/log/wtmp         -j WRITE
  /sbin/lidsadm -A -s /sbin/halt -o /var/log/lastlog      -j WRITE
  /sbin/lidsadm -A -s /etc/rc.d/rc.sysinit \
                   -o /var/log/wtmp -i 1                  -j WRITE
  /sbin/lidsadm -A -s /etc/rc.d/rc.sysinit \
                   -o /var/log/lastlog -i 1               -j WRITE

  # Startup
  #
  /sbin/lidsadm -A -s /sbin/hwclock -o /etc/adjtime       -j WRITE


  # Shutdown
  #
  /sbin/lidsadm -A -s /sbin/init -o CAP_INIT_KILL         -j GRANT
  /sbin/lidsadm -A -s /sbin/init -o CAP_KILL              -j GRANT

  # Give the following init script the proper privileges to kill processes and
  # unmount the file systems.  However, anyone who can execute these scripts
  # by themselves can effectively kill your processes.  It's better than
  # the alternative, however.
  #
  # Any ideas on how to get around this are welcome!
  #
  /sbin/lidsadm -A -s /etc/rc.d/init.d/halt \
                   -o CAP_INIT_KILL -i 1                  -j GRANT
  /sbin/lidsadm -A -s /etc/rc.d/init.d/halt \
                   -o CAP_KILL -i 1                       -j GRANT
  /sbin/lidsadm -A -s /etc/rc.d/init.d/halt \
                   -o CAP_NET_ADMIN -i 1                  -j GRANT
  /sbin/lidsadm -A -s /etc/rc.d/init.d/halt \
                   -o CAP_SYS_ADMIN -i 1                  -j GRANT

  # Other
  #
  /sbin/lidsadm -A -s /sbin/update -o CAP_SYS_ADMIN       -j GRANT





  7.2.  Apache

  This sample configuration assumes Apache was installed in
  /usr/local/apache with a log directory of /var/log/httpd and a
  configuration directory of /etc/httpd.  You can adjust the paths in
  the ACLs to match your own configuration.  With this configuration,
  Apache must be started prior to sealing the kernel, or when
  LIDS_GLOBAL is disabled so it can bind to port 80 (and possibly 443).

  /sbin/lidsadm -A -s /usr/local/apache/bin/httpd \
                   -o CAP_SETUID                          -j GRANT
  /sbin/lidsadm -A -s /usr/local/apache/bin/httpd \
                   -o CAP_SETGID                          -j GRANT

  # Config files
  /sbin/lidsadm -A -o /etc/httpd                          -j DENY
  /sbin/lidsadm -A -s /usr/local/apache/bin/httpd \
                   -o /etc/httpd                          -j READ

  # Server Root
  /sbin/lidsadm -A -o /usr/local/apache                   -j DENY
  /sbin/lidsadm -A -s /usr/local/apache/bin/httpd \
                   -o /usr/local/apache                   -j READ

  # Log Files
  /sbin/lidsadm -A -o /var/log/httpd                      -j DENY
  /sbin/lidsadm -A -s /usr/local/apache/bin/httpd \
                   -o /var/log/httpd                      -j APPEND
  /sbin/lidsadm -A -s /usr/local/apache/bin/httpd \
                   -o /usr/local/apache/logs              -j WRITE







  7.3.  qmail

  These ACLs were written for a qmail setup that was installed according
  to Dave Sill's Life with qmail.  With this configuration, qmail must
  be started prior to sealing the kernel, or when LIDS_GLOBAL is
  disabled so tcpserver can bind to port 25.


  # setup
  /sbin/lidsadm -A -o /var/qmail                          -j READ
  /sbin/lidsadm -A -s /usr/local/bin/multilog \
                   -o /var/log/qmail                      -j WRITE
  /sbin/lidsadm -A -s /usr/local/bin/svc \
                   -o /var/qmail/supervise                -j WRITE

  # queue access
  #
  /sbin/lidsadm -A -s /var/qmail/bin/qmail-inject \
                   -o /var/qmail/queue                    -j WRITE
  /sbin/lidsadm -A -s /var/qmail/bin/qmail-rspawn \
                   -o /var/qmail/queue                    -j WRITE
  /sbin/lidsadm -A -s /var/qmail/bin/qmail-lspawn \
                   -o /var/qmail/queue                    -j WRITE
  /sbin/lidsadm -A -s /var/qmail/bin/qmail-queue \
                   -o /var/qmail/queue                    -j WRITE
  /sbin/lidsadm -A -s /var/qmail/bin/qmail-clean \
                   -o /var/qmail/queue                    -j WRITE
  /sbin/lidsadm -A -s /var/qmail/bin/qmail-send \
                   -o /var/qmail/queue                    -j WRITE
  /sbin/lidsadm -A -s /var/qmail/bin/qmail-remote \
                   -o /var/qmail/queue                    -j WRITE

  # Access to local mail boxes
  /sbin/lidsadm -A -s /var/qmail/bin/qmail-lspawn \
                   -o CAP_SETUID                          -j GRANT
  /sbin/lidsadm -A -s /var/qmail/bin/qmail-lspawn \
                   -o CAP_SETGID                          -j GRANT
  /sbin/lidsadm -A -s /var/qmail/bin/qmail-lspawn \
                   -o CAP_DAC_OVERRIDE                    -j GRANT
  /sbin/lidsadm -A -s /var/qmail/bin/qmail-lspawn \
                   -o CAP_DAC_READ_SEARCH                 -j GRANT


  # Remote delivery
  /sbin/lidsadm -A -s /var/qmail/bin/qmail-rspawn \
                   -o CAP_NET_BIND_SERVICE -i -1          -j GRANT

  # supervise

  /sbin/lidsadm -A -s /usr/local/bin/supervise \
                   -o /var/qmail/supervise/qmail-smtpd/supervise     -j WRITE
  /sbin/lidsadm -A -s /usr/local/bin/supervise \
                   -o /var/qmail/supervise/qmail-smtpd/log/supervise -j WRITE
  /sbin/lidsadm -A -s /usr/local/bin/supervise \
                   -o /var/qmail/supervise/qmail-send/supervise      -j WRITE
  /sbin/lidsadm -A -s /usr/local/bin/supervise \
                   -o /var/qmail/supervise/qmail-send/log/supervise  -j WRITE




  7.4.  dnscache & tinydns (djbdns)

  The following ACLs were written for a djbdns setup based on Jeremy
  Rauch's Installing djbdns (DNScache) for Name Service parts 1 & 2.
  With this configuration, dnscache and tinydns must be started prior to
  sealing the kernel, or when LIDS_GLOBAL is disabled so they can bind
  to port 53.

  # dnscache
  #
  /sbin/lidsadm -A -o /var/dnscache                        -j READ
  /sbin/lidsadm -A -s /usr/local/bin/supervise \
                   -o /var/dnscache/dnscache/supervise     -j WRITE
  /sbin/lidsadm -A -s /usr/local/bin/supervise \
                   -o /var/dnscache/dnscache/log/supervise -j WRITE
  /sbin/lidsadm -A -s /usr/local/bin/multilog \
                   -o /var/dnscache/dnscache/log/main      -j WRITE

  # tinydns
  #
  /bin/echo "tinydns"

  /sbin/lidsadm -A -s /usr/local/bin/supervise \
                   -o /var/dnscache/tinydns/supervise      -j WRITE
  /sbin/lidsadm -A -s /usr/local/bin/supervise \
                   -o /var/dnscache/tinydns/log/supervise  -j WRITE
  /sbin/lidsadm -A -s /usr/local/bin/multilog \
                   -o /var/dnscache/tinydns/log/main       -j WRITE




  7.5.  Courier-imap

  The following ACLs assume courier-imap was installed into
  /usr/local/courier-imap. With this configuration, courier-imap must be
  started prior to sealing the kernel, or when LIDS_GLOBAL is disabled
  so it can bind to port 143.


  /sbin/lidsadm -A -o /usr/local/courier-imap                     -j DENY

  /sbin/lidsadm -A -s /usr/local/courier-imap/sbin/imaplogin \
                   -o /etc/shadow                                 -j READ
  /sbin/lidsadm -A -s /usr/local/courier-imap/libexec/authlib/authpam \
                   -o /etc/shadow                                 -j READ
  /sbin/lidsadm -A -s /usr/local/courier-imap/libexec/couriertcpd \
                   -o /usr/local/courier-imap                     -j READ

  /sbin/lidsadm -A -s /usr/local/courier-imap/libexec/couriertcpd \
                   -o CAP_SETUID -i 3                             -j GRANT
  /sbin/lidsadm -A -s /usr/local/courier-imap/libexec/couriertcpd \
                   -o CAP_SETGID -i 3                             -j GRANT
  /sbin/lidsadm -A -s /usr/local/courier-imap/libexec/couriertcpd \
                   -o CAP_DAC_OVERRIDE -i 3                       -j GRANT
  /sbin/lidsadm -A -s /usr/local/courier-imap/libexec/couriertcpd \
                   -o CAP_DAC_READ_SEARCH -i 3                    -j GRANT




  7.6.  MySQL

  The following ACLs assume MySQL was installed into /usr/local/mysql.







  /sbin/lidsadm -A -o /usr/local/mysql/var                -j APPEND

  /sbin/lidsadm -A -o /usr/local/mysql                    -j DENY
  /sbin/lidsadm -A -s /usr/local/mysql/libexec/mysqld \
                   -o /usr/local/mysql                    -j READ
  /sbin/lidsadm -A -s /usr/local/mysql/libexec/mysqld \
                   -o /usr/local/mysql/var                -j WRITE




  7.7.  OpenSSH

  The following configuration will work after boot and while LIDS_GLOBAL
  is on because it gives sshd the CAP_NET_BIND_SERVICE capability.


  /sbin/lidsadm -A -s /usr/sbin/sshd -o /etc/shadow       -j READ

  /sbin/lidsadm -A -o /etc/ssh/sshd_config                -j DENY
  /sbin/lidsadm -A -o /etc/ssh/ssh_host_key               -j DENY
  /sbin/lidsadm -A -o /etc/ssh/ssh_host_dsa_key           -j DENY

  /sbin/lidsadm -A -s /usr/sbin/sshd \
                   -o /etc/ssh/sshd_config                -j READ
  /sbin/lidsadm -A -s /usr/sbin/sshd \
                   -o /etc/ssh/ssh_host_key               -j READ
  /sbin/lidsadm -A -s /usr/sbin/sshd \
                   -o /etc/ssh/ssh_host_dsa_key           -j READ

  /sbin/lidsadm -A -s /usr/sbin/sshd \
                   -o /var/log/wtmp                       -j WRITE
  /sbin/lidsadm -A -s /usr/sbin/sshd \
                   -o /var/log/lastlog                    -j WRITE

  /sbin/lidsadm -A -s /usr/sbin/sshd \
                   -o CAP_SETUID                          -j GRANT
  /sbin/lidsadm -A -s /usr/sbin/sshd \
                   -o CAP_SETGID                          -j GRANT
  /sbin/lidsadm -A -s /usr/sbin/sshd \
                   -o CAP_FOWNER                          -j GRANT
  /sbin/lidsadm -A -s /usr/sbin/sshd \
                   -o CAP_CHOWN                           -j GRANT
  /sbin/lidsadm -A -s /usr/sbin/sshd \
                   -o CAP_DAC_OVERRIDE                    -j GRANT
  /sbin/lidsadm -A -s /usr/sbin/sshd \
                   -o CAP_NET_BIND_SERVICE                -j GRANT




  7.8.  OpenLDAP (slapd)

  The following configuration will work after boot and while LIDS_GLOBAL
  is on because it gives slapd the CAP_NET_BIND_SERVICE capability.

  /sbin/lidsadm -A -s /usr/local/libexec/slapd \
                   -o /usr/local/ldapdb                   -j WRITE
  /sbin/lidsadm -A -s /usr/local/libexec/slapd \
                   -o CAP_NET_BIND_SERVICE                -j GRANT
  /sbin/lidsadm -A -s /usr/local/libexec/slapd \
                   -o CAP_INIT_KILL                       -j GRANT
  /sbin/lidsadm -A -s /usr/local/libexec/slapd \
                   -o CAP_SYS_MODULE                      -j GRANT


  7.9.  Port Sentry

  The following configuration will work after boot and while LIDS_GLOBAL
  is on because it gives portsentry the CAP_NET_BIND_SERVICE capability.
  Depending on what you want portsentry to do, you may or may not need
  all of the following ACLs.

  /sbin/lidsadm -A -s /usr/local/psionic/portsentry/portsentry \
                   -o /usr/local/psionic/portsentry               -j WRITE
  /sbin/lidsadm -A -s /usr/local/psionic/portsentry/portsentry \
                   -o /var/log                                    -j WRITE
  /sbin/lidsadm -A -s /usr/local/psionic/portsentry/portsentry \
                   -o CAP_NET_BIND_SERVICE                        -j GRANT

  # For portsentry to be able to update the firewall:
  /sbin/lidsadm -A -s /usr/local/psionic/portsentry/portsentry \
                   -o CAP_NET_RAW -i 1                            -j GRANT

  # For portsentry to be able to update /etc/hosts.allow and/or /etc/hosts.deny:
  /sbin/lidsadm -A -s /usr/local/psionic/portsentry/portsentry \
                   -o /etc/hosts.allow                            -j WRITE
  /sbin/lidsadm -A -s /usr/local/psionic/portsentry/portsentry \
                   -o /etc/hosts.deny                             -j WRITE





  7.10.  Samba

  With this configuration, Samba must be started prior to sealing the
  kernel, or when LIDS_GLOBAL is disabled so it can bind to ports 137 &
  139.


  /sbin/lidsadm -A -o /etc/samba -j READ
  /sbin/lidsadm -A -o /var/samba -j READ
  /sbin/lidsadm -A -s /usr/sbin/smbd -o /var/samba -j WRITE
  /sbin/lidsadm -A -s /usr/sbin/nmbd -o /var/samba -j WRITE

  # smbd needs write access to smbpasswd to chmod it.  i think it
  # also needs access to MACHINE.SID
  /sbin/lidsadm -A -s /usr/sbin/smbd -o /etc/samba -j WRITE
  /sbin/lidsadm -A -s /usr/sbin/smbd -o /etc/shadow -j READ

  /sbin/lidsadm -A -s /usr/sbin/smbd -o CAP_SETUID -j GRANT
  /sbin/lidsadm -A -s /usr/sbin/smbd -o CAP_SETGID -j GRANT
  /sbin/lidsadm -A -s /usr/sbin/smbd -o CAP_HIDDEN -j GRANT

  # LIDS complains about smbd trying to chroot to /
  # everything still seems to work without it, though
  # (and isn't chrooting to / kinda pointless anyway?)
  #/sbin/lidsadm -A -s /usr/sbin/smbd -o CAP_SYS_CHROOT -j GRANT
  /sbin/lidsadm -A -s /usr/sbin/nmbd -o CAP_HIDDEN -j GRANT




  7.11.  Linux HA heartbeat







  /sbin/lidsadm -A -o /usr/lib/heartbeat/heartbeat                -j READ
  /sbin/lidsadm -A -s /usr/lib/heartbeat/heartbeat \
                   -o CAP_NET_BIND_SERVICE -i -1                  -j GRANT
  /sbin/lidsadm -A -s /usr/lib/heartbeat/heartbeat \
                   -o CAP_SYS_RAWIO -i -1                         -j GRANT
  /sbin/lidsadm -A -s /usr/lib/heartbeat/heartbeat \
                   -o CAP_NET_BROADCAST -i -1                     -j GRANT
  /sbin/lidsadm -A -s /usr/lib/heartbeat/heartbeat \
                   -o CAP_NET_ADMIN -i -1                         -j GRANT
  /sbin/lidsadm -A -s /usr/lib/heartbeat/heartbeat \
                   -o CAP_NET_RAW -i -1                           -j GRANT
  /sbin/lidsadm -A -s /usr/lib/heartbeat/heartbeat \
                   -o CAP_SYS_ADMIN -i -1                         -j GRANT

  # For sending Gratuitous Arps

  /sbin/lidsadm -A -o /usr/lib/heartbeat/send_arp                 -j READ
  /sbin/lidsadm -A -s /usr/lib/heartbeat/send_arp \
                   -o CAP_NET_RAW -i -1                           -j GRANT

  # For modifying the routing table when the IP address changes

  /sbin/lidsadm -A -o /sbin/route                                 -j READ
  /sbin/lidsadm -A -s /sbin/route -o CAP_NET_ADMIN -i 0           -j GRANT

  #
  # Protect the heartbeat configuration and authentication key.
  #
  /sbin/lidsadm -A -o /etc/ha.d/ha.cf                             -j READ
  /sbin/lidsadm -A -o /etc/ha.d/haresources                       -j READ
  /sbin/lidsadm -A -o /etc/ha.d/authkeys                          -j DENY

  #
  # Only heartbeat can see the authkey
  #
  /sbin/lidsadm -A -s /usr/lib/heartbeat/heartbeat \
                   -o /etc/ha.d/authkeys                          -j READ








  8.  LIDS Technical

  8.1.  Will LIDS work with a file system other than ext2?

  Yes.  To quote LIDS co-author Philippe Biondi:

       "LIDS works on top of the VFS layer, so that it can handle
       every fs linux supports."



  8.2.  Will LIDS run on an SMP system?

  There have been problems reported with SMP systems running LIDS.  Many
  of the problems have been fixed, so it is recommended that you try out
  the latest version and see for yourself.  Xie and Philippe are very
  dedicated to fixing any such problems, so please make sure to report
  any to the LIDS mailing list.

  UPDATE (2/10/01): Many users have reported success using LIDS-1.0.5
  for the 2.4.x kernel on SMP systems.
  8.3.  Will LIDS coexist with Solar Designer's Openwall patch?

  Yes.  If you apply both the LIDS and Openwall patches yourself, one of
  the hunks will fail (as of release 0.9.11 for kernel 2.2.18).  It is a
  minor error that won't affect your system security.  However, if you
  don't like the error, you can visit http://root-it.be/community/lids
  and download the combined LIDS + Openwall patch.  Wim Vandersmissen
  was nice enough to combine the patches and fix the error for us.  Wim
  also offers several other combo patches on his site that include LIDS.


  8.4.  Will LIDS run on non-Intel hardware?

  I'm not aware of any confirmed success stories on other hardware
  platforms.  If you get LIDS to work on another architecture, be sure
  to let everyone know of your efforts.

  Update: Johannes Helje has successfully installed LIDS on a pair of
  SUN IPXs.  He is using Debian with a 2.2.18 kernel.


  8.5.  What is the difference between the 0.9.x and 1.0.x versions of
  LIDS?

  LIDS  0.9.x  is for the  2.2.x  Linux kernel, and LIDS  1.0.x  is for
  the  2.4.x  Linux kernel.








































