lids-faq.sgml

关于LINUX安全内核的源代码

</verb>

<sect1> With all of these ACLs, how can I possibly keep track of my configuration?
<p>
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.
<verb>
# lidsadm -Z
</verb>

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

<sect1> I can't see my /etc/lids directory when LIDS is enabled.  What's going on?
<p>
LIDS automatically protects the <tt>/etc/lids</tt> directory with DENY.

<sect1> How can I give init write access to /etc/initrunlvl so LIDS doesn't complain about it during startup and shutdown?
<p>
Unfortunately, there isn't much you can do about this.  Because <tt>init</tt> 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 <tt>/etc/initrunlvl</tt>.

<sect1> Can a process inherit file ACLs from its parent?
<p>
Yes.  Up until version 0.9.12-2.2.18, this was the default behavior.  Now the default is for children <bf>not</bf> 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 &lt;inheritance level&gt;" option.
<p>
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).
<p>
<em>Note:</em> These same inheritance rules apply to ACLs that grant capabilities.

<sect1> Help! I can't seem to get program xyz to work under LIDS.  How do I determine what files/capabilities it needs access to?
<p>
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 <bf>temporarily</bf> give strace the CAP_SET_PTRACE capability so it can trace your program while LIDS is enabled.

<sect1> How do I give passwd the proper permissions to update the /etc/shadow file?
<label id="passwd-update">
<p>
Unfortunately there isn't an easy solution.  This is because the <tt>passwd</tt> utility recreates the <tt>/etc/shadow</tt> file every time you change your password.  Because of this, it will start on a different inode each time you use the <tt>passwd</tt> utility successfully.

For the system administrator, there is an easy work around.  Start an LFS and use the <tt>passwd</tt> 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 <bf>not</bf> recommended.  <tt>/usr/bin/passwd</tt> can be given write access to /etc so it can always modify the shadow file regardless of it's inode number.

<bf> WARNING:</bf> If someone were to find a vulnerability in <tt>/usr/bin/passwd</tt>, or any of the libraries/PAM modules that it uses, he/she could potentially gain write access to your <tt>/etc</tt> 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 <tt>/usr/bin/passwd</tt> write access to <tt>/etc</tt>, it is recommended that you create ACLs to protect every file and directory under <tt>/etc</tt> that you don't want <tt>/usr/bin/passwd</tt> to be able to modify.
This will significantly reduce the risk (and possibly completely remove it if done correctly) mentioned above.
For example:
<verb>
/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
...
</verb>

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 <tt>/etc</tt> that you don't want <tt>passwd</tt> to have access to, you must create a new ACL to protect it.



<em> A note about updating inodes: </em>
<p>
<label id="passwd-file-warning">
If you have defined ACLs to grant access to <tt>/etc/shadow</tt> or <tt>/etc/passwd</tt> you must make sure to tell lids to <ref id="update-inodes" name="update the inodes"> and then <ref id="Reload" name="reload"> it's config files.  Otherwise you may encounter problems.

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


<sect1> Why doesn't ssh or scp work when LIDS is enabled?
<label id="ssh-scp-question">
<p>
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 <tt>ssh_config</tt> file to force it to use a port above 1023 for the source port:

<verb>
UsePrivilegedPort No
</verb>

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

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

<sect1> OpenSSH won't start at boot time.  LIDS reports that <tt>bash</tt> tried to access a hidden file.  How can I fix this?
<label id="ssh-keygen-question">
<p>
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 <tt>/etc/ssh</tt>.  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:
<verb>
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
      ;;
</verb>

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

<sect1> Some of my file systems won't unmount at shutdown because I have hidden processes running.  How can I kill them?
<p>
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 <tt>/var</tt> (<tt>/var/run</tt> is commonly used).  Your shutdown scripts can be modified to read the pids from these files and send them the appropriate signals.
<p>
For example, if your system stores the pids in <tt>/var/run/&lt;process_name&gt;.pid</tt>, then you can add the following lines to your shutdown scripts:
<verb>
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
</verb>
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 <tt>/var/run</tt> directory from everything but the init scripts too.

Another option would be to just send every process the TERM and KILL signals.
<label id="kill-hidden-processes-script">
<verb>
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
</verb>
<label id="kill-hidden-processes-C-program">
<p>
Nenad Micic wrote his own <htmlurl url="http://www.bg.ac.yu/~mclaffin/lids/mklidsconf/sbin/brc.c" name="C program"> to kill hidden processes at shutdown.

<sect1> 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?
<label id="basic-configuration">
<p>
A good starting point would be to protect your system binaries and libraries:
<verb>
/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
</verb>

If <tt>/usr/local</tt> is on a separate partition, add the following ACLs also:
<verb>
/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
</verb>

<p>
You should also disable CAP_SYS_RAWIO and CAP_SYS_PTRACE in the <tt>/etc/lids/lids.cap</tt> 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 <ref id="xfree+lids" name="above"> about getting X to work under LIDS.


<!-- Section 6 -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect> Configuring Security Alerts
<sect1> Which kernel configuration options do I need to select in order to send security alerts through the network?
<p>
<verb>
[*]   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
</verb>
<p>
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.

<sect1> Where do I specify the mail server information and e-mail address to send the LIDS alerts to?
<p>
All information required for sending security alerts must be configured in the <tt>/etc/lids/lids.net</tt> file.  A description of each option is provided in the configuration file itself.  When specifying an e-mail address, be sure not to leave <bf>any</bf> 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:
<verb>
"MAIL_TO= [e-mail]"
"MAIL_TO=[e-mail] "
</verb>

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 <tt>/etc/lids/lids.net</tt> file, you must tell LIDS to <ref id="Reload" name="reload"> it's configuration files.

<sect1> LIDS can't seem to deliver alerts to my qmail SMTP server.  Is there a fix for this?
<p>
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:
<htmlurl url="http://www.egroups.com/message/lids/1896" name="http://www.egroups.com/message/lids/1896">.


<!-- Section 7 -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect> Sample Configurations
<sect1> Basic System Setup
<label id="basic-system-setup-config">
<p> The following is a sample configuration for basic system setup.
<verb>
# 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