Re: Security settings for drivers
From: Jim Cavalaris [MS] (jamesca@online.microsoft.com)
Date: 06/11/02
- Next message: Darien Fawkes: "CD Burning Rights for Limited Users"
- Previous message: Roger Abell: "Re: Security settings for drivers"
- In reply to: Roger Abell: "Re: Security settings for drivers"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Jim Cavalaris [MS]" <jamesca@online.microsoft.com> Date: Tue, 11 Jun 2002 01:13:54 -0700
understanding the distinction really involves understanding the
evolutionary differences between the APIs provided by the
system for configuring devices. the explanation involves
more plug and play than security admin topics, so it may
be somewhat off-topic, but i'll post anyways, in case it's helpful.
the main distinction is that the Configuration Manager API
is a bare-bones API set for directly configuring the device
state and properties as seen by the plug and play manager.
the only device-specific code typically executed is by the
kernel-mode driver for the device responding to the requests.
the setupapi Device Installer API set actually builds upon
the core functionality provided by Configuration Manager
APIs to provide full-detaured installation, and a flexible
model where user-mode device and class-specific installer
code can get "in-the-loop" on the installation and
configuration of devices to copy files, modify arbitrary settings,
provide additional ui, and perform additional work every step
of the way. in most cases, this requires Administrator rights.
because most devices now rely on such class/device specific
installer code to perform additional tasks, the Configuration
Manager routines have been superceded by the Device Installer
routines, and should not be called. calling the Configuration
Manager directly bypasses installer code, and could leave the
device in an inconsistent state, or with inconsistent settings.
and finally, to bring the point back to the original discussion,
because installer and driver code is executed in the context of an
Administrator or System-level account, non-Administrators
must not be able install or reconfigure driver files or settings,
since it could allow a limited user to cause untrusted code.to
be executed within a trusted context. only system-supplied or
Administrator-approved code should be allowed.
-jim.
-- This posting is provided "AS IS" with no warranties, and confers no rights. "Roger Abell" <mvpNOSPAM@asu.edu> wrote in message news:ePCVhlQECHA.2596@tkmsftngp05... > Yes, Jim, that does help. Thanks for the lengthy explanation. > I am going to have to read it again :-) but your description of > the right governing alteration of the run state of drivers, compared > to initial config/install, pretty much cleared this up for me. > > Thanks, > -- > Roger Abell > MVP (Windows Platform) Associate Expert > The Expert Zone - www.microsoft.com/windowsxp/expertzone > > "Jim Cavalaris [MS]" <jamesca@online.microsoft.com> wrote in message > news:3d044df8@news.microsoft.com... > > roughly speaking, the load/unload driver privilege is required by the > > Configuration Manager routines (i.e. the CM_* APIs) to change > > the running state of a device, initiate a rescan of plug and play > > devices, or to modify certain well-defined plug and play device > > and/or class properties. > > > > device installation, which is performed by the Setup Device Installer > > routines (i.e. setupapi, SetupDiXxx APIs) involves much more. it > > typically requires copying device inf files, drivers files, and class / > > co-installer libraries to system directories, and executing that code. > > also, settings that are not among those pre-defined by the Configuration > > Manager may be set, deleted or modified, as specified by the inf, > > or class/co-installers. those modifications are performed directly, > > rather than by the Configuration Manager. > > > > since the locations of these system files and persistent device > > information storage are securable objects (file and registry), they're > > guarded by access control, not privileges. specifically, > > Administrators group access rights are required to modify them. > > so while it is currentoy possible to change some device settings > > and state via the Configuration Manager with only load/unload driver > > privilege, this doesn't account for all the actions necessary to install > > devices. > > > > by the way - much of the functionality for configuring devices typically > > seen in the os (via components like device manager) is actually > > performed via the device installer routines (so that class and/or device > > specific installer code may be executed during the operation), so you'll > > find that most device configuration tasks require Administrators access > > as well. > > > > in future releases of Windows, plug and play will standardize more > > on requiring Administrators group access for device installation and > > configuration tasks, even when performed directly via the > > Configuration Manager. use of the load/driver privilege will be > > confined to operations that directly modify the running state of a device, > > without modifying its persistent state, or any persistent settings. > > > > lastly - i should mention that this is just a description of how plug and > > play uses the load/unload driver privilege. this privilege is a > well-known > > windows privilege, so any component, subsystem, or driver can require > > it for any operation it feels appropriate, indepently of its meaning with > > respect to plug and play. > > > > hope this helps, > > jim. > > > > -- > > This posting is provided "AS IS" with no warranties, and confers no > rights. > > > > > > "Roger Abell" <mvpNOSPAM@asu.edu> wrote in message > news:OlhEKEtDCHA.2712@tkmsftngp04... > > > Hi Jim, > > > > > > Off hand, can you simply explain what this right to > > > "Load and unload device drivers" does govern ? > > > > > > TIA, > > > -- > > > Roger Abell > > > MVP (Windows Platform) Associate Expert > > > The Expert Zone - www.microsoft.com/windowsxp/expertzone > > > > > > "Jim Cavalaris [MS]" <jamesca@online.microsoft.com> wrote in message > > > news:3d014cc4$1@news.microsoft.com... > > > > device drivers run in the context of the system, not any single user. > > > > updating a device driver introduces new (and potentially untrusted) > > > > code on the system that has the ability to affect the entire state of > > > > the machine, as well as that of any/all other users. similarly, > > > > disabling a device affects the current or future running state of the > > > > system, for both system components and other users who may > > > > be using services provided by that device. > > > > > > > > non-Administrators should not be allowed to make system-wide > > > > changes that can affect other users, so any changes to device > > > > drivers must be considered an Administrative task. > > > > > > > > the "Load and unload device drivers" privilege is just one requirement > > > > for configuring devices on the system. most device configuration > > > > tasks truly require Administrator group access rights (i.e. caller > must > > > > be a member of the local Administrators group). assigning the "load > > > > driver" privilege to other user groups will not allow them to update > > > > device drivers, or perform most device configuration tasks. > > > > > > > > hope this helps, > > > > jim. > > > > > > > > -- > > > > This posting is provided "AS IS" with no warranties, and confers no > > > rights. > > > > > > > > > > > > "Roger Abell" <mvpNOSPAM@asu.edu> wrote in message > > > news:#vy5HWTDCHA.1700@tkmsftngp04... > > > > > Have you tried using the policy named > > > > > Load and unload device drivers > > > > > which is a User Right in the Local Policies under Computer > > > > > By default this is granted only to Administrators > > > > > -- > > > > > Roger Abell > > > > > MVP (Windows Platform) Associate Expert > > > > > The Expert Zone - www.microsoft.com/windowsxp/expertzone > > > > > > > > > > "Thorsten Tarrach" <tho_public@nym.alias.net> wrote in message > > > > > news:eD3lN8JDCHA.1660@tkmsftngp02... > > > > > > How do I change the security settings for my drivers and devices. > The > > > > > goal: > > > > > > A non-admin should be able to deactivate a certain device and even > > > update > > > > > > its driver. > > > > > > Any ideas? > > > > > > Thanks, Thorsten > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
- Next message: Darien Fawkes: "CD Burning Rights for Limited Users"
- Previous message: Roger Abell: "Re: Security settings for drivers"
- In reply to: Roger Abell: "Re: Security settings for drivers"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
