lids-faq.txt

关于LINUX安全内核的源代码

  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).