📄 lids-faq-5.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><HTML><HEAD> <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9"> <TITLE> LIDS FAQ: Configuring LIDS</TITLE> <LINK HREF="LIDS-FAQ-6.html" REL=next> <LINK HREF="LIDS-FAQ-4.html" REL=previous> <LINK HREF="LIDS-FAQ.html#toc5" REL=contents></HEAD><BODY><A HREF="LIDS-FAQ-6.html">Next</A><A HREF="LIDS-FAQ-4.html">Previous</A><A HREF="LIDS-FAQ.html#toc5">Contents</A><HR><H2><A NAME="Configuring-LIDS"></A> <A NAME="s5">5. Configuring LIDS</A></H2><H2><A NAME="ss5.1">5.1 How do I protect a file as read only?</A></H2><P><PRE># lidsadm -A -o /some/file -j READ</PRE><P>This will prevent anyone (including root) from modifying or deleting <CODE> /some/file </CODE> as long as LIDS is enabled. If you are in an LFS, you are free to modify <CODE> /some/file </CODE> assuming you have appropriate file system permissions and the partition isn't mounted read-only.<P><H2><A NAME="ss5.2">5.2 OK, so how do I protect a directory as read only?</A></H2><P>Same as above, only specify <CODE> /some/directory </CODE><PRE># lidsadm -A -o /some/directory -j READ</PRE><P>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.<CODE><B> LIDS ACLs do not cross file system boundaries!</B></CODE>) This is very important to remember so you don't accidentally leave part of your system unprotected.<P>A directory that you may want to protect as read only is the <CODE>/etc</CODE> directory.<PRE># lidsadm -A -o /etc -j READ</PRE><P><H2><A NAME="ss5.3">5.3 How can I hide a file/directory from everyone?</A></H2><P><PRE># lidsadm -A -o /some/file_or_directory -j DENY</PRE>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).<P><H2><A NAME="ss5.4">5.4 How can I protect log files so they can only be appended to?</A></H2><P><PRE># lidsadm -A -o /some/log/file -j APPEND</PRE>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.<P>An easy way to protect your system logs as append only would be:<PRE># lidsadm -A -o /var/log -j APPEND</PRE><P>This will protect all files under <CODE> /var/log </CODE> as append only. As with READ and DENY, this target is also recursive.<P><H2><A NAME="ss5.5">5.5 If nothing is allowed to read my /etc/shadow file, how can I authenticate myself to the system?</A></H2><P>In order to allow users to authenticate themselves to the system, it is necessary to give certain programs read only access to the <CODE>/etc/shadow</CODE>. Some of the programs you may want to consider giving read access to are: <CODE>login, sshd, su,</CODE> and <CODE>vlock</CODE>.<P>To allow the login program to read <CODE>/etc/shadow</CODE>, use the following ACL:<PRE># lidsadm -A -s /bin/login -o /etc/shadow -j READ</PRE>The "-s" option specifies a subject, which is <CODE>/bin/login</CODE> in this case. We are giving the subject read only access to the object (<CODE>/etc/shadow</CODE> in this case).<P><H2><A NAME="etc-mtab-1"></A> <A NAME="ss5.6">5.6 If I protect /etc as read only, how will mount be able to write to /etc/mtab?</A></H2><P>It won't. To fix this problem, you can remove the <CODE>/etc/mtab</CODE> file and replace it with a symbolic link to <CODE>/proc/mounts</CODE>. In order for this to work, you must modify your startup scripts to use the "-n" option with every <CODE>mount</CODE> and <CODE>umount</CODE> command. This tells <CODE>mount</CODE> and <CODE>umount</CODE> not to update the <CODE>/etc/mtab</CODE> file.<P>For example, if you find:<PRE>mount -av -t nonfs,noproc</PRE><P>in your init scripts, you will need to change it to:<PRE>mount -av -n -t nonfs,noproc</PRE><P>These <CODE>mount</CODE> 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 <CODE>umount</CODE> commands in the same manner.<P><H2><A NAME="ss5.7">5.7 LIDS complains that it can't write to my modules.dep file during startup. What's wrong?</A></H2><P>This happens when you protect <CODE>/lib</CODE> as read only (a good thing to do). The error received is something similar to:<BLOCKQUOTE><BLOCKQUOTE><CODE>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</CODE></BLOCKQUOTE></BLOCKQUOTE><P>This occurs during startup because the <CODE>/etc/rc.d/rc.sysinit</CODE> 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 <CODE>/etc/rc.d/rc.sysinit</CODE> script that recreates the module dependencies (Look for <CODE>depmod -a</CODE> or something similar).<P><H2><A NAME="ss5.8">5.8 If I protect my logs as append only, how will logrotated rotate my logs?</A></H2><P><A NAME="log-rotation"></A> 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 <A HREF="#log-rotation-option">below</A> for a possible alternative).<P><H2><A NAME="ss5.9">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?</A></H2><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.<P><A NAME="log-rotation-option"></A> An alternative solution to giving your log rotation utility write access to <CODE>/var/log</CODE>, is to give the cron daemon write access to /var/log and make it inheritable:<PRE>lidsadm -A -s /usr/sbin/crond -i -o /var/log -j WRITE</PRE><P>This prevents someone from manually executing your log rotation utility, but will allow it to work when it is executed by the cron daemon.<P><B> WARNING:</B> If a vulnerability is found in your cron daemon, someone could exploit it and wipe your logs since cron would have write access to <CODE>/var/log</CODE>. 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><H2><A NAME="ss5.10">5.10 When LIDS is active, my file systems won't unmount during shutdown. What do I do?</A></H2><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 <CODE>/etc/rc.d/init.d/halt</CODE> script unmounts your file systems. You must give it the CAP_SYS_ADMIN capability so it can unmount your file systems:<PRE># lidsadm -A -s /etc/rc.d/init.d/halt -o CAP_SYS_ADMIN -i 1 -j GRANT</PRE><P>The target "GRANT" tells LIDS to grant the subject (<CODE>/etc/rc.d/init.d/halt</CODE> in this case) the CAP_SYS_ADMIN capability. The "-i 1" option sets the "inheritance level" of the ACL to 1.<P>Beware that this also allows anyone who can execute your <CODE>/etc/rc.d/init.d/halt</CODE> 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.<P><H2><A NAME="ss5.11">5.11 Why can't I start a service that runs on a privileged port as root?</A></H2><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 <CODE>/etc/lids/lids.cap</CODE> file, you must either grant the program that capability<PRE># lidsadm -A -s /usr/local/bin/apache -o CAP_NET_BIND_SERVICE -j GRANT</PRE>or, start the service when LIDS_GLOBAL is disabled.<P><H2><A NAME="ss5.12">5.12 Why can't I start a service that runs on a privileged port from an LFS?</A></H2><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.<P><H2><A NAME="ss5.13">5.13 How do I disable/enable capabilities?</A></H2><P>The <CODE>/etc/lids/lids.cap</CODE> 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 <A HREF="LIDS-FAQ-4.html#Reload">reload</A> the configuration files.<P><H2><A NAME="xfree+lids"></A> <A NAME="ss5.14">5.14 Why won't the X Window System work with LIDS enabled?</A></H2><P>The X server that you are using requires the CAP_SYS_RAWIO capability. Try<PRE># lidsadm -A -s /path/to/your/X_server -o CAP_SYS_RAWIO -j GRANT</PRE><P><H2><A NAME="ss5.15">5.15 With all of these ACLs, how can I possibly keep track of my configuration?</A></H2><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.<PRE># lidsadm -Z</PRE><P>To protect this shell script, you can either create an ACL to DENY access to it, or put it in the <CODE>/etc/lids</CODE> directory since it is automatically protected as DENY.<P><H2><A NAME="ss5.16">5.16 I can't see my /etc/lids directory when LIDS is enabled. What's going on?</A></H2><P>LIDS automatically protects the <CODE>/etc/lids</CODE> directory with DENY.<P><H2><A NAME="ss5.17">5.17 How can I give init write access to /etc/initrunlvl so LIDS doesn't complain about it during startup and shutdown?</A></H2>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -