On Fri, Aug 15, 2003 at 11:01:54PM +0100, Alaric B Snell wrote: > > If the target program *ever* performs, say, the syscalls required to > start up a shell (fork, some socket calls to set up a listener, accept, > then dups of fds then exec, say?) - even with other syscalls inbetween - > then the shell code might well perform the syscalls in order, using > dummy arguments for syscalls it doesn't want (open /dev/zero and read > blocks of 0 bytes from it and so on). Wagner and Soto published a paper about these 'mimicry' attacks: http://www.cs.berkeley.edu/~daw/papers/mimicry.pdf ... with regards to intrusion detection systems; same applies for host based security. It's a problem that any behavioural models based purely on syscalls have a tough time getting around. That, and how to reduce the size of the FSM generated if you trace through all possible permutations of the control flow statically. > But still - it sounds promising; it reminds me of an idea I was > considering (but Theo de Raadt hated!) of allowing processes to drop > certain syscalls (or certain modes of operation of syscalls - many are > multi-function), shedding priveleges in the same manner as setuid-ing > down to nobody or chrooting. So Apache could, after binding to its > ports, drop the ability to bind to ports. After opening its log files, > it could drop the ability to open files for writing. Each child process > would abandon fork rights, and exec rights as soon as it sees it's not a > CGI. It just adds another layer of complexity to an already over-complex kernel/userland interface. If you're going to change the source like this, I prefer privilege separation instead, which works without kernel changes. -- Anil Madhavapeddy http://anil.recoil.org University of Cambridge http://www.cl.cam.ac.uk
This archive was generated by hypermail 2b30 : Mon Aug 18 2003 - 17:34:22 PDT