On Fre, Nov 30, 2001 at 11:31:08 +1000, [EMAIL PROTECTED] wrote: > I just wanted to know if anyone is using this and what they think of > it.
I think it's a good protection that bring's a linux system a step further in the direction of having a finer tuneable system that doesn't depend too much on a single user. > Is it hard to set up? It would be *very* nice to have labor to test this stuff out. To effectively configure it, you must have a real world load on the machine where many users try to access their data. This was, for me, a hairy step. First, you download the patch. You patch the kernel and set configuration options. Then the usual compile run. After you setup up a LIDS protected kernel, you boot the system without LIDS enabled. This is option "security=0" (e.g. at lilo stage). Then you boot it. Set the password which protect your kernel from root. Then you set which capabilities should be enabled/disabled by the kernel. Then you set basic configuration. First, imagine what capabilities a daemon should have for the daemons that need additional access. This will never work from just imagine it. In the FAQ/HOWTO there are several examples of configurations for specific daemons and/or programs. If you wann be on the secure way, disable every capability that you don't need and don't configure any capabilties further. Configure it later on a per-need basis. Second, you set up basic mandatory ACL. Protect /etc, /bin, /usr and so on. This is well documented on the homepage and the LIDS distribution comes with good basic configuration. After you have a mini LIDS configured system, with basicly configured filesystem and daemons, you boot the system. Many daemons will fail to boot at this step (because e.g. they could not bind to port 80 'cause lack of access the capability CAP_NET_SYS_BIND_SERVICE). Try to login (hope, you have configured /bin/login properly). If something goes wrong, you can reboot with LIDS disabled and do admin stuff as usual. Setup LIDS logging (important). Perhaps remote or via printk/klogd (stuff goes to /var/log/kern.log) Now you can try to access some files/directories which you have protected or you try someting you disabled (e.g. try ping to access raw sockets). LIDS should generate an alert, even for root. Then you do a LFS (LIDS free session). Check documentation (as you should already really have at this stage). Start every daemon that could not be started at boot stage. Activate LIDS and monitor where the daemons fail to do their job. Configure the daemons with lidsadm. After the daemons run smootly in a configured LIDS, you set up them so they can start automatically. In my setup, i changed start sequence so every daemon which e.g. have to bind to a privileged port in single user mode. LIDS will be sealed at the finish of single user mode boot stage. Background: don't give daemons to much access if they don't need it really for daily business operations. Run the system with maximum protection and change perms on a per-need basis. After things go well, you protected filesystem and capabilites and the system runs with required security, you can fine tune it. "Does this daemon really need it for running? Can this file/directory be secured and everything runs well?" If you do it the first time, it will be a time consuming process to monitor it and to configure it properly. After experience grow, it will be easier and easier to secure your machine. The main purpose i use LIDS, is to protect the person who administrate the machine from the root user wich have to run service daemons. Cause in a properly setup system, these are not the same (with LIDS), i can sleep well bacause they [the attacker] will bite into stone, even they get root access. One very cool feature is to terminate session on violation. On thing access even which root should not have and you have your session terminated. > What happens when you do an apt-get > dist-upgrade - will it refuse to change the binaries you want to > upgrade? This depend. In an activateed environment, you login as root and upgrade, it will fail. The filesystem is in this situation protected even for root. If you disable it locally, say your current shell and child-processes have LIDS deactivated, it will work. With my version (i used it on 2.2) it will update the files without problems. Problems could occur on restarting the daemons. I had to disable it globally and restart the daemons by hand (and of course ractivate it later, say it's insecure). > Is something like Tripwire / AIDE better because it doesn't > stop root from changing/deleting files but will tell you later which > ones have changed. I use both. The access control lists are mandatory. This means they're compulsory even for root. In an normal kernel, discretionary control is used, which mean root can evade it. LIDS protect from actually restricted access and, this is very nice, have a logging facility wich report every policy violation. So, a script kiddiy ist accessing a read-only /usr, he will raise alert on write access the whole /usr sub-directory (this is different from mounting it read-only. You can remount it in this situation. With LIDS this is not possible). LIDS is for protection and real-time logging. The checksum is for verifiyng the storage. LIDS goes further, but also does have logging facilites. > Anyone with any experience in using this LIDS? Yes, i do. Some off-topic (personal) info: I had a talk at my local user group. The response, actually from people who administrate systems with over 300 users, was very good. I had the next LIDS presenation at the ETH in zurich. Then David Spreen contacted me. He creates the inofficial debian LIDS packages at http://netzwurm.cc/computer/lids.html If everything goes well, we'll have a speak together at the Chaos Communication Congress 2001 (18C3) about LIDS. I'll have a computer with LIDS there and will hand-out root passwort to everybody. The challenge root-vs-kernel will begin :)
