> "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