Re: LSM patch for Linux-2.4.20-8

From: Syed Ahemed (kingkhan@private)
Date: Tue Jan 18 2005 - 02:51:28 PST


> "Is Process X owned by User Y allowed to do Z?" - that's what LSM is about .

kingkhan writes :   Long before LIDS was ported as an LSM , It did
this .The only difference being  it implemented security at the
begining" and after porting it follows the LSM model (hooks at the end
)
 LIDS without LSM  :  Process X owned by User Y allowed to  "access
file" Z [ intercepted at the begining ]
 LIDS with LSM       :  Process X owned by User Y allowed to "access
file" Z  [intercepted at the end before a call to the open system
call.
SELinux with LSM    :     Process X owned by User Y allowed to 
"create sockets/threads/ access files etc"  [intercepted at the end
before a call to the open system call]

 Am i right ? 
Based on your answer to the above ,Finally it will boil down to the
following solutions for my threat model  [after ur statement that
multiple security models might not co-exist well ] :  Please comment .

Solution 1 
---------------
a]LIDS without LSM   : Takes care of files and process issues with
conventional  unix/linux model
b] Implement my own strncpy or strcpy with better length checking 
c] Openwall patch is a part of base kernel will take care of
executable stack issue

Solution 2 
---------------
a] LSM with SELINUX    :  what it does that LIDS[with/without LSM ] cant  ? 
    Note : I haven't seen a debate LIDS VS SELINUX , maybe they aren't
alike at all.But we   have a co-existence problem to solve too.
b]   Implement my own strncpy or strcpy with better length checking 
c] Openwall patch is a part of base kernel will take care of
executable stack issue


 Solution 3
------------------
I cant get the best of both worlds : LSM framework for restrictive
access and Security against world known exploits like buffer overflow
and the likes .

Thanks
kingkhan



       

On Tue, 18 Jan 2005 02:24:37 -0500, Valdis.Kletnieks@private
<Valdis.Kletnieks@private> wrote:
> 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 : Tue Jan 18 2005 - 02:52:13 PST