Hi All
Yes we had the same problem, but found that with XP’s “enhanced security
options”, using the DDK example for XP is seems to set the correct access
rights. Also you can manipulate the security settings from security gui…
This seems to work fine… so you don’t need sysinternal’s code
just check the O/S version and remove the code for XP… It worked for us.
Steve
----- Original Message -----
From: “Michal Vodicka”
To: “NT Developers Interest List”
Sent: Monday, March 03, 2003 10:52 PM
Subject: [ntdev] RE: Device driver object security settings to enable
non-priv’d user access
> I guess you’re right. Now how to force others to fix their drivers which
use
> this old good proven method… I’ll try it with vmware.
>
> It seems as partial MS fault. If w2k behave differently (and I’d bet
because
> there was no problem), they should explain this method isn’t safe anymore.
> Yes, it was undocumented but still widely used.
>
> Best regards,
>
> Michal Vodicka
> STMicroelectronics Design and Application s.r.o.
> [michal.vodicka@st.com, http:://www.st.com]
>
> > ----------
> > From: xxxxx@nryan.com[SMTP:xxxxx@nryan.com]
> > Reply To: xxxxx@lists.osr.com
> > Sent: Monday, March 03, 2003 10:56 PM
> > To: xxxxx@lists.osr.com
> > Subject: [ntdev] RE: Device driver object security settings to enable
> > non-priv’d user access
> >
> > I guess it’s time to try to use IoCreateDeviceSecure (described in a
> > recent NT Insider article). I originally shied away from this since the
> > article implied it wasn’t NT4-compatible, but maybe this is incorrect -
> > the function is implemented in a static library, after all.
> >
> > - Nicholas Ryan
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Nicholas Ryan
> > > Sent: Monday, March 03, 2003 1:42 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] RE: Device driver object security settings
> > > to enable non-priv’d user access
> > >
> > >
> > > After some snooping I’ve partially figured out what’s going
> > > on. The security descriptor is created and assigned to the
> > > device object deep in undocumented function ObAssignSecurity.
> > > What happens is this function creates the base descriptor
> > > using SeAssignSecurity - which returns memory allocated
> > > simply by ExAllocatePool. Then the undocumented function
> > > _IopGetSetSecurityObject is called to assign the descriptor
> > > to the device object. However, it doesn’t simply point the
> > > device object to this descriptor - instead it uses an
> > > identical descriptor allocated from a private cache of
> > > security descriptors maintained by the Object Manager. (The
> > > original descriptor passed in is just freed). Apparently this
> > > is done for memory savings since objects in this cache are
> > > refcounted to avoid duplication. The additional header you’re
> > > seeing before the memory for the descriptor proper is the
> > > header for objects in this cache.
> > >
> > > This still doesn’t explain why the header is being touched
> > > while the device object is in use. However, I’m not sure your
> > > method of modifying the descriptor in-place is safe either,
> > > since this is a cached and potentially shared descriptor
> > > (descriptors in the cache are indexed by a hash of the
> > > descriptor’s contents). What a mess.
> > >
> > > - Nicholas Ryan
> > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com] On Behalf Of
> > > Michal Vodicka
> > > > Sent: Monday, March 03, 2003 11:28 AM
> > > > To: NT Developers Interest List
> > > > Subject: [ntdev] RE: Device driver object security settings
> > > > to enable non-priv’d user access
> > > >
> > > >
> > > > You missed the point. XP seem to expect object header before
> > > > the SD pointed by device object. So if it points to your
> > > > block of memory, OS accesses and writes to random memory
> > > > before your new SD.
> > > >
> > > > What you describe would only cure symptom and shield the
> > > real problem.
> > > >
> > > > Best regards,
> > > >
> > > > Michal Vodicka
> > > > STMicroelectronics Design and Application s.r.o.
> > > > [michal.vodicka@st.com, http:://www.st.com]
> > > >
> > > > > ----------
> > > > > From: xxxxx@nryan.com[SMTP:xxxxx@nryan.com]
> > > > > Reply To: xxxxx@lists.osr.com
> > > > > Sent: Monday, March 03, 2003 8:17 PM
> > > > > To: xxxxx@lists.osr.com
> > > > > Subject: [ntdev] RE: Device driver object security
> > > > settings to enable
> > > > > non-priv’d user access
> > > > >
> > > > > Easiest solution when using the SysInternals approach: save the
> > > > > pointer to the original descriptor, and point the device
> > > object to
> > > > > your new descriptor. When it comes time to delete your
> > > > device object,
> > > > > free your descriptor, then point the device object back to the
> > > > > original descriptor, and then delete the device.
> > > > >
> > > > > - Nicholas Ryan
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: xxxxx@lists.osr.com
> > > > > > [mailto:xxxxx@lists.osr.com] On Behalf Of
> > > > Michal Vodicka
> > > > > > Sent: Monday, March 03, 2003 10:35 AM
> > > > > > To: NT Developers Interest List
> > > > > > Subject: [ntdev] RE: Device driver object security settings
> > > > > > to enable non-priv’d user access
> > > > > >
> > > > > >
> > > > > > It seems there is a problem with this approach at XP.
> > > Last week I
> > > > > > encountered something similar with VMware parallel driver which
> > > > > > access caused random data overwrite. It seemed as the problem
> > > > > > caused my driver I’m working on so I investigated the
> > > problem and
> > > > > > found OS tried to access data before security descriptor for
> > > > > > this driver device. The descriptor was created the way you
> > > > > > describe; they create new one and change
> > > > > > DeviceObject->SecurityDescriptor to its address. They don’t
> > > > > > free the old
> > > > > > DeviceObject->one
> > > > > > and I presume it is because it caused the same problem as
> > > > you have.
> > > > > >
> > > > > > I guess device security descriptor at XP are objects and OS
> > > > > > expects object header prepended to memory pointed with
> > > > > > DeviceObject->SecurityDescriptor. It would explain why
> > > > > > ExFreePool fails: the real allocation starts several
> > > bytes before.
> > > > > > Please note I only guess; I’d appreciate if somebody
> > > can confirm
> > > > > > or disprove this observation or give any more info
> > > about XP device
> > > > > > SDs.
> > > > > >
> > > > > > Also please note above described approach (ignore problem and
> > > > > > don’t free original descriptor) is plain wrong and can
> > > cause BSODs
> > > > > > or worse, random data overwrite. You can try different
> > > > > > approach: change original SD contents instead. It is usable
> > > > > > way if all you need is to change an ACE mask. I used it at
> > > > > > w2k with no problem.
> > > > > >
> > > > > > 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: Monday, March 03, 2003 6:42 PM
> > > > > > > To: xxxxx@lists.osr.com
> > > > > > > Subject: [ntdev] RE: Device driver object security
> > > > > > settings to enable
> > > > > > > non-priv’d user access
> > > > > > >
> > > > > > > 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
> > > > > > >
> > > > > > > —
> > > > > > > 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@nryan.com To
> > > > > > unsubscribe send a blank email to
> > > xxxxx@lists.osr.com
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > —
> > > > > 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@nryan.com
> > > > To unsubscribe send a blank email to
> > > xxxxx@lists.osr.com
> > > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@nryan.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> >
> > —
> > 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@bemac.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>