# lidsadm -A -o /some/file -j READ
This will prevent anyone (including root) from modifying or deleting /some/file as long as LIDS is enabled. If you are in a LFS, you are free to modify /some/file assuming you have appropriate file system permissions and the partition isn't mounted read-only.
Same as above, only specify /some/directory
# lidsadm -A -o /some/directory -j READ
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 boundries!). 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.
# lidsadm -A -o /etc -j READ
# lidsadm -A -o /some/file_or_directory -j DENYAgain, 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).
# lidsadm -A -o /some/log/file -j APPENDThis will allow someone to write to the end of the file while at the same time preventing him/her from erasing or modifying it's existing contents.
An easy way to protect your system logs as append only would be:
# lidsadm -A -o /var/log -j APPEND
This will protect all files under /var/log as append only. As with READ and DENY, this target is also recursive.
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:
# lidsadm -A -s /bin/login -o /etc/shadow -j READThe "-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).
It won't. You can give mount and umount write access to /etc/mtab like this:
# lidsadm -A -s /bin/mount -o /etc/mtab -j WRITE
or 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.
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 open /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 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).
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.
You can, but it's not recommended. If someone were to break into you system, even though they couldn't modify your logs, they could rotate them enough times 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.
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:
# lidsadm -A -s /etc/rc.d/init.d/halt -t -o CAP_SYS_ADMIN -j INHERIT
The "-t" option tells LIDS that the object is a capability and not a device or file. The target "INHERIT" tells LIDS that all processes started by the halt script will inherit this capability.
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.
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
# lidsadm -A -s /usr/local/bin/apache -t -o CAP_NET_BIND_SERVICE -j NO_INHERITor, start the service when LIDS_GLOBAL is disabled.
A 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.
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, simple 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.
The X server that you are using requires the CAP_SYS_RAWIO capability. Try
# lidsadm -A -s /path/to/your/X_server -t -o CAP_SYS_RAWIO -j NO_INHERIT
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.
# lidsadm -Z
LIDS automatically protects the /etc/lids directory with DENY.
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.