lids-faq-5.html

关于LINUX安全内核的源代码

<P>Unfortunately, there isn't much you can do about this.  Because <CODE>init</CODE> 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 <CODE>/etc/initrunlvl</CODE>.
<P>
<H2><A NAME="ss5.18">5.18 Can a process inherit file ACLs from its parent?</A>
</H2>

<P>Yes.  Up until version 0.9.12-2.2.18, this was the default behavior.  Now the default is for children <B>not</B> 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.
<P>
<H2><A NAME="ss5.19">5.19 Help! I can't seem to get program xyz to work under LIDS.  How do I determine what files/capabilities it needs access to?</A>
</H2>

<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.
<P>NOTE: If you have disabled CAP_SYS_PTRACE globally, you will need to <B>temporarily</B> give strace the CAP_SET_PTRACE capability so it can trace your program while LIDS is enabled.
<P>
<H2><A NAME="passwd-update"></A> <A NAME="ss5.20">5.20 How do I give passwd the proper permissions to update the /etc/shadow file?</A>
</H2>

<P>Unfortunately there isn't an easy solution.  This is because the <CODE>passwd</CODE> utility recreates the <CODE>/etc/shadow</CODE> file every time you change your password.  Because of this, it will start on a different inode each time you use the <CODE>passwd</CODE> utility successfully.
<P>For the system administrator, there is an easy work around.  Start an LFS and use the <CODE>passwd</CODE> 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.
<P>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 <B>not</B> recommended.  <CODE>/usr/bin/passwd</CODE> can be given write access to /etc so it can always modify the shadow file regardless of it's inode number.
<P><B> WARNING:</B> If someone were to find a vulnerability in <CODE>/usr/bin/passwd</CODE>, or any of the libraries/PAM modules that it uses, he/she could potentially gain write access to your <CODE>/etc</CODE> 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!
<P>If you are going to give <CODE>/usr/bin/passwd</CODE> write access to <CODE>/etc</CODE>, it is recommended that you create ACLs to protect every file and directory under <CODE>/etc</CODE> that you don't want <CODE>/usr/bin/passwd</CODE> to be able to modify.
This will significantly reduce the risk (and possibly completely remove it if done correctly) mentioned above.
For example:
<PRE>
/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
...
</PRE>
<P>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 <CODE>/etc</CODE> that you don't want <CODE>passwd</CODE> to have access to, you must create a new ACL to protect it.
<P>
<P>
<P><EM> A note about updating inodes: </EM>
<P>
<A NAME="passwd-file-warning"></A> 
If you have defined ACLs to grant access to <CODE>/etc/shadow</CODE> or <CODE>/etc/passwd</CODE> you must make sure to tell lids to 
<A HREF="LIDS-FAQ-4.html#update-inodes">update the inodes</A> and then 
<A HREF="LIDS-FAQ-4.html#Reload">reload</A> it's config files.  Otherwise you may encounter problems.
<P>For example: Assume <CODE>/etc/passwd</CODE> is protected as DENY, and <CODE>/bin/login</CODE> can read <CODE>/etc/passwd</CODE>.  If the inodes aren't updated after changing a password, problems may arise the next time someone tries to log in.  <CODE>/bin/login</CODE> won't be able to read <CODE>/etc/passwd</CODE> 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.
<P>
<P>
<H2><A NAME="ssh-scp-question"></A> <A NAME="ss5.21">5.21 Why doesn't ssh or scp work when LIDS is enabled?</A>
</H2>

<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 <CODE>ssh_config</CODE> file to force it to use a port above 1023 for the source port:
<P>
<PRE>
UsePrivilegedPort No
</PRE>
<P>Or, you can grant CAP_NET_BIND_SERVICE to ssh (since scp uses ssh, it will work also):
<P>
<PRE>
lidsadm -A -s /usr/bin/ssh -o CAP_NET_BIND_SERVICE      -j GRANT
</PRE>
<P>
<H2><A NAME="ssh-keygen-question"></A> <A NAME="ss5.22">5.22 OpenSSH won't start at boot time.  LIDS reports that <CODE>bash</CODE> tried to access a hidden file.  How can I fix this?</A>
</H2>

<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 <CODE>/etc/ssh</CODE>.  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.
<P>To fix this, remove the check for the key files in the startup script:
<PRE>
start)
      # Create keys if necessary
      #do_rsa_keygen;  &lt;------------ 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
      ;;
</PRE>
<P><B> NOTE: </B> This means the private keys will have to be generated manually prior to starting sshd.  Otherwise, it will fail to start.
<P>
<H2><A NAME="ss5.23">5.23 Some of my file systems won't unmount at shutdown because I have hidden processes running.  How can I kill them?</A>
</H2>

<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 <CODE>/var</CODE> (<CODE>/var/run</CODE> 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 <CODE>/var/run/&lt;process_name&gt;.pid</CODE>, then you can add the following lines to your shutdown scripts:
<PRE>
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
</PRE>

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 <CODE>/var/run</CODE> directory from everything but the init scripts too.
<P>Another option would be to just send every process the TERM and KILL signals.
<A NAME="kill-hidden-processes-script"></A> 
<PRE>
MAX_PROC=65535
trap : 1 2 15
I=1;while (( $I &lt; $MAX_PROC ));do
        I=$(($I+1));
        if (( $$ != $I ));then
                kill -15 $I;
        fi;
done
sleep 5
sync;sync;sync;
I=1;
while (( $I &lt; $MAX_PROC ));do
        I=$(($I+1));
        if (( $$ != $I ));then
                kill -9 $I;
        fi;
done
sync;sync;sync
</PRE>

<A NAME="kill-hidden-processes-C-program"></A> <P>Nenad Micic wrote his own 
<A HREF="http://www.bg.ac.yu/~mclaffin/lids/mklidsconf/sbin/brc.c">C program</A> to kill hidden processes at shutdown.
<P>
<H2><A NAME="basic-configuration"></A> <A NAME="ss5.24">5.24 I just want to start with a basic configuration.  Can you recommend a setup that will provide additional protection and still leave most of my system functioning as normal?</A>
</H2>

<P>A good starting point would be to protect your system binaries and libraries:
<PRE>
/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
</PRE>
<P>If <CODE>/usr/local</CODE> is on a separate partition, add the following ACLs also:
<PRE>
/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
</PRE>
<P>
<P>You should also disable CAP_SYS_RAWIO and CAP_SYS_PTRACE in the <CODE>/etc/lids/lids.cap</CODE> file.  If you don't disable CAP_SYS_RAWIO, then someone can override the above file protections by writing directly to your devices.
<P>If you are running the X Window System, please see 
<A HREF="#xfree+lids">above</A> about getting X to work under LIDS.
<P>
<P>
<P>
<HR>
<A HREF="LIDS-FAQ-6.html">Next</A>
<A HREF="LIDS-FAQ-4.html">Previous</A>
<A HREF="LIDS-FAQ.html#toc5">Contents</A>
</BODY>
</HTML>