Re: Help hardening interactive processes in Windows

[Miles Stevenson <miles () mstevenson org>]

Hi Oki.

<snip>
> Could you please give me some examples of how to harden Interactive
> processes, to keep them from running under a higher level accounts ?
</snip>

I'm not completely sure what you mean by "running under a higher level 
accounts [sic]", but I THINK you mean the concept of resitricting a process 
so that if it is compromised, an attacker will have few privelages on the 
system to do more damage.

This is a concept that the Unix world has had for quite some time now in the 
form of a system call known as "chroot" (a "system call" is a way that you 
can signal to your kernel to execute a particular "function" or "block" of 
code/instructions). The recent BSD's have taken this idea further with their 
concept of a "jail". The idea is simply to "trap" a running process inside of 
this cage/jail, so that any attacker that exploits the process is also 
limited to the confines of this cage/jail. 

Unfortunately, the Windows world has no concpet of this, and therefore, no 
implementation. The Windows kernel has no means to restrict a running process 
inside of a "sub" environment. I'm certainly not a Windows authority, but I 
think your best bet would be to investigate the "runas" command (you might 
have to install the windows resource kit, I can't remember). Depending on 
what you are trying to execute, you might be able, at the very least, to use 
"runas" to run the process as a non-admin user, and restrict that users 
rights using NTFS permissions and the Windows Security Policies. It's not 
quite as elegant as a chroot() or jail(), but it's better than nothing!

I would be interested in how successfully this works if you experiment with 
this. Please share!
 
-- 
Miles Stevenson
miles () mstevenson org
PGP FP: 035F 7D40 44A9 28FA 7453 BDF4 329F 889D 767D 2F63

Attachment: _bin
Description: