But your analysis is flawed then, since we can delegate the ability to start a driver (SeLoadDriverPrivilege) to an arbitrary group or user. Provided I have access to the registry (controlled by the ACL on the Services key), I can create the service key and manually start the driver (ZwLoadDriver). I just cannot do it via the Service Control Manager because it applies a FIXED ACL to its own control object. Of course, I can create the service key and then reboot the system and then the SCM will pick up that registry key anyway.
There are many aspects of security we don’t discuss here, but certainly one principle to keep in mind is that we often try to make things more difficult to achieve just to “raise the bar”. For example, it is impossible to eliminate covert channels from within a system, but we can mitigate their bandwidth. Similarly, we can make it more difficult for an arbitrary attack to beat away at the box. Think of it as similar to the reason we put locks on our windows - the windows CAN be broken, so the locks aren’t really useful and yet it makes it less convenient to break in.
The harsh truth is that most systems are compromised via the users; partial authority to do something often makes it much easier to gain full control. Given that reality, it requires that we add other security features (audits and alarms) to track how the system was compromised.
Within the Windows security model, there is no special (distinguished) magic user. UNIX has the “root” account but while Windows HAS distinguished accounts, you can actually gut those accounts and restrict their privileges (well, perhaps SYSTEM is an exception here, since it represents the local running system itself, but it is not a user level account).
Indeed, your point that once a driver is loaded it can do anything is a valid one and I suspect you’ll see steps in future versions of Windows that try to mitigate against this. For example, perhaps more people will start to use alternate system processes (Services for UNIX does this, for example). Nothing would prevent such alternate processes from having a different set of credentials…
My point however remains: concentrating all security within a single well-known group would seem to be a weakness, not a strength. In many ways this is comparable to mastered key systems on buildings - they seem like a good idea but in fact make the overall system FAR less secure. By concentrating all power in a single group and user account, we simplify the jobs of hackers because they can focus their attention on that one weak spot.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
Sent: Friday, November 19, 2004 2:22 PM
To: ntdev redirect
Subject: Re:[ntdev] Bluetooth driver stack implementations
Well, ok, but if you can install a driver, you can effectively do any of
those other things that the Admin group can do anyway, so isn’t this a
difference that makes no difference?
It seems to me that allowing the “install drivers” privilege outside of
the Admin group would just give you a false sense of security.
Tony Mason wrote:
Sad, but true. This is an unfortunate blindness on how components within Windows use the OS provided security mechanisms - because it would be nice to delegate just certain privileges/operations to a restricted account, rather than concentrating all authority in one account (or one group) as seems to have become the default. Note that this is NOT a restriction on how the Security Reference Monitor works, but rather the na?ve insistence in other OS components that all power should be concentrated into a specially nominated group.
For example, you might want to create an account that has the ability to install new devices without the numerous other rights that are inherent in the rights assigned to the Admin Group (for example, Admin Group can override security checks using restore privilege). The current implementation of the Service Control Manager REQUIRES that the request come from the Admin Group - no choice. So you could modify the registry and force a reboot (which is likely to be required for a filter anyway) but you cannot do this in dynamic fashion.
In general, good security policy is to divide up tasks and compartmentalize the security rights to provide only those rights that are required. This has become my current hot-button because I recently spent time trying to figure out how to configure an account that was NOT a member of Admin Group that could install a service and found the SCM restriction. Then I went to figure out how to create a unique service account for interacting with a kernel driver as a counter-point to the hideous “let’s look at the undocumented image name in the EPROCESS” hack and found that I can’t use IoCreateDeviceSecure to create such an SD (with a non-well-known account) and the APIs necessary to do this correctly are not exposed. So, I’m restricted to using an account that is an Admin Group member which means that if I screwed up anything in my service, instead of merely compromising the control over my device, I have compromised the entire box.
The concentration of privileges and propensity for giving people unlimited control over the box to compensate has led to the current situation in which 90% of the computers are used by people with “Admin” privileges that then makes it far easier for attacks against those boxes to gain complete control once they are so compromised.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class April 4, 2004 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, November 17, 2004 6:52 PM
To: ntdev redirect
Subject: RE: [ntdev] Bluetooth driver stack implementations
If they are not an admin, they cannot touch the filters on a device nor enable/disable a service
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Wednesday, November 17, 2004 3:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
In very rare case, user logs in with account other than root, well in Windows.
Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com
-----Original Message-----
From: Doron Holan [mailto:xxxxx@windows.microsoft.com]
Sent: November 17, 2004 4:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
As said many times, if someone is an admin on the box (which is required to muck around w/drivers), you have no security b/c they can disable anything on the machine.
d
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Wednesday, November 17, 2004 11:49 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
Filter for this purpose is probably not solid.
It’s not difficult for average users to remove a filter driver if (s)he really wants to use his Bluetooth or other stuff.
Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com
-----Original Message-----
From: Shahar Talmi [mailto:xxxxx@safend.com]
Sent: November 17, 2004 6:02 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
I am probably going to filter above the host controller, maybe even use a
bus filter driver (I would like to implement the driver in a way that will
allow me to know as little as possible about the actual Bluetooth protocol
stack).
One of the many potential purposes is to deny connections, but this is not
where it stops.
Do you think that filtering the WIDCOMM and Microsoft implementations will
cover almost all users ?
Shahar
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, November 16, 2004 10:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
If you filter below the host controller, the USB HCI is completely
standardized and you can write a filter that covers all USB devices.
Serial is a different story, although H5 should cover it for the most part.
What is the purpose of the filter? To deny connections?
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Tuesday, November 16, 2004 11:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
I plan to write a filter driver for a Bluetooth driver stack (probably for
the Bluetooth Host Controller, or atleast I think this is the right term).
Since I want my filter to work on as many computers as possible and since
there are more then one implementations, it seems I would have to implement
a different filter for each implementation.
Therefore, I must know what implementations exist, and I’m hoping that
WIDCOMM and Microsoft are covering enough users for me to be satisfied with
only being able to filter those implementations.
Shahar
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, November 16, 2004 9:15 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
OK, I’ll bite. Why is this important? What are you trying to do?
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Tuesday, November 16, 2004 11:08 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
So, is it safe to assume WIDCOMM and Microsoft’s implementations are used by
almost all Windows users that require Bluetooth support?
Isn’t there any other implementation which is even close to be widely used?
Shahar
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, November 16, 2004 7:41 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bluetooth driver stack implementations
3com’s stack is dead and has been for a long time.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Programmers Society
Prokash Sinha
Sent: Tuesday, November 16, 2004 9:26 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Bluetooth driver stack implementations
3Com had a stack long back (2001 time fram) and it was essentially ESI
(extended system’s joint work with 3Com) stack …
-pro
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
…/ray..
Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com