Re: Need help. Proof of concept 100% security.

[Alaric B Snell <alaric () alaric-snell com>]

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