lids-faq.sgml

关于LINUX安全内核的源代码

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

<verb>
/sbin/lidsadm -I
</verb>

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.

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

<sect1> How do I view the status of my LIDS system?
<p>
In order to use the "-V" option, you must have compiled lidsadm with <tt> make VIEW=1 </tt> <ref id="lidsadm-compile" name="(see above)">.

At the command line, enter:
<verb>
# lidsadm -V
</verb>

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

<verb>
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
</verb>

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

<sect1> How do I configure the port scan detector in LIDS?
<p>
You don't.  As long as you selected the option when you configured your LIDS enhanced kernel, the port scan detector is enabled.
<verb>
   [*]  Port Scanner Detector in kernel
</verb>

<sect1> What are the subject and object in a LIDS ACL?
<label id="Subject-Object-question">
<p>
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.

<sect1> Can I enable/disable a system capability without modifying /etc/lids/lids.cap and reloading the configuration files?
<p>
Yes.  However, this method will not save the changes past system shutdown.

To enable a capability:
<verb>
# lidsadm -S -- +CAP_SYS_ADMIN
</verb>

To disable a capability:
<verb>
# lidsadm -S -- -CAP_SYS_ADMIN
</verb>

<sect1> I've reconfigured my LIDS ACLs, but my changes don't seem to take effect.  What's wrong?
<label id="acl-reconfig">
<p>
There are two things you should do when re-configuring LIDS:
<enum>
<item> <ref id="Reload" name="Reload"> the configuration files.
<item> Restart the service or services that your changes affected.
</enum>

<sect1> Why won't lidsadm -L list my ACLs?
<p>
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:
<verb>
lidsadm: can not open conf file
reason:: Permission denied
LIST
</verb>

<sect1> Is there anyway to reduce the number of LIDS violations that get reported on the console?
<label id="console-logging">
<p>
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 <tt>include/linux/kernel.h</tt>).

For example:
<verb>
klogd -c 4
</verb>

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

<sect1> Should I be concerned about the LD_PRELOAD environment variable with LIDS?
<label id="LD_PRELOAD-warning">
<p>
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).
<p>
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.
<p>
<em>Possible options to reduce your risk:</em>
<p>
<itemize>
<item>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. <tt>chmod o-rwx /path/to/program </tt>)
<item>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.
</itemize>

<sect1> When I boot up, the message "read password file error" appears.  How do I fix the problem?
<label id="read-password-error">
<p>
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 <ref id="unusable-system" name="booting an unusable system">) and set your <ref id="Set-Password" name="LIDS password">.
<!-- Section 5 -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect> Configuring LIDS
<label id="Configuring-LIDS">
<sect1> How do I protect a file as read only?
<p>
<verb>
# lidsadm -A -o /some/file	-j READ
</verb>

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

<sect1> OK, so how do I protect a directory as read only?
<p>
Same as above, only specify <tt> /some/directory </tt>
<verb>
# lidsadm -A -o /some/directory	 -j READ
</verb>

When the object is a directory, LIDS protects the directory itself, and it recursively protects everything underneath it <em> within the same file system</em>. (e.g.<tt><bf> LIDS ACLs do not cross file system boundaries!</bf></tt>) 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 <tt>/etc</tt> directory.
<verb>
# lidsadm -A -o /etc -j READ
</verb>

<sect1> How can I hide a file/directory from everyone?
<p>
<verb>
# lidsadm -A -o /some/file_or_directory   -j DENY
</verb>
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).

<sect1> How can I protect log files so they can only be appended to?
<p>
<verb>
# lidsadm -A -o /some/log/file  -j APPEND
</verb>
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:
<verb>
# lidsadm -A -o /var/log  -j APPEND
</verb>

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

<sect1> If nothing is allowed to read my /etc/shadow file, how can I authenticate myself to the system?
<p>
In order to allow users to authenticate themselves to the system, it is necessary to give certain programs read only access to the <tt>/etc/shadow</tt>.  Some of the programs you may want to consider giving read access to are: <tt>login, sshd, su,</tt> and <tt>vlock</tt>.

To allow the login program to read <tt>/etc/shadow</tt>, use the following ACL:
<verb>
# lidsadm -A -s /bin/login -o /etc/shadow -j READ
</verb>
The "-s" option specifies a subject, which is <tt>/bin/login</tt> in this case.  We are giving the subject read only access to the object (<tt>/etc/shadow</tt> in this case).

<sect1> If I protect /etc as read only, how will mount be able to write to /etc/mtab?
<label id="etc-mtab-1">
<p>
It won't. To fix this problem, you can remove the <tt>/etc/mtab</tt> file and replace it with a symbolic link to <tt>/proc/mounts</tt>.  In order for this to work, you must modify your startup scripts to use the "-n" option with every <tt>mount</tt> and <tt>umount</tt> command.  This tells <tt>mount</tt> and <tt>umount</tt> not to update the <tt>/etc/mtab</tt> file.

For example, if you find:
<verb>
mount -av -t nonfs,noproc
</verb>

in your init scripts, you will need to change it to:
<verb>
mount -av -n -t nonfs,noproc
</verb>

These <tt>mount</tt> 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 <tt>umount</tt> commands in the same manner.

<sect1> LIDS complains that it can't write to my modules.dep file during startup.  What's wrong?
<p>
This happens when you protect <tt>/lib</tt> as read only (a good thing to do).  The error received is something similar to:
<quote>
<tscreen>
LIDS: depmod (3 12 inode 16119) pid 13203 user (0/0) on tty2: Try to open /lib/modules/2.2.18/modules.dep for writing,flag=578
</tscreen>
</quote>

This occurs during startup because the <tt>/etc/rc.d/rc.sysinit</tt> 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 <tt>/etc/rc.d/rc.sysinit</tt> script that recreates the module dependencies (Look for <tt>depmod -a</tt> or something similar).

<sect1> If I protect my logs as append only, how will logrotated rotate my logs?
<p>
<label id="log-rotation">
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 <ref id="log-rotation-option" name="below"> for a possible alternative).

<sect1> Why can't I just give my log rotation utility write access to the directory containing my log files so it can rotate them?
<p>
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.

<label id="log-rotation-option">
An alternative solution to giving your log rotation utility write access to <tt>/var/log</tt>, is to give the cron daemon write access to /var/log and make it inheritable:
<verb>
lidsadm -A -s /usr/sbin/crond -i -o /var/log	-j WRITE
</verb>

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

<bf> WARNING:</bf>  If a vulnerability is found in your cron daemon, someone could exploit it and wipe your logs since cron would have write access to <tt>/var/log</tt>.  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!

<sect1> When LIDS is active, my file systems won't unmount during shutdown.  What do I do?
<p>
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 <tt>/etc/rc.d/init.d/halt</tt> script unmounts your file systems.  You must give it the CAP_SYS_ADMIN capability so it can unmount your file systems:
<verb>
# lidsadm -A -s /etc/rc.d/init.d/halt -o CAP_SYS_ADMIN -i 1 -j GRANT
</verb>

The target "GRANT" tells LIDS to grant the subject (<tt>/etc/rc.d/init.d/halt</tt> 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 <tt>/etc/rc.d/init.d/halt</tt> 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.

<sect1> Why can't I start a service that runs on a privileged port as root?
<p>
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 <tt>/etc/lids/lids.cap</tt> file, you must either grant the program that capability
<verb>
# lidsadm -A -s /usr/local/bin/apache -o CAP_NET_BIND_SERVICE -j GRANT
</verb>
or, start the service when LIDS_GLOBAL is disabled.

<sect1> Why can't I start a service that runs on a privileged port from an LFS?
<p>
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.

<sect1> How do I disable/enable capabilities?
<p>
The <tt>/etc/lids/lids.cap</tt> 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 <ref id="Reload" name="reload"> the configuration files.

<sect1> Why won't the X Window System work with LIDS enabled?
<label id="xfree+lids">
<p>
The X server that you are using requires the CAP_SYS_RAWIO capability. Try
<verb>
# lidsadm -A -s /path/to/your/X_server -o CAP_SYS_RAWIO -j GRANT