KERNEL PROCESS FIREWALL (KPF)
-----------------------------
version 0.1 - 12/02/2003
version 0.2 - 12/24/2003
-----------------------------
This document describes my ideas to support a process firewall inside the
linux kernel.  This work draws inspiration from CommInst [1]
(www.cs.wisc.edu/~raj/comminst) and tries to address some of CommInst's
limitations.

CommInst allows users to monitor and control the IO operations performed
by processes in their system. It uses the DynInst API to modify the
run-time image of a process and inserts a library into the process that
permits/denies future IO operations based on a user-specified policy. The
user need not have access to the application's source files or
rebuild/recompile the application. A tool like CommInst will be invaluable
for monitoring/controlling the IO operations of third-party software, for
which the source may not be available or if available, too complex to
analyze. CommInst cannot trap direct invocations of system calls that bypass 
glibc and this makes the system vulnerable to malicious attacks.

The only truly secure way of protecting a system is to trap the system
call in kernel space and permit/allow the call to proceed based on the
user-specified policy.  The Kernel Process Firewall (KPF) will be a module
that will 
	- accept policy input
	- enforce the policy specified	
I propose to add a new flag (_TIF_SYSCALL_KPF) to the task_info structure 
in the task_struct structure.  All System calls will be diverted into the
kpf module if this flag is set for any process.  The diversion tactic will
be similar to the call to syscall_trace_entry.  Specifically, it will look
like this in ENTRY(system_call) function defined in entry.S-
	#ifdef CONFIG_SECURITY_KPF
		testb $_TIF_SYSCALL_KPF,TI_FLAGS(%ebp)
		jnz syscall_kpf_entry
	#endif		
Each system call will take a performance hit when the CONFIG_SECURITY_KPF
is enabled, as it would have to check the flag in the  task_struct 
structure to  make a decision.  If the flag for a particular system call 
is set, the kernel would transfer control to do_kpf_policy(), which 
would implement the user-specified policy.  The policy will be available
in a hash-table (one for pids and one for executable names) in the kpf 
module.  The only system call that will be modified will be sys_execve
in order to support policy specification by name. 

The policy and the flag itself will be populated by looking up
/proc/sys/kernel/security/kpf-policy, which could be modified at anytime 
by a user with sufficient privileges.  A /proc and sysctl handler will 
be provided to update the policy information for all processes for which 
the user has specified a policy.  The user will be allowed to specify 
policy either for processes or for executables by providing full path.  
The format of the /proc/sys/kernel/security/kpf-policy file will be 
as follows -

#executable/pid          #syscall  #policy             #param
/usr/src/bin/foobar      open      DENY_REPORT         /etc/passwd

The first two fields are self-explanatory.  The policy field will support
the following values - DENY, DENY_REPORT, ALLOW, ALLOW_REPORT, SPOOF.  The
param field will take a , separated list of values that can be used to
control system calls at a finer granularity.  For instance, one may want
to deny all attempts to open the /etc/passwd file, while at the same time
allowing access to other files.  The SPOOF policy will allow users to fool
the application.  It will take an argument which has the -> operator.  For
instance,

#executable/pid          #syscall  #policy             #param
/usr/src/bin/foobar      open      SPOOF               /etc/passwd->/tmp/passwd
/usr/src/bin/foobar      open      SPOOF               /etc/passwd->FAIL

The first policy will always try to open /tmp/passwd instead of
/etc/passwd and the second will always return failure to the application.

I expect KPF (Kernel support for Process Firewall) to be of great value to
system administrators, security analysts and researchers in general and
solicit your comments.

Related Work (Annotated)
------------------------
1. CommInst - A Process Firewall
Website  - www.cs.wisc.edu/~raj/comminst
Comments - CommInst was one of my grad school projects and the 
motivation for KPF.

2. REMUS - Reference Monitor for Unix Systems
Website  - http://twiki.dsi.uniroma1.it/twiki/view/Remus/WebHome
Comments - REMUS is very similar to KPF and requires patching sys_execve. 
It is also geared toward detecting/preventing illegal invocation of 
critical system calls.  REMUS also concentrates only on some of the 
system calls, whereas KPF is more generic.

3. syscalltrack 
Website  - http://syscalltrack.sourceforge.net/index.html
Comments - syscalltrack allows privileged users to track invocations of
system calls across a system.  It does not provide per-process tracing,
monitoring or control that KPF is designed for.  Also, syscalltrack relies
on an EXPORTed sys_call_table (I believe they are working on a different
implementation).

Raj
---
I'll find a way ... or make one