On Tue, 18 Jan 2005 12:03:43 +0530, Syed Ahemed said: > Problem 1 > ------------------ > strcpy for instances has the maximum number of instances in my code . > Now instead of replacing strcpy with strncpy (which has its own set of > vulnerabilities_performance issues ) , I decided to have checks to > ensure safe usage of strcpy ( a la libsafe implementation) . which > didnt guarantee solution to buffer overflows either .I stumbled upon > LSM which spoke about hooks to call security function , I assumed > LSM framework could "implement [not provide me with a framework] a > security function to check for string length" before strcpy > internally called memcpy . > I guess am wrong with my assumption here . Can LSM do anything to solve this ? No. The proper thing to do here is to ensure that kernel code either uses strncpy, or checks the lengths beforehand, or similar correct programming practice. There is no LSM exit to verify a strcpy is OK. In fact, there is no LSM way to protect against *any* bug in the kernel. The complete list of what LSM can check is listed in include/linux/security.h - if it's not in there, LSM can't check it. There's 133 or so exits provided. The list of things is basically "What security-related events in the kernel might a package like SELinux or LIDS want to give its opinion about?". LSM isn't about protecting against kernel bugs. It's about implementing a security framework to control what userspace processes are allowed to do. "Is Process X owned by User Y allowed to do Z?" - that's what LSM is about. > Problem 2 > --------------- > Then there a few files and process to be protected I decided to use > LIDS ,realised it has administrative control only , I mean security is > still at the mercy of command configuration the administrative level. I hope you realize there is *no* easy way to secure a system against the administrator, or any other authenticated access at admin level (unless you go to an MLS scheme where the sysadmin isn't allowed to see things, and all the sysadmin's actions go to an audit file for the security officer to review...) > I wanted a comprehensive solution to intercept system calls and > ensure security at the kernel level . Intercepting system calls to ensure security - now *THAT* LSM can do well. > For instance if LIDS was compromised i didnt want a buffer overflow > smashing my stack . Which "my" stack do we mean here - a userspace process stack or a kernel stack? > So i decided to use LSM's openwall patch . Considering it doesn't > co-exist I lose out on LIDS . Openwall didn't address stack smashes either (except for the non-exec stack which is now in the base kernel). Most of Openwall is *totally* useless in your scenario, as it's protecting users from other malicious users - and if you get a malicious user on this router box, you're basically screwed anyhow, and there isn't anything Openwall will do to save you. > Problem 3 > --------------- > Its a well know debate offcourse u either implement security at the > begining or just before the system resource is accessed (LSM does this). Note that security "at the beginning" can often run into TOCTOU (Time Of Check/ Time Of Use) issues with race conditions. For example, you can stat() a file, decide the values make sense - and before you actually open() the file it gets replaced by something malicious. There's been a number of kernel bugs where code would do a copy_from_user() to get an ioctl parameter or similar, verify it, and later re-fetch the "same" data (which by now wasn't "same" anymore). > P.S I am not using LSM cos it allows me to security functions as > modules , I dont care if it is a part of the kernel or a module . There's no requirement that code using LSM has to be a module - in fact, the SELinux code *cannot* be built as a module, because by the time userspace gets up far enough to do a 'modprobe', it's "too late" for SELinux to start up and make the guarantees it wants to make (in particular, it can't guarantee that some other unauthorized code hasn't already been modprobe'ed into the kernel).
This archive was generated by hypermail 2.1.3 : Mon Jan 17 2005 - 23:25:16 PST