Disable USB-C ports

@MBond2 said:
I think I must have missed something, but is this all devices on a particular port, or particular devices (inclusively or exclusively) on any port?

the viability of any solution on any os depends to a great extent on these answers i think

The requirement is to disable an specific physical port so, any device will be attached.

I believe the easiest way (althought extremely not recommended), would be to hook the PnP major dispatch of the USB Hub Driver and return an invalid NTSTATUS whenever it is an arrival of a (No idea how you’re going to detect this) USB-C device.

This will most likely display a warning icon in the Device Manager for the USB Hub Driver.

would be to hook the PnP major dispatch of the USB Hub Driver

That is not a good idea, or anything remotely like a supported approach.

We have filter drivers in Windows for a reason.

Peter

What ready product would you recommend?

Most of so called “endpoint security” products have some kind of USB control.
I haven’t used this stuff recently (concur with Mr. Roberts on products that exist to tamper with normal operation of my Windows system)
If you find the freedesktop link interesting, the maintainers of this thing are on this forum. They may be able to help you.
– pa

2 Likes

@“Peter_Viscarola_(OSR)” said:

would be to hook the PnP major dispatch of the USB Hub Driver

That is not a good idea, or anything remotely like a supported approach.

We have filter drivers in Windows for a reason.

Peter

Hi, please forgive my ignorance, but I have the same problem which I intend to approach by developing a USB Bus Filter Driver (UpperFilter) to change the DEVICE_RELATIONS list after the Bus responded to the PNP_MN_QUERY_DEVICE_RELATIONS, whenever a new device is plugged in an arbitrary USB port. The intention is to “soft disable” that port by preventing any new device connecting to it from being enumerated.

Is it possible to write this as a KMDF USB Hub Filter Driver (maybe modifying one of the sample drivers from Microsoft’s Github)?

Thanks in advance and, again, forgive me if I misunderstood some basic concept for I’m new to this kind of endeavor.

Adriano Lemos.

Yes it is possible to write a bus filter driver for usb. It is a lot of
work. KMDF does not support bus filter drivers, but with a bit of effort
you can use kmdf to do most of the work and then escape out of kmdf to do
the rest using WDM.

Mark Roddy

2 Likes

Thanks @Mark_Roddy. Much appreciated the information.
Can you (or any member) point me to some repository or post with sample code showing how I could accomplish this task? That could save me an awful lot of time.

Thanks again,
Adriano Lemos.

@“Peter_Viscarola_(OSR)” said:

I happen to have a particular aversion to driver projects whose primary aim is to PREVENT the normal operation of my Windows system

Ordinarily, me too. But, you know, not every system running Windows is an “ordinary” Windows system. Consider systems that are used to host machine tools and control

We’ve spent the last several years working with a major industrial security vendor to build and refine a complex security system for USB devices in such settings. It fills a real need.

I am very much with you, and from a different industry.
We had a similar issue in the past where customer required “only these select special USB devices” to be allowed, and not anything else. In any USB port in system, in any order.

A lot of work was done to accomplish it, and one lesson was the growing frustration of management with Windows 10 architecture.

I wonder is the situation with this task any better on Linux or in Mac ?

Thanks,
Sergey

one lesson was the growing frustration of management with Windows 10 architecture

That seems like… a very unusual “lesson” – We’ve done some significant work with USB device security, and while I agree that solving it non-trivially is a difficult and complex problem, I’m not sure I’d lay the blame at the feet of “Windows 10 architecture.”

Mostly, the issues that we’ve encountered are because USB – and the vastness of its device classes – is a PITA. When is a flash drive not “just” a flash drive? When its a USB UAS flash drive.

Not to mention the positive CRAP that vendors release as far as USB devices. Just look at how difficult it is to find a USB flash drive that’s actually been tested and has passed USB logo requirements.

Peter

2 Likes

@“Peter_Viscarola_(OSR)” said:

one lesson was the growing frustration of management with Windows 10 architecture

That seems like… a very unusual “lesson” – We’ve done some significant work with USB device security, and while I agree that solving it non-trivially is a difficult and complex problem, I’m not sure I’d lay the blame at the feet of “Windows 10 architecture.”

I certainly agree with you on that Peter.
And that is why when someone higher up tells me that they were told should we design our instrument based on WindRiver OS or Linux than such task would be simple I don’t know if that is true or just something told them by Linux camp.
That’s why I asked if anyone can comment on how complex the same would be in other OS.

Sergey

It all depends on what you need to do, and what else is required for your instrument.

If the job is “we only will allow this list of VIDs and PIDs to connect via USB”… well, that’s pretty easy on any OS. If things get more complex, then they get complex quickly on any OS.

But really, isn’t what USB devices are allowed the “side show”? Isn’t the real question “How do we write the embedded app(s) on the instrument”? That (and timing needs, of course) is what usually causes folks to choose one OS over the other.

Peter

@“Peter_Viscarola_(OSR)” said:
But really, isn’t what USB devices are allowed the “side show”? Isn’t the real question “How do we write the embedded app(s) on the instrument”?

It is not the question in my case if user will see some USB device which we don’t want them to see. It is about to meet security requirements in USB area - some from customer and some external (FDA here and its counterpart in EU), and within budget.
E.g.
If the security in USB can be met with OS 1 a lot easier than with OS 2 then they prefer OS 1. But if OS 1 does not natively support FIPS then it is a no go. And so on like that.

But the point is that the security requirement is the issue and not the OS. Simple security requirements can be met simply. Complex security requirements are complex. The devices and the USB protocol are the same under any OS.

There are probably some kinds of things that are easier to do under one OS versus another. But it’s probably not fundamental to your problem.

Taking a SWAG, I would say that you have bad requirements. And what you need to do is recapitulate them in technically sound terms instead - easier said than done I know. A requirement change that I advocated for in 2009 was just recently approved. And that was a simple missing negation in a financial regulation calculation. And they didn’t even have to get the law amended - just a better interpretation of this obscure case. Of course it helped that now is the only time in the last 20+ years that the case applies and they were facing financial loss because of the wrong arithmetic :wink:

1 Like

Again, filtering and hijacking USB devices is not a rocket science. VMWare does it, VirtualBox does it. The latter is opensource.
@rusakov2 Please see links in my previous comment in this thread.
The genuine problem is that forging USB devices is easier these days than writing a Windows filter driver :wink:
So go ask your “security” expert what if device allowed by user’s policy is a fake.
Just as example, knowing that USB smartcard reader with certain PID&VID is allowed I can make a multifunction device with these PID&VID and pack in it a camera and what not.
– pa

We had a similar issue in the past where customer required “only these select special USB devices” to be allowed,
and not anything else. In any USB port in system, in any order.

And that is why when someone higher up tells me that they were told should we design our instrument based on
WindRiver OS or Linux than such task would be simple I don’t know if that is true or just something told them by Linux camp.

Well, your problems are VERY specific to the Windows world. They don’t really make any sense in context of a system that allows you to build the kernel in any configuration that you wish, and to include only those components that you would like your custom kernel to support, in your custom build. As you may have guessed, your “dilemma” is simply a non-issue on such a system. The only question is the one of the software ecosystem that your clients want to be supported by your system/instrument, and there is a good chance that the target ecosystem is Windows-oriented

Anton Bassov

I happen to have a particular aversion to driver projects whose primary aim is to PREVENT the normal operation of my Windows system

Well, no one really forces you to install them on your system,right? Although this position is more than likely to be supported by virtually everyone in respect of their home systems, they may have rather different attitudes in respect of their corporate ones. After all, you would not really want your highly-sensitive data (for example, the source code of a proprietary project that you have spent quite a few man-years on), to be stolen and sold to the competitors by some rogue employee,would you. This is where all above mention driver projects come in handy…

Anton Bassov

Adjacent posts on the same day with contradictory opinions. On the one hand Windows administrators have absolute discretion as to what they install and so shouldn’t complain about people wanting to write software that implements ‘functionality’ that is undesirable. On the other hand the problem of choosing which OS to implement my super special security software in is a Windows only problem because on *NIX I get to decide exactly which software to install. Hmmmm…

The problem still seems to be a good definition of the super special security first, and then a platform specific design second.

Adjacent posts on the same day with contradictory opinions. On the one hand Windows administrators have absolute discretion
as to what they install and so shouldn’t complain about people wanting to write software that implements ‘functionality’
that is undesirable. On the other hand the problem of choosing which OS to implement my super special security software
in is a Windows only problem because on *NIX I get to decide exactly which software to install. Hmmmm…

Well, if you see the world only in black and white, you may potentially find some contradictions in a single post as well (i.e.the same functionality may be undesirable on the personal system but more than welcome on the corporate one)…

The point that you seem to be missing is that you simply don’t need to install ANY “super special security software” that is meant to disable the certain OS functionality( probably, at the expense of screwing up the normal system operations) on the system that allows you to build the kernel in any configuration that you wish. All you have to do us to build kernel without enabling the support for the functionality of your interest (as you may know, the build target is configurable), and that’s about it.

However, in order to achieve the same goal on the Windows system, you need some “super special security software”. The functionality that this software implements may have some undesirable “side effects”, and may come at the expense of screwing up the normal system operations. However, as long as no one forces you to install it on your system, you’ve got absolutely nothing to complain about. Simple, ugh…

Anton Bassov

say that one creates a custom version of *nix that ‘blocks’ certain ‘unwanted’ devices in accordance with some complex algorithm. And then this version gets ‘installed’ on your target host; have you installed super special security software?

contrast this with a stock version of Windows installed on a host. on top of which you install a filter driver that ‘blocks’ certain ‘unwanted’ devices in accordance with some complex algorithm; have you installed a super special security software?

familiarity with a particular OS aside, how do you make the choice?

this will be my last post on this thread

say that one creates a custom version of *nix that ‘blocks’ certain ‘unwanted’ devices in accordance with some complex algorithm

Well, one does not really need to create a “custom version of *nix”, let alone to implement any “complex algorithms” in order to reach the objective that we are speaking about. The only thing that you need here is just to build the kernel in configuration that suits your needs, which, despite its “terrifying” description, in actuality, implies nothing more complex than simply modifying the configuration file. In case if you are sill “terrified” , I can assure you that it involves nothing more than simply changing the Y to N settings for the modules of your interest, which can be done with menuconfig utility and friends.

have you installed super special security software?

Taking into consideration the fact that the task in question does not require writing a SINGLE line of code even in a scripting language, let alone in C, the very term “creating software” does not really seem to apply here, does it…

contrast this with a stock version of Windows installed on a host. on top of which you install a filter driver that ‘blocks’
certain ‘unwanted’ devices in accordance with some complex algorithm;

The contrast seems to be, indeed, so stark that is just sort of astounding…

have you installed super special security software?

Well, if you still doubt it…

Anton Bassov