System call whitelisting

Discussion in 'sandboxing & virtualization' started by Gullible Jones, Jun 7, 2014.

Thread Status:
Not open for further replies.
  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    Because I'm interested in just how insanely far you can take the HIPS strategy on Windows 7, in terms of protecting the kernel, before you reach a point of diminishing returns.

    There 330+ undocumented functions comprising the NT Native API:

    http://undocumented.ntinternals.net/

    But how many do most desktop applications use, through the Win32 API or directly?

    Would it be theoretically possible to
    - Apply a whitelist of acceptable system calls to an executable?
    - Apply a whitelist of acceptable parameters to each acceptable system call for the application?

    IOW, I'm talking about an extremely strict mandatory access control policy, with an eye less towards defending filesystem objects and more towards preventing persistent takeover.

    Note that I'm somewhat influenced here by what little I know of Windows; i.e. that it's a really weird OS that uses complicated, specialized system calls for almost everything. UNIX has idiosyncrasies, Windows is idiosyncrasies from what I've seen... Anyway my thought is that, with fewer syscalls being recycled for variegated purposes, those idiosyncrasies might make it easier to pull this off.

    (That said, this is a shot in the dark and I'm really not too optimistic about what it will turn up. Most of what I've seen been that in-application sandboxes are the way to go.)

    Edit: whoops, I think I posted an idea about this last year. Can someone please close this thread?
     
    Last edited: Jun 8, 2014
Loading...
Thread Status:
Not open for further replies.