RE: Device driver object security settings to enable non-priv'd user access

NTDEV
1

For PnP devices, there is a way of doing this via INF file, it is
documented.

----- Original Message -----
From: “Michal Vodicka”
To: “NT Developers Interest List”
Sent: Saturday, January 25, 2003 2:37 AM
Subject: [ntdev] RE: Device driver object security settings to enable
non-priv’d user access

> You should write a function using mentioned ones which changes SD as
you
> need and call it after your device is created to change its SD. It
should be
> done at PASSIVE_LEVEL. I’m not aware about a way how to set device
security
> during installation but it doesn’t mean there isn’t some.
>
> Best regards,
>
> Michal Vodicka
> STMicroelectronics Design and Application s.r.o.
> [michal.vodicka@st.com, http:://www.st.com]
>
> > ----------
> > From: Barry.Kierstein@HP.Com[SMTP:Barry.Kierstein@HP.Com]
> > Reply To: xxxxx@lists.osr.com
> > Sent: Friday, January 24, 2003 10:09 PM
> > To: xxxxx@lists.osr.com
> > Subject: [ntdev] RE: Device driver object security settings to
enable
> > non-priv’d user access
> >
> > Thanks for the input! From what I have read, can I put the
various
> > routines like RtlSetDaclSecurityDescriptor or SetSecurityInfo in
the
> > DriverEntry routine? Or, is there a way to set this once at
installation
> > time?
> >
> > Barry
> >
> > —
> > You are currently subscribed to ntdev as: michal.vodicka@st.com
> > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

2

Hello!

I thank you all for your help so far! Here is an update of what I
have tried to date. There were two suggestions: 1) change the security
via the .INF file, and 2) put some function calls to do this in the
DriverEntry routine of the driver. I took the .INF file suggestion first,
as that would supposedly fix the problem from the beginning. However, so
far this has not worked. Maybe something is superceding what is specified
in the .INF file, but the DACL part of the security descriptor is not
changed from the default.

The default DACL for the device is:

D:(A;;FX;;;WD)(A;;FA;;;SY)(A;;FA;;;BA)(A;;FX;;;RC)

The first ACE specifies that WorlD has File eXecute access Allowed. I
changed this to (A;;FA;;;WD), which is File All access. Below is part of
the .INF file that I changed according to the AddReg entry in the DDK
documentation:

;-------------------------------------------------------------------------
; Service installation support
;-------------------------------------------------------------------------
[Install.Services]
AddService=AmNdis50,AmNdis50_Service_Inst

[AmNdis50_Service_Inst]
DisplayName = %AmNdis50_Desc%
ServiceType = 1 ;SERVICE_KERNEL_DRIVER
StartType = 3 ;SERVICE_DEMAND_START, SERVICE_SYSTEM_START = 1
ErrorControl = 1 ;SERVICE_ERROR_NORMAL
ServiceBinary = %12%\AmNdis50.sys
LoadOrderGroup = NDIS
AddReg = AddReg_AmNdis50_Service_Inst
Description = %AmNdis50_Desc%

[AddReg_AmNdis50_Service_Inst]
HKR,“TestKey”,“Test value”
HKR,Security,“D:(A;;FA;;;WD)(A;;FA;;;SY)(A;;FA;;;BA)(A;;FX;;;RC)”

[AddReg_AmNdis50_Service_Inst.security]
“D:(A;;FA;;;WD)(A;;FA;;;SY)(A;;FA;;;BA)(A;;FX;;;RC)”

[Install.Remove]
DelReg=Del_AM_Static_reg

[Del_AM_Static_reg]
HKR,“TestKey”

The “TestKey” stuff is to just make sure that this .INF file has
really executed.
If there are any suggestions, please let me know. I am proceeding on
option 2 for now. Thanks!

Barry Kierstein

3

I have not been following the whole thread, but I think you made the wrong
security setting in your INF. From your snipped it looks you apply the
security to the service and not the device object itself.
See the following sections of the DDK documentation for details:
Creating Secure Device Installations
Tightening File-Open Security in a Device INF File

The .NET DDK has new security functions that allow you to specify the
security settings when creating device objects.
The function is IoCreateDeviceSecure.
See the OSR NT Insider article form the July/August 2002 issue for a
detailed description.

More importantly don’t you think opening up the access to your driver may
create a security hole? Do you validate in your
DispatchCreate routine the caller (your app) and do the proper access
check?
The MS sample NDISUIO does not. If you change the access rights that any
user can open the driver then any malicious app could do that. Any script
kiddie could build a little VB app and create potential havoc.

I think the proper way would be to implement a WMI interface in your
driver. Your app. could then securely interface with the driver.

OSR offers a great new seminar that focuses on the subjects of driver
reliability and security: Writing Reliable Drivers for Windows

Gernot Seidler
Vibren Technologies, Inc.
http://www.vibren.com

Hello!

I thank you all for your help so far! Here is an update of what I
have tried to date. There were two suggestions: 1) change the security
via the .INF file, and 2) put some function calls to do this in the
DriverEntry routine of the driver. I took the .INF file suggestion first,
as that would supposedly fix the problem from the beginning. However, so
far this has not worked. Maybe something is superceding what is specified
in the .INF file, but the DACL part of the security descriptor is not
changed from the default.

The default DACL for the device is:

D:(A;;FX;;;WD)(A;;FA;;;SY)(A;;FA;;;BA)(A;;FX;;;RC)

The first ACE specifies that WorlD has File eXecute access Allowed. I
changed this to (A;;FA;;;WD), which is File All access. Below is part of
the .INF file that I changed according to the AddReg entry in the DDK
documentation:

;-------------------------------------------------------------------------
; Service installation support
;-------------------------------------------------------------------------
[Install.Services]
AddService=AmNdis50,AmNdis50_Service_Inst

[AmNdis50_Service_Inst]
DisplayName = %AmNdis50_Desc%
ServiceType = 1 ;SERVICE_KERNEL_DRIVER
StartType = 3 ;SERVICE_DEMAND_START, SERVICE_SYSTEM_START = 1
ErrorControl = 1 ;SERVICE_ERROR_NORMAL
ServiceBinary = %12%\AmNdis50.sys
LoadOrderGroup = NDIS
AddReg = AddReg_AmNdis50_Service_Inst
Description = %AmNdis50_Desc%

[AddReg_AmNdis50_Service_Inst]
HKR,“TestKey”,“Test value”
HKR,Security,“D:(A;;FA;;;WD)(A;;FA;;;SY)(A;;FA;;;BA)(A;;FX;;;RC)”

[AddReg_AmNdis50_Service_Inst.security]
“D:(A;;FA;;;WD)(A;;FA;;;SY)(A;;FA;;;BA)(A;;FX;;;RC)”

[Install.Remove]
DelReg=Del_AM_Static_reg

[Del_AM_Static_reg]
HKR,“TestKey”

The “TestKey” stuff is to just make sure that this .INF file has
really executed.
If there are any suggestions, please let me know. I am proceeding on
option 2 for now. Thanks!

Barry Kierstein

4

All,

Thanks for your great suggestions. I have followed the SysInternals
example in modifying the security descriptor in the device object. There
is one remaining oddity.

Basically, the SysInternals example does the following:

  1. gets the security descriptor from the device object
    (it is in relative format),
  2. creates an empty absolute format security descriptor,
  3. reads the device object security descriptor for various attributes
    and sets these in the absolute security descriptor,
  4. converts the absolute security descriptor to relative format security
    descriptor,
  5. frees the device object’s security descriptor using ExFreePool, and
  6. sets the device object’s security descriptor pointer to the new
    relative format security descriptor.

This works fine on Windows 2000. On Windows XP, it bugchecks when
trying to execute the ExFreePool call with a stop code of 0xC2.

BAD_POOL_CALLER (c2)
The current thread is making a bad pool request.
Typically this is at a bad IRQL level or double freeing the same
allocation, etc.
Arguments:
Arg1: 00000007, Attempt to free pool which was already freed
Arg2: 00000cd4, (reserved)
Arg3: 00000027, Memory contents of the pool block
Arg4: e13f5318, Pointer to pool header

Any ideas why this is happening? Thanks…

Barry Kierstein