WDevSec

There are many ways to customize security of non-volatile objects (files, folders, services, registry keys etc.) on Windows systems. However when it comes to volatile Windows kernel objects which are created mainly by drivers and services (allowing them to be contacted via these objects) and recreated every time the creator driver/process starts the situation is much worse.

There are some GUI tools (e.g. WinObj and WinObjEx) which can change access permissions (DACLs) of these objects, but tools for automated securing of them seem to be pretty rare. This is what WDevSec does.

WDevSec is a command line utility able to view and change access permissions (DACLs) on Windows kernel objects. It can be used with Task Scheduler or Group Policy startup scripts to automate execution of it and set appropriate access permissions on every system startup.

WDevSec can process devices, named pipes, files, sections, events, mutants (mutexes), semaphores, timers, event pairs, I/O completion ports, registry keys, directory objects, folders, symbolic links and other objects (including LPC ports) with /A option.

WDevSec can also run in background and automatically set DACLs when it receives device change notification or on specified time intervals. With WDevSec comes with another utility - WDevList. This utility can list Windows kernel objects and (optionally) execute WDevSec on them. WDevList can be used in situations where several objects with similar names exist and they all need to be secured. WDevList can also provide bare listing as output for processing by other programs (such as batch scripts).

WDevSec uses SDDL strings containing only DACL. All account names in these strings are automatically turned to SIDs.

WDevSec may be a great solution to customize access to some Windows features as well as to third party software components. Almost every software which provides some kind of services to other programs accepts communication via some Windows kernel objects. Drivers normally create device objects, user mode software usually uses named pipes (objects in ??PIPE device), Windows components often uses LPC ports.