Balwinder Singh wrote: > Brief Introduction of EFC > ------------------------- > > 1. Kernel runs in kernel space, which cannot be modified by user space > programs. Each request from program ends up calling a routine in kernel > space called syscall. Lets call syscall with arguments just syscalls > > Each program will make a defind set of syscalls to achieve its > objective. Now idea is to watch syscalls that a program is supposed to > make during its run time. A database which describes the syscalls that a > program can make is called behavior model of the program. Lets assume we > can generate a behavior model which perfectly describes an application. > Now any deviation from behavior model of program essentially indicates > an intrusion at real time. Thus a corrective action can be taken. This > makes kernel intelligent which knows which program should do what, > rather than a slave of program in which any program can ask anything and > kernel will provide it. That is indeed a nice approach to defence. It will stop a whole load (if not all) of current exploits, which are written without it in mind. However, what ways can we think of to try to attack it? 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). I guess a lot of server apps only bind listening sockets early on in their lives (SIGHUP aside). So maybe forking off a shell might become too hard to do in general. But daemons that write to files as root and so on are often exploited to put stuff in /etc/inetd, /etc/passwd, crontabs, and executables. Would it protect against a careful subversion of such a program that is designed to act within the syscall behaviour of the original program? Buffer overflows that do not gain control of execution but manage to overwrite, say, the name of the log file to append to would sneak through without even trying, needless to say. 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. There could be two levels of 'dropping' a right - one that's inherited across exec and one that's not. When you run a chrooted system then the scripts that start sshd and whatnot inside the chroot could drop system management syscalls like halt/reboot and writing to sysctls. Many apps could start by dropping a whole load of abilities they plain don't need. An NTP server could open its log file then drop all filesystem related syscalls right off. It'd still have the file descriptor of the log file to write() to, but otherwise its only contact with the kernel would be IO on the pre-opened UDP socket and log file, access to the system clock, sleep, and exit when it's had enough. No fork, exec, opening new files, etc. ABS
This archive was generated by hypermail 2b30 : Mon Aug 18 2003 - 09:44:16 PDT