> Suggestions like restricting access to /proc were named, but there > were few suggestions on how to properly implement this. A Linux kernel module is the best way to go if you want to be able to hide only specific processes. If you prefer to have more of a 'you can only see your own processes' then you can do this as a kernel patch instead that isn't dynamic. LIDS does selective process hiding, as do many rootkit kernel modules (although they are more often hard-coded and not as dynamic as LIDS and friends.) I'd provide more direct pointers to available software, but can't think at the moment. Too too damned hot here. > Does hiding process give a false sense of security? Is it worth the > effort? What problems can one run into by for example restricting > access to /proc? Are there better ways to hide process information > from users? I love to hide processes, especially on honeypots. Another good candidate is any log analysis/monitoring software. It doesn't add security, but it may make any malicous user who has gained access less stealthy if they think no one is watching them. Another good case would be for file integrity tools, to keep them from noticing which ones are in use. Say you have tripwire installed in a default location and obviously run out of cron. Leave that for the cracker to edit/disable. But secretly have a daemon running that is hidden, and all it does in periodically (like cron - in fact you could copy /usr/sbin/cron) run the AIDE file integrity tool, which is stored in a very non-standard location with unrecognizable file names. No, it doesn't add security, but it does add secrecy, and that may help you keep the bad guys off guard. -- Brian Hatch "Well, who wants to live forever?" Systems and "I do, actually. But what the hell." Security Engineer http://www.ifokr.org/bri/ Every message PGP signed
msg00407/pgp00000.pgp
Description: PGP signature
