Thanks a lot for the inputs ,Looks like am getting there .But I need
to take a decision on LSM as soon as possible .It would be of great
help if u suggest a solution based on the threat model i describe
below.
Threat Model [ An effort to get hardened linux ...The story so far ]
--------------------
I have my KBOX running linux kernel that will act as router/bridge to
our network .
Most of the packets coming will be remote configuration or forwarder
packets which will be check for attacks to the end machines.
Apart from the above i have implemented quite a few modules that do
store packets in transit at the box before forwarding .
To be able to disallow the compromise/damage of KBOX , I have
shortlisted common vulnerabilities.
NOTE : I AM ONLY ADDRESSING LINUX HARDENING AT THE CODE LEVEL.
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 ?
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 wanted a comprehensive solution to intercept system calls and
ensure security at the kernel level .
For instance if LIDS was compromised i didnt want a buffer overflow
smashing my stack .
So i decided to use LSM's openwall patch . Considering it doesn't
co-exist I lose out on LIDS .
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
). It sounds very exciting to me that
Inode level check are implemented by LSM , I took the plunge .
Linus torvalds n community backs this ...But i have to implement with
minimal effort .
Now all i want is to to address these Problem 1 and Problem 2 using LSM .
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 .
Please provide a precise solution with just one example with a
vulnerability and how exactly does LSM help .
Thanks a million in advance
Syed Ahemed
On Mon, 17 Jan 2005 13:54:11 -0500, Valdis.Kletnieks@private
<Valdis.Kletnieks@private> wrote:
> On Mon, 17 Jan 2005 23:45:56 +0530, Syed Ahemed said:
>
> > For instance open() system call without the LSM patch checks for file
> > attributes for read write permissions from the user .
> > What does this "security_ops->file_permission (file, MAY_WRITE); "
> > do additionally?
>
> It does all the actual work.
>
> > In short do i need to write "C code" to implement the security
> > solution like checking if a file has symbolic link before opening to
> > avoid race condition ?
>
> You either write C code, or add in somebody else's C code (like SELinux)
> to do the work.
>
> Sample file_permission exit from a small LSM I wrote to do OpenWall-ish stuff:
>
> +#ifdef CONFIG_SECURITY_SYMLINK
> +int vtkit_follow_link (struct dentry *dentry, struct nameidata *nd)
> +{
> + struct inode *i_target = dentry->d_inode;
> + struct inode *i_parent = dentry->d_parent->d_inode;
> +
> + /* Here we check the following - If the symlink is in a world-writeable
> + * directory and the dir is mode +t, then we don't follow the symlink
> + * unless the target's UID matches either the directory's or the
> + * process's. In particular, we do *not* cut uid==0 a free pass...
> + *
> + * If you have world-write dirs w/o +t, you're on your own...
> + *
> + * Subtle - we don't bother checking S_ISLNK on the inode because
> + * we're only called if the inode has a follow_link() function....
> + */
> + if (security_safe_symlink &&
> + (i_parent->i_mode & S_ISVTX) && (i_parent->i_mode & S_IWOTH) &&
> + (i_parent->i_uid != i_target->i_uid) &&
> + (current->fsuid != i_target->i_uid)) {
> + printk(KERN_NOTICE "vtkit - rejecting symlink UID %d (dir UID %d) follow byPID %d (uid=%d, comm=%s)\n",
> + i_target->i_uid, i_parent->i_uid, current->pid, current->uid, current->comm);
> + return -EPERM;
> + }
> + return 0;
> +}
> +#endif
>
> This requires some "glue" code to create a security_ops structure, populate it
> with a pointer to this function, and register it.
>
> > Issue 2
> > -----------
> > Apart from modular implementation the reason i moved from LIDS patch
> > without LSM --> LSM with OPENWALL/LIDS/SELINUX was because
> > LIDS provides administrative control over files and process and not
> > kernel level security . LIDS doesnt guarantee bufferover flow
> > solution. Openwall/LSM does
>
> Openwall doesn't do anything to protect against buffer overflows.
>
> > 2] Does LSM with all its security modules(Open wall , LIDS, SELINUX
> > )co-exist and IMPLEMENT a solution to buffer overflow , format
> > strings and race conditions ?
>
> LSM doesn't protect against coding errors in the kernel. It provides
> a *framework* for programmers to use to implement additional security
> checks for actions taken by userland programs.
>
> The various modules don't co-exist well at all unless you pick up Serge Hallyn's
> stacker patches - and even *then* you are *NOT* guaranteed that the various
> LSM modules will "play nicely" together. Arbitrary composition of security
> functions is a far-from-easily-done thing.
>
> > What are the vulnerabilities that would remain if I dont use LIDS?
>
> First off, we'd have to know what your threat model is - what are you trying
> to protect against, and what *arent* you worried about?
>
>
>
This archive was generated by hypermail 2.1.3 : Mon Jan 17 2005 - 22:34:20 PST