Linux Intrusion Detection System FAQ
Sander Klein
<lids AT roedie DOT nl>
v.20, May 19th, 2003
This is the Linux Intrusion Detection System (LIDS) FAQ. It
answers commonly asked questions asked on the
LIDS-mailing-list (and more!).
The LIDS version at the time this Document was released was:
* Kernel 2.4: 1.1.1 (stable) 1.1.2-rc6 (developement)
* Kernel 2.2: 0.11.0r2 (stable) 0.11.1pre1 (development)
* Kernel 2.5: 2.0.3rc1 (development)
_________________________________________________________
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. Translations
1.11. Revision History
1.12. To-do
1.13. Where can I get this faq?
2. Installing LIDS
2.1. How do I apply the LIDS kernel patch?
2.2. How do I install the LIDS administration utilities
(lidsadm & lidsconf)?
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. A note for Debian users...
2.6. I tried to apply the LIDS patch to kernel version
2.x.x-x that is shipped with my distro and I
received errors. What's wrong?
3. lidsadm and lidsconf
3.1. What is lidsadm?
3.2. What is lidsconf?
3.3. What options are available for lidsadm?
3.4. What options are available for lidsconf?
3.5. Nice, what do all those capabilities mean?
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 lidsconf -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?
4.19. How do I check if LIDS is enabled/disabled??
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. How can I give init write access to /etc/initrunlvl
so LIDS doesn't complain about it during startup
and shutdown?
5.17. Can a process inherit file ACLs from its parent?
5.18. 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.19. How do I give passwd the proper permissions to
update the /etc/shadow file?
5.20. Why doesn't ssh or scp work when LIDS is enabled?
5.21. Open-SSH won't start at boot time. LIDS reports
that bash tried to access a hidden file. How can
I fix this?
5.22. Some of my file systems won't unmount at shutdown
because I have hidden processes running. How can
I kill them?
5.23. 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?
5.24. Is it possible to limit access based on time of
day?
5.25. How do I limit the ports that a program can bind
to?
5.26. If I make /etc/mtab a symbolic link to
/proc/mounts, will user quotas still work?
5.27. When I edit a file protected by LIDS, it appears to
lose it's LIDS protections. Why?
5.28. When I update my LIDS configuration some processes
seem to lose their capabilities
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 (3.4p1)
7.8. OpenLDAP (slapd)
7.9. Port Sentry
7.10. Samba
7.11. Linux HA heartbeat
7.12. Bind 9.x
7.13. Sendmail
7.14. Apcupsd
7.15. Pump
7.16. Snort
7.17. Getty
7.18. Login
7.19. Su
7.20. Exim
7.21. Qpopper
7.22. Proftp
7.23. Aproxy
7.24. Squid
7.25. Innd
7.26. Postfix
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.x, 1.x and 2.x
versions of LIDS?
_________________________________________________________
Chapter 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
headache 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?
You can obtain LIDS on http://www.lids.org or one of it's
mirrors. For a list of mirrors visit
http://www.lids.org/mirrors.html.
_________________________________________________________
1.4. Which versions of the Linux kernel are supported?
Currently, LIDS supports the 2.2 kernel as well as the 2.4
kernel. LIDS development is done using the 2.5 kernel. So, new
features will be implemented there first. However, some
features may make it back into the 2.2 or 2.4 kernel depending
on users' needs. Any security fixes will be backported to the
2.2 or 2.4 kernels. There's also a version of LIDS which is
integrated in LSM (Linux Security Modules).
_________________________________________________________
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, 2002 for Steve
Bremer - 2002, 2003 for Sander Klein and it is a FREE
document. You may redistribute it under the terms of the GNU
General Public License.
The information herein this document is, to the best of
Sander's knowledge, correct. However, LIDS and the LIDS-FAQ is
written by humans and thus, the chance of mistakes, bugs, etc.
might occur from time to time.
No person, group, or other body is responsible for any damage
on your computer(s) and any other losses by using the
information on this document. i.e.
"THE AUTHORS AND ALL MAINTAINERS ARE NOT RESPONSIBLE FOR ANY
DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE INFORMATION
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 lids AT roedie DOT nl. I always welcome feedback whether
it's good or bad!
_________________________________________________________
1.9. Credit
Special thanks go to:
* Xie Huagang - Technical editor and LIDS author.
+ LIDS version question.
+ Subject/object question.
* Philippe Biondi - LIDS author.
* Andy Harrelson - Grammar/spelling editor.
* Rob Willis - Open-SSH, OpenLDAP, and Port Sentry
configuration examples.
* Fred Mobach - Inspiration and corrections.
* David Ranch - I used his excellent Linux IP Masquerade
HOW-TO as an SGML template. His disclaimer also proved
useful.
* Austin Gonyou -
+ Valuable feedback on FAQ.
+ Alternative fix to the lidsadm compile problem.
+ Warning about updating the inode of the /etc/passwd
file.
* Pavel Epifanov - For a simple fix to the lidsadm compile
problem.
* Justus Pendleton - Samba configuration example.
* Nenad Micic
+ For the hidden process kill script example.
+ His C program to kill hidden processes at shutdown.
+ LD_PRELOAD warning.
* Bill Phillips - For pointing out many reference errors in
the PDF version.
* Szymon Juraszczyk
+ LD_PRELOAD warning.
* Lorn Kay -
+ Heartbeat configuration for Linux HA.
+ Sendmail configuration.
* Bill McKenzie - Additions to Portsentry configuration.
* Sander Klein
+ Question about checking if LIDS is enabled or
disabled.
+ Apcupsd configuration.
+ Pump configuration.
+ Snort configuration.
+ getty configuration.
+ login configuration.
+ su configuration.
* David Spreen - Time restriction warning and restricting
crontab access.
* Thomas Linden - For providing his BIND 9.x Configuration
* Mathias Gygax - For providing sample configurations for
exim, qpopper, and proftp.
* Dimitri Goldin - For pointing out that the LIDS password
can be obtained by root users if /dev/pts is mounted and
left unprotected.
* BigSam - Innd config.
* Ralf Dreibrodt - Innd config.
* Steve Bremer - For starting to write this document which
helped me a lot when I started using LIDS.
" Linux is a trademark of Linus Torvalds "
_________________________________________________________
1.10. Translations
The following is a list of know translations and their
locations:
* Japanese -- http://www.linux.or.jp/JF/JFdocs/LIDS-FAQ.html
* Polish -- http://www.linuxpub.pl/man/lidsfaq/.
_________________________________________________________
1.11. Revision History
The latest version of this FAQ can be found at
http://www.roedie.nl/lids-faq/. Please check the latest
version before reporting any bugs.
* May 19th, 2003. Version .20
+ Added the Postfix example.
+ Updated the Openssh example.
+ Removed the part about compiling lids prior to 1.1.0.
+ Removed the 'I can't see my /etc/lids dir' question.
+ Added question about losing capabilities.
+ Changed the capabilities section.
+ Changed lots of small things to be correct again.
* December 22th, 2002. Version .19
+ This is the first version of the LIDS FAQ that I
(Sander Klein) released. Big thanks go to Steve.
+ Replaced lidsadm -P to lidsconf -P.
+ Rewritten small parts to be up-to-date again.
+ Rewritten the whole document in docbook format with
the ldp stylesheet.
+ Added the capabilities section.
+ Changed some URLs to point to the right directions
again.
* April 27th, 2002. Version .18
+ This will be the last version of the LIDS FAQ that I
(Steve Bremer) will produce. Sander Klein will be the
new maintainer of the FAQ from this point on.
+ Added aproxy configuration example.
+ Added /dev/pts warning.
+ Added squid configuration example.
+ PowerPC status update.
+ Added Innd configuration example.
+ Other minor corrections.
* January 28th, 2002. Version .17
+ Changed "READ" to "READONLY".
* January 12th, 2002. Version .16
+ Various updates for the changes made in version
1.1.0.
+ Minor corrections.
+ Added sample configurations for exim, qpopper, and
proftp.
+ Updated console logging question.
+ Updated LD_PRELOAD warning.
+ Updated file ACL inheritance question.
+ Added file editing question.
* November 12th, 2001. Version .15
+ Added many new configurations
(Sendmail,apcupsd,pump,snort,getty,login,su). Thanks
to Sander Klein and Lorn Kay.
+ Added Red Hat Kernel patch question.
+ Added User quota question.
* August 26th, 2001. Version .14
+ Added LIDS enabled/disabled question.
+ Improved basic configuration question.
+ Added a notice for Debian users.
+ Added time restriction question.
+ Updated log rotation question to use new time
restriction feature.
+ Updated non-Intel hardware question.
+ Added translations section.
+ Added port restriction question.
+ Added BIND 9.x configuration.
* May 20th, 2001. Version .13
+ Added heartbeat configuration for HA Linux.
+ Added read password error question.
+ Added basic configuration question.
+ Minor additions to portsentry configuration.
+ Enhanced (yet again) passwd update question.
+ Other minor corrections.
* April 1st, 2001. Version .12
+ Updated FAQ for new versions of LIDS (1.0.6+ and
0.9.14+).
+ Added warning about LD_PRELOAD environment variable.
+ Updated hardware question.
* March 10th, 2001. Version .11
+ Fixed several reference errors in the PDF version
(there are still a few document conversion problems
that need looked at).
+ Clarified the Basic System Setup configuration.
+ Updated the mailing list information
+ Updated passwd and log rotation questions.
* March 1st, 2001. Version .10
+ Added Samba configuration example.
+ Added example on how to kill hidden processes at
shutdown.
+ Added ssh keygen question.
+ Enhanced passwd update question.
* February 10th, 2001. Version .09
+ Added ssh/scp question.
+ Updated mailing list information.
+ LIDS SMP status update.
* January 27th, 2001. Version .08
+ Modified Apache configuration so the server root is
protected as DENY.
+ Modified mysql and courier-imap so their default
directories are protected as DENY.
+ Modified ssh config to work with password
authentication.
+ Added question regarding ACL reconfiguration.
* January 25th, 2001. Version .07
+ Added a much simpler fix to the lidsadm compile
problem. Clarified the sealing the kernel question
(hopefully). Minor corrections.
* January 24th, 2001. Version .06
+ Removed ACL example from /etc/mtab mount question
because /etc/mtab is recreated at system boot and
each time a file system is unmounted.
+ Added alternative fix to the lidsadm compile problem.
+ Minor corrections.
* January 22nd, 2001. Version .05
+ Minor additions to Basic System Setup sample
configuration. Added section on configuring e-mail
alerts.
* January 19th, 2001. Version .04
+ Minor correction to lidsadm compile problem question.
* 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.
* January 15th, 2001. Version .02
+ Minor corrections.
* January 15th, 2001. Version .01
+ Initial release.
_________________________________________________________
1.12. To-do
Things that still need to be done in this document:
* Add directions for LIDS-LSM.
* Probably a lot more...
_________________________________________________________
1.13. Where can I get this faq?
The html version of the LIDS-FAQ can be found at the LIDS
website. Other formats are also available at
http://www.roedie.nl/lids-faq/.
_________________________________________________________
Chapter 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.
Always make sure you are using the latest LIDS version with
the corresponding kernel version. LIDS development can go very
rapid from time to time and documentation changes just as
fast.
* First you need to download the LIDS patch from
www.lids.org/download.html. Make sure you get the version
that matches your kernel. (People who use kernels provided
by their Linux distribution please read the following.
* Then, expand the tarball:
bash$ tar -zxvf lids-lids_version-kernel_version.tar.gz
* Apply the lids patch to the existing kernel sources:
bash$ cd /usr/src/linux
bash$ patch -p1 < /path/to/lids/patch/lids-lids_version-kernel_version.
patch
* 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 utilities (lidsadm &
lidsconf)?
* LIDS 1.1.2+
NOTE: If you are upgrading LIDS, you should backup everything
in the /etc/lids directory first!)
From your LIDS source directory, type:
bash$ tar -zvxf lidstools-version.tar.gz
bash$ cd lidstools-version
bash$ ./configure
bash$ make
bash$ su -
bash# make install
This will install lidsadm and lidsconf in the /sbin directory.
It will also create an /etc/lids directory and place a few
default configuration files in it for you. The configuration
files will be updated with the proper inode and device
information for your system. You will also be prompted to
enter the LIDS password at this time. The inode update process
can give some errors if it is looking for files that are
non-existant on your system. These errors are not harmful.
If you do not wish to enable the view option (-V) in lidsadm,
specify --disable-view when running configure.
_________________________________________________________
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: *** [lid
sadm.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. A note for Debian users...
David Spreen is maintaining the Debian package for LIDS. He
would like you to email package specific LIDS configurations
to netzwurm AT debian DOT org. He also recommends that Debian
users use the Debian package for LIDS because it includes
Debian specific modifications.
_________________________________________________________
2.6. I tried to apply the LIDS patch to kernel version 2.x.x-x that
is shipped with my distro and I received errors. What's wrong?
LIDS is developed using the "vanilla" kernel as developed by
Linus. Many distributions,including Red Hat, Debian, and Suse,
customize their kernels. There is nothing wrong with this, but
you should be aware that their kernels are not the same as
Linus' kernel. If you want to apply it to a non-Linus kernel,
you're on your own. (Debian users, see above notice)
_________________________________________________________
Chapter 3. lidsadm and lidsconf
3.1. What is lidsadm?
lidsadm is the LIDS administration utility that you will use
to administer LIDS on your system. This includes
enabling/disabling LIDS, sealing the kernel, and viewing the
status of LIDS.
_________________________________________________________
3.2. What is lidsconf?
lidsconf is used to configure the access control lists (ACLs)
for LIDS. It is also used to set the LIDS password. NOTE: In
versions prior to LIDS 1.1.0, lidsadm also performed all of
the tasks of that lidsconf now performs.
_________________________________________________________
3.3. What options are available for lidsadm?
To get a list of the available options, enter the following:
bash# lidsadm -h
This will return the following output:
lidsadm version 0.4.1 for LIDS project
Huagang Xie <xie@gnuchina.org>
Philippe Biondi <pbi@cartel-info.fr>
Usage: lidsadm -[S|I] -- [+|-][LIDS_FLAG] [...]
lidsadm -V
lidsadm -h
Commands:
-S To submit a password to switch some protections
-I To switch some protections without submitting password (seal
ing time)
-V To view current LIDS state (caps/flags)
-v To show the version
-h To list this help
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 set*gid(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_MKNOD mknod operation
CAP_LEASE taking leases on files
CAP_HIDDEN hidden process
CAP_KILL_PROTECTED kill protected programs
CAP_PROTECTED Protect the process from signals
Available flags:
LIDS de-/activate LIDS locally (the shell & childs)
LIDS_GLOBAL de-/activate LIDS entirely
RELOAD_CONF reload config. file and inode/dev of protected pro
grams
_________________________________________________________
3.4. What options are available for lidsconf?
To get a list of the available options, enter the following:
bash# lidsconf -h
This will return the following output:
lidsconf version 0.4.1 for the LIDS project
Huagang Xie <xie@gnuchina.org>
Philippe Biondi <philippe.biondi@webmotion.net>
Usage: lidsconf -A [-s subject] -o object [-d] [-t from-to] [-i level]
-j ACTION
lidsconf -D [-s file] [-o file]
lidsconf -Z
lidsconf -U
lidsconf -L [-e]
lidsconf -P
lidsconf -v
lidsconf -[h|H]
Commands:
-A,--add To add an entry
-D,--delete To delete an entry
-Z,--zero To delete all entries
-U,--update To update dev/inode numbers
-L,--list To list all entries
-P,--passwd To encrypt a password with RipeMD-160
-v,--version To show the version
-h,--help To list this help
-H,--morehelp To list this help with CAP/SOCKET name
subject: -s,--subject subj
can be any program, must be a file
object: -o,--object [obj]
can be a file, directory or Capability, Socket Name
ACTION: -j,--jump
DENY deny access
READONLY read only
APPEND append only
WRITE writable
GRANT grant capability to subject
IGNORE ignore any permissions set on this object
DISABLE disable some extersion feature
OPTION:
-d,--domain The object is an EXEC Domain
-i,--inheritance Inheritance level
-t,--time Time dependency
-e,--extended Extended list
_________________________________________________________
3.5. Nice, what do all those capabilities mean?
Capabilities allow you to set certain system wide permissions
on what actions are allowed or disallowed. If you disable
CAP_SETUID then it's impossible for any program to transfer
the UID. With LIDS you can enable/disable certain capabilities
for certain programs. The function of each capability is
described in /etc/lids/lids.cap or in
/path/to/lidstools/example/lids.cap if you didn't install LIDS
yet.
_________________________________________________________
Chapter 4. LIDS Administration
4.1. How do I set my LIDS password?
If the install command somehow didn't ask you to set you
password then you must set it before you reboot into your LIDS
enhanced kernel by entering the following at the command
prompt:
bash# lidsconf -P
You will then be prompted for a LIDS password:
MAKE PASSWD
enter new password:
reenter new password:
wrote password to /etc/lids/lids.pw
This will write your RipeMD-160 encrypted password to the
/etc/lids/lids.pw file. You need this password if you want to
change some ACL's, capabilities or when you want to start a
LIDS free session.
_________________________________________________________
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.
WARNING: It is possible for someone with root access to obtain
the LIDS password if /dev/pts is mounted. In order to prevent
this, you can either unmount /dev/pts or protect it.
_________________________________________________________
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:
bash# 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:
* Enable LIDS again (lidsadm -S -- +LIDS).
* 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
NOTE: Be sure that there is no other administrator in an LFS
because you will close his LFS!
_________________________________________________________
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:
* /etc/lids/lids.conf - LIDS ACL configuration file.
* /etc/lids/lids.cap - LIDS capabilities file.
* /etc/lids/lids.pw - LIDS password file.
* /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 lids=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 lids=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:
bash# 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.
bash# 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:
bash# 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 the view option enabled. (which is standard
behaviour, see above). At the command line, enter:
bash# lidsadm -V
This will produce output similar to the following on a 2.4.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_MKNOD 0
CAP_LEASE 0
CAP_HIDDEN 1
CAP_KILL_PROTECTED 0
CAP_PROTECTED 0
LIDS 0
LIDS_GLOBAL 1
RELOAD_CONF 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:
bash# lidsadm -S -- +CAP_SYS_ADMIN
To disable a capability:
bash# 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 lidsconf -L list my ACLs?
lidsconf -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:
lidsconf: 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.
Another way to change the console log level is to modify the
values in /proc/sys/kernel/printk. View the documentation
provided in /usr/src/linux/Documentation/sysctl/kernel.txt for
more information.
_________________________________________________________
4.17. Should I be concerned about the LD_PRELOAD environment
variable with LIDS?
Yes, if you are running an version of LIDS older than
1.1.1preX please read on.
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:
* Any program with special capabilities or file access
permissions should be restricted with the standard unix
file permissions so that not everyone is allowed to
execute it (e.g. chmod o-rwx /path/to/program )
* 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.
SECURITY UPDATE: Starting with LIDS 1.1.1preX, the LD_PRELOAD
environment variable is disabled automatically for any program
that has been given special privileges via LIDS. This has also
been back ported to LIDS 0.10.3.
_________________________________________________________
4.18. When I boot up, the message "read password file error"
appears. How do I fix the problem?
This happens when you somehow forget or did not 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.
_________________________________________________________
4.19. How do I check if LIDS is enabled/disabled??
If you have compiled the lidsadm with 'make VIEW=1' then you
can use 'lidsadm -V' to see if LIDS is enabled. If it says
'LIDS_GLOBAL 0' then LIDS is disabled. If it says 'LIDS 0'
then someone is in a Lids Free Session. If you haven't
compiled lidsadm with the VIEW option there are several ways
to determine if LIDS is running.
1. You can check for the line 'Linux Intrusion Detection
System <lids-version> for <kernel-version> doesn't start'
is in your dmesg. If it says 'Linux Intrusion Detection
System <lids-version> for <kernel-version> starts' then
LIDS is started of course.
2. You can try to do something that you are sure of you can't
do to see if LIDS takes action. If there's no action the
LIDS is not active.
_________________________________________________________
Chapter 5. Configuring LIDS
5.1. How do I protect a file as read only?
bash# lidsconf -A -o /some/file -j READONLY
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
bash# lidsconf -A -o /some/directory -j READONLY
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.
bash# lidsconf -A -o /etc -j READONLY
_________________________________________________________
5.3. How can I hide a file/directory from everyone?
bash# lidsconf -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?
bash# lidsconf -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:
bash# lidsconf -A -o /var/log -j APPEND
_________________________________________________________
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:
bash# lidsconf -A -s /bin/login -o /etc/shadow -j READONLY
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). This will protect all files
under /var/log as append only. As with READ and DENY, this
target is also recursive.
_________________________________________________________
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 op
en /lib/modules/2.2.18/modules.dep for writing,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:
lidsconf -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!
UPDATE: Because of the new time restriction feature, it is
recommended that if crond has write access to /var/log, it
should be limited to a specific time period. For example, if
logrotated is executed every day at 6:00 AM by crond, limit
crond's write access to a 1 minute window:
/sbin/lidsconf -A -s /usr/sbin/crond -i 2 -o /var/log -t 0600-0601 -j W
RITE
If 1 minute isn't long enough, extend the time by 1 minute
increments until logrotated is executed successfully.
_________________________________________________________
5.10. When LIDS is active, my file systems won't unmount during
shutdown. 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:
bash# lidsconf -A -s /etc/rc.d/init.d/halt -o CAP_SYS_ADMIN -i 1 -j GRA
NT
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
bash# lidsconf -A -s /usr/local/bin/apache -o CAP_NET_BIND_SERVICE 80 -
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
bash# lidsconf -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.
bash# lidsconf -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. 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.17. 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.
SECURITY UPDATE: Starting with LIDS 1.1.1preX and 0.10.1, only
protected programs are allowed inherit ACLs from their parent.
Allowing non-protected processes to inherit ACLs led to an
exploit.
_________________________________________________________
5.18. 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.19. 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/lidsconf -A -s /usr/bin/passwd -o /etc -j WRI
TE
/sbin/lidsconf -A -s /usr/bin/passwd -o /etc/hosts.allow -j REA
DONLY
/sbin/lidsconf -A -s /usr/bin/passwd -o /etc/hosts.deny -j REA
DONLY
/sbin/lidsconf -A -s /usr/bin/passwd -o /etc/rc0.d -j REA
DONLY
/sbin/lidsconf -A -s /usr/bin/passwd -o /etc/rc1.d -j REA
DONLY
/sbin/lidsconf -A -s /usr/bin/passwd -o /etc/rc2.d -j REA
DONLY
/sbin/lidsconf -A -s /usr/bin/passwd -o /etc/rc3.d -j REA
DONLY
/sbin/lidsconf -A -s /usr/bin/passwd -o /etc/rc4.d -j REA
DONLY
/sbin/lidsconf -A -s /usr/bin/passwd -o /etc/rc5.d -j REA
DONLY
/sbin/lidsconf -A -s /usr/bin/passwd -o /etc/rc6.d -j REA
DONLY
/sbin/lidsconf -A -s /usr/bin/passwd -o /etc/init.d -j REA
DONLY
/sbin/lidsconf -A -s /usr/bin/passwd -o /etc/cron.d -j REA
DONLY
/sbin/lidsconf -A -s /usr/bin/passwd -o /etc/pam.d -j REA
DONLY
...
The above is not a complete list by any stretch of the
imagination, 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.20. 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):
lidsconf -A -s /usr/bin/ssh -o CAP_NET_BIND_SERVICE 22 -j GRANT
_________________________________________________________
5.21. Open-SSH 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. The 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.22. 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.23. 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?
Make sure to select the following kernel options:
...
Security alert when execing unprotected programs before sealin
g
Do not execute unprotected programs before sealing lids
...
Allow switching LIDS protections
...
Allow reloading config. file
A good starting point would be to protect your init scripts,
system binaries, and libraries (Note that these may vary
depending upon your distro):
/sbin/lidsconf -A -o /etc/rc0.d -j READONLY
/sbin/lidsconf -A -o /etc/rc1.d -j READONLY
/sbin/lidsconf -A -o /etc/rc2.d -j READONLY
/sbin/lidsconf -A -o /etc/rc3.d -j READONLY
/sbin/lidsconf -A -o /etc/rc4.d -j READONLY
/sbin/lidsconf -A -o /etc/rc5.d -j READONLY
/sbin/lidsconf -A -o /etc/rc6.d -j READONLY
/sbin/lidsconf -A -o /etc/init.d -j READONLY
/sbin/lidsconf -A -o /etc/rc -j READONLY
/sbin/lidsconf -A -o /etc/rc.local -j READONLY
/sbin/lidsconf -A -o /etc/rc.sysconfig -j READONLY
/sbin/lidsconf -A -o /bin -j READONLY
/sbin/lidsconf -A -o /sbin -j READONLY
/sbin/lidsconf -A -o /lib -j READONLY
/sbin/lidsconf -A -o /usr/bin -j READONLY
/sbin/lidsconf -A -o /usr/sbin -j READONLY
/sbin/lidsconf -A -o /usr/lib -j READONLY
If /usr/local is on a separate partition, add the following
ACLs also:
/sbin/lidsconf -A -o /usr/local/bin -j READONLY
/sbin/lidsconf -A -o /usr/local/sbin -j READONLY
/sbin/lidsconf -A -o /usr/local/lib -j READONLY
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.
_________________________________________________________
5.24. Is it possible to limit access based on time of day?
Yes. There is a new feature in LIDS version 0.10.1 for 2.2.19
and version 1.0.10 for 2.4.5 that allows a time restriction to
be placed on ACLs. For example, to only allow logins between
the hours of 9:00 AM and 6:00 PM (18:00):
/sbin/lidsconf -A -s /bin/login -o /etc/shadow -t 0900-1800 -j READONLY
Now, /bin/login can only read the /etc/shadow file during the
specified time period and any login attempts outside of that
time period will fail. You can also use the "!" operator for
negation (e.g. The ACL permits access all the time except for
the time period listed).
If you grant privileges to crond based on time restrictions,
it is highly recommended that you hide your crontabs from
everyone (including root), and only allow crond to read them.
Otherwise, someone could figure out what time of day they
should try and exploit something by looking at your crontabs.
Remember to protect the system crontabs as well as the user
crontabs.
For example, the following should be hidden:
/var/spool/cron/
/etc/crontab
/etc/cron.hourly/
/etc/cron.daily/
/etc/cron.weekly/
/etc/cron.monthly/
/etc/cron.d/
WARNING: Because this new feature relies on the system time,
you should not grant CAP_SYS_RAWIO to any program that can
change the system time (e.g. /sbin/hwclock. This would allow
someone to bypass the time restriction by changing the system
time.
_________________________________________________________
5.25. How do I limit the ports that a program can bind to?
As of version 0.10.1 for 2.2.19 and version 1.0.11 for 2.4.6,
you can limit the privileged ports that a program can bind to.
When granting CAP_NET_BIND_SERVICE to a program, specify the
port or ports that the program is allowed to bind to after the
capability, like this:
/sbin/lidsconf -A -s /bin/httpd -o CAP_NET_BIND_SERVICE 80-80 -j GRANT
Or, if you also need to bind to port 443 for SSL:
/sbin/lidsconf -A -s /bin/httpd -o CAP_NET_BIND_SERVICE 80-80,443-443 -
j GRANT
If you have a program that requires a range of ports, try
this:
/sbin/lidsconf -A -s /path/to/program -o CAP_NET_BIND_SERVICE 423-867 -
j GRANT
_________________________________________________________
5.26. If I make /etc/mtab a symbolic link to /proc/mounts, will user
quotas still work?
Yes, as long as you are starting quotaon with the "-a" option.
_________________________________________________________
5.27. When I edit a file protected by LIDS, it appears to lose it's
LIDS protections. Why?
Many editors (e.g. vi) copy the file you are editing to a
temporary file. All your changes are made to that temporary
file. When you exit the editor, the temporary file is moved
over the original file. This changes the inode of the original
file and any previous LIDS ACLs that affected the file will no
longer work. Type:
/sbin/lidsconf -U
To update the inodes in the lids.conf file.
_________________________________________________________
5.28. When I update my LIDS configuration some processes seem to
lose their capabilities
This can happen when a process got it's capabilities through
inheritance. Think of the following:
The parent process gives it's capabilities to a child proces,
the parant process exits but the child remains running. If you
start an LFS, change some ACL's and reload your config, LIDS
will re-attach the capabilities based on the parents process
capabilities and it's own capabilities. If the parent process
is not running anymore the process will not get those
capabilities again and may give errors.
_________________________________________________________ |
IP卡
狗仔卡
发表于 2004-10-8 01:42:20
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
楼主