Re: propolice support for linux

[Willy Tarreau]

Hi,

On Thu, Jan 13, 2005 at 11:52:22PM +0100, Han Boetes wrote:
> 1) Where an application compiled with PP is working worse or even
>    failing where it would work right without PP.

No idea on this one, I never tried PP, although I know how it basically
works since I worked on a similar concept in 97 of last century (but I
didn't have the skills to touch the compiler and still don't).

> 2) Where a bufferoverflow can be exploited even though the
>    application is compiled with PP.

1) any broken function of this kind :

int create_temp_dir(struct task *t, char *dir) {
   int err;
   int can_unlink;
   char dirname[MAXPATHLEN];

   can_unlink = (task->euid == 0);
   strncpy(dirname, dir, MAXPATHLEN);
   strcat(dirname, "/tmp");
   dirname[MAXPATHLEN] = '\0';

   if (err = mkdir(dirname, 0755)) {
      if (can_unlink) {
         unlink(dirname);
         err = mkdir(dirname, 0755);
      }
   }
   return err;
}

Get it ? Just pass any name of MAXPATHLEN length, and get
any existing file removed and replace with an empty directory.
Useful for hosts.deny, /var/log/messages, init scripts, etc...

2) all heap overflows (but not in kernel AFAIK).

I think you have a misconception about what a buffer overflow is. First,
propolice will be usable only against some *stack* overflows (which I agree
are the most common in userspace). But regular buffer overflows like above,
which can be triggered either in the stack on in the data space, are not
stopped. And heap overflows such as the double free bug in zlib will not
be prevented by propolice either.

> As an example where PP does work right the test-code provided by
> the propolice maintainer:
> 
>     /* test-propolice.c */
>     #define OVERFLOW "This is longer than 10 bytes"
>     #include <string.h>
>     int main (int argc, char *argv[]) {
>         char buffer[10];
>         strcpy(buffer, OVERFLOW);
>         return 0;
>     }
> 

This is kind, but this is also the easiest buggy program to write. The one
we all use when trying to write shell code. But this is far away from real
life, there often are other constraints.

Like others, I think that PP is close to useless in the kernel, but since
the patch is little and does not break anything, why not include it to let
people try it and return feedback ?

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/