On Windows, is there any way to programatically approve a USB device after insertion, if it is of a certain type (say Removable Drive) allow its use, otherwise not? Also not to allow running of drivers, only allow usage of the device in an approved way?
I.E. We want to allow the insertion of USB drives, but not have to worry about virus's being installed.
EDIT Sorry, I wasn't very clear on the posting of this question. Yes this is Windows, but I am not worried about auto-run programs, that is of course turned off. Users will not be able to access any executables, just data will be read off of the drive. They will not have access to any UI other than what we allow (it's a Kiosk). What I am concerned about is device drivers running and installing software (ala U3, and other USB software that installs itself when you insert a USB drive). There are a bunch of virus's in the wild that can be run just by inserting a USB drive into a system. We have restricted things with group-policy to the level that we can, but I can't find a way to not allow the installation of drivers without creating a base whitelist of USB drives that come pre-installed and nothing else would work (ie. Do not allow installation of drivers).
(Since you're worried about viruses I'll assume that we're talking about Windows.)
There is no point in restricting the user like that. Make sure the user does not have Administrator privileges. And install an up-to-date virus scanner.
Rationale: If you're not going to permit even reading files, then allowing a USB drive would be useless anyway. So you are going to permit reading files from a USB drive. But then someone could already install a virus by copying it to the local hard drive and run it from there.
If it's your own kiosk application, make sure your kiosk has drive letters A-Z assigned. To access the USB drive, you'll need a path of the form \??\Volume{GUID}\Filename. But by keeping it out of the normal file system, you're safe against most attacks.
You're never entirely safe. As Raymond Chen would point out, it doesn't help a lot if you disapprove forks. The (physical) damage is already done.
Also, on Windows, disable Autoplay/Autorun on the USB drives.
With Group Policy:
http://www.howtogeek.com/howto/windows/disable-autoplay-of-audio-cds-and-usb-drives/
There are also options in the TweakUI utility:
http://www.microsoft.com/windowsxp/Downloads/powertoys/Xppowertoys.mspx
No. You can restrict access to removable media using GPO, but you can't specify what kind of files are allowed on the removable media or if they can execute or not.
EDIT: upvoting thomas. better answer than mine.
Related
Summary
I'm developing firmware and a PC test application for a custom USB device, using the STM32F072 Discovery board. The device includes Microsoft Windows Compatible IDs (WCIDs) to enable automatic installation of the WinUSB driver on the PC.
The device is enumerated correctly on other Windows 10 hosts, but not on my Windows 10 development PC. My development PC had previously tried to enumerate the device when it had the same VID/PID combo, but with different descriptors/metadata. If I change the PID to some other number (new to my development PC), it does enumerate correctly.
Questions
How can I get this to work with my desired VID/PID combo on my development PC?
Is Windows caching USB metadata the cause of the failed enumeration on this one PC?
What are best practices on the (Windows) PC-side for testing/development of USB device firmware, during the stage when device descriptors and metadata are in flux? Is it possible to avoid chewing up PIDs just to avoid the Windows caching?
Details
Because of the way Windows caches USB descriptors and the like from previous enumerations, during firmware development, I was incrementing the device Product ID (PID) in the firmware after each time I made other changes, to ensure that Windows wasn't caching things from previous iterations of the descriptors, and messing up stuff that would otherwise work.
Now I've gotten the device to enumerate successfully on Windows 7, 8, and 10 PCs as a WinUSB device, and I've established communication. But when I change the firmware back to using the VID/PID that I started with, and then connect the device to my development PC, it shows up in Device Manager under "Other devices" with an error icon. I think this is because my (Windows 10) development PC previously had seen this VID/PID combo as having different descriptors, so it's getting confused by some bad cached stuff.
I've tried using regedit to delete the device's registry keys under HKLM\SYSTEM\CurrentControlSet\Enum\USB\VID_xxxx&PID_yyyy, but the problem persists. (Also, I get an error, because it can't delete the VID_xxxx&PID_yyyy\zzzzzzzzzzzzz\Properties subfolders.) I also tried using USBDeview to uninstall old iterations of the device, but that hasn't made a difference either.
Also of note is that I can no longer pass the device through to Virtual Box virtual machines. I'm not sure what happened there.
Try removing any relevant registry keys of the form:
HLKM\SYSTEM\CurrentControlSet\Control\UsbFlags\vvvvpppprrrrr
The MSDN article Microsoft OS Descriptors for USB Devices says:
The operating system creates a registry entry, named osvc, under this registry key that indicates whether the device supports Microsoft OS Descriptors. If the device does not provide a valid response the first time that the operating system queries it for a Microsoft OS String Descriptor, the operating system will make no further requests for that descriptor.
I know the OP has resolved his issues, but for future reference for anyone else having this problem: I had similar issues while developing a USB device with a vendor-specific class. Specifically, (similar to your experience) I was unable to delete the keys from:
HKLM\SYSTEM\CurrentControlSet\Enum\USB\VID_xxxx&PID_yyyy,
so I had to increment the PID every time I modified my device code.
The reason why these keys can't be deleted is that the Properties registry subfolder is owned by the System user, so even running as Administrator you can't delete this subfolder nor change its permissions.
Running Regedit via PsExec (which is part of the SysInternals suite from Mark Russinovich) from an elevated command prompt with: psexec -s -i regedit.exe runs regedit as System user, which means you can delete that pesky Properties subfolder and the parent VID_xxxx&PID_yyyy keys.
I'm confronted with the same issue and uninstalling the device did not help.
Messing around with the registry makes me feel uneasy.
I still don't see a real answer to question #3.
What worked in my case: open device manager, select the non-working device and do "update driver". Select the driver manually from the list of locally available (Microsoft) drivers.
This did not solve all my problems but at least Windows does not ignore my device anymore and I can continue developing.
EDIT: I found a very helpful description on a github project named WCID Devices by Pete Batard. I strongly recommend reading the section Implementation and the following on this page WCID Devices
there are tools for removing hidden traces of USB devices like USBOblivion http://www.thewindowsclub.com/usboblivion-remove-usb-traces-windows , USBDeview,...
sources of USBOblivion are here: https://sourceforge.net/projects/usboblivion/ (https://www.openhub.net/p/usboblivion)
http://www.techerator.com/2010/05/how-to-remove-hidden-duplicate-copies-of-usb-device-drivers-in-windows/
To Remove TrustedInstaller Owned Registry Keys
Unfortunately the old PsExec trick of running RegEdit doesn't always work. In that case try to use:
ExecTI - Run as TrustedInstaller
Run it to open the ExecTI GUI and enter: C:\Windows\regedit.exe
To repair file and registry permissions
You can also try using the very old tool: subinacl.exe
Example:
subinacl.exe /subkeyreg HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Enum\USB\VID_0000&PID_0002\
Further described here. And has been shown to still work on Win10.
I have a removable device setup so it autoruns when plugged into a Windows machine and pops up a message giving the owner's information, so it can be returned if lost. Is there a way to do this in Linux as well? It doesn't need to be complex, it can be an option in a right-click menu, or a splashscreen, or anything.
No. Unlike a default installation of Windows, which looks at Autorun.inf and automatically executes a specified program (or at least asks whether the user wants to run the "default action"), no distribution of Linux does this. Any autorun-like feature upon inserting a USB device on Linux must be explicitly set up by the user.
By the way, the autorun "feature" of Windows can be disabled, and it frequently is disabled by security-conscious computer users.
I haven't understood well what you're trying to do, anyway I strongly suggest to use one of the APIs provided by dbus (expecially the hal service).
Though this approach is not immediate.
http://dbus.freedesktop.org/doc/dbus-tutorial.html
I guess you could just put a file in the root directory called README_Owner_Identification.txt. That way people using certain desktop environments would see the filename when the file browser popped up in response to a USB device being automounted. If I recall correctly, both GNOME and KDE will do this by default.
Of course, people would still have to open the file to see the info, and it wouldn't work on systems that have the settings changed, but it's probably your best option. Anything else would require that people engage in some thoroughly insecure system reconfiguration just to see your ID.
I have content on a portable HDD that is to be shared between 2 or more computers, but none of the computers are connected to a domain (none exists). I want to give permissions to the content in such a way that the permissions remain the same across all my computers, irrespective of which computer I connect the HDD to and irrespective of which user account was used to set the permissions.
For example, I want the built-in Administrators group (SID: S-1-5-32-544) to have Full Control of a file on the portable HDD, irrespective of the computer it is connected to (I am aware this constitutes a big security hole, but so long as the drive doesn't get stolen, I am ok with it. Anyway, once an attacker has physical access to a drive, all bets are off.).
Problem I am trying to solve is this: I connect the HDD to computer1, set all permissions, disconnect. Then I connect the HDD to computer2, and suddenly the permissions aren't right for the user on this computer since the SIDs are different (both in terms of permissions and ownership of content).
If you want the Administrators group to have full control, just set it that way. In Windows XP Pro or some other system that gives you a Security tab in Properties, use it. In the drive's security properties, add Administrators (if it's not already there), and in the privileges for Administrators give full control and enable all inheritance. You just have to set that on one machine and then other NT-based Windows PCs will obey the settings.
If you can't find one Pro system to use for that setting, then you'll have to learn the cacls command line. Fortunately you still just have to do it once. Oops. You'll have to do it n times where the first (n-1) times are various mistakes, but you just have to get it right once.
The permission scheme you choose for your HDD depends on the filesystem you've formatted the drive with. Different filesystems specify permissions differently and have to be treated separately.
Why are you using permissions at all? If someone gets the drive then they have access. Instead, just use something like truecrypt to protect everything, and give everyone permissions to everything in the truecrypt volume.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
In linux, if I have a file I'm sharing with a group, and I put the file on a USB memory stick, for example, and copy it to a computer that doesn't have the same group or users, does the file have no permissions for anyone on that new computer? What if I bring a linux file that only lets user X to read it to a windows machine? Who gets to read it on the windows machine? since user X (and group) doesn't exist on that machine.
What kind of security do I get copying a linux file to another linux machine? how about to a windows machine?
What kind of security do I get copying a windows file to another windows machine? how about to a linux machine?
Please let me know.
jbu
Regarding the USB key: generally, USB keys use one of the FAT family of filesystems; FAT doesn't support security at all, so as soon as you copy the file to it the security information is lost. So for your first question, anyone who has the USB key can read it on any computer from any user account. It is possible to format USB keys using another filesystem (for example, NTFS, which does support security); in that case, if the accounts (in Windows, at least, it must be a domain account or similar, just naming two accounts the same will not do it) do not exist on the target computer, only a user who can ignore filesystem permissions (such as root on *nix or Administrator on Windows) will be able to access the file.
For the second, I'm not 100% sure but I believe it depends on how you copy it; things like FTP and rcp generally don't copy permissions over, so I would assume that the file gets some kind of default permissions for the target directory, or a default built into the copy program, depending on what the copy program does.
For windows, to the best of my knowledge the security descriptor is initially inherited from the target folder; permissions are, again, not persisted across machines. It can be modified after the copy.
In general, except in specific environments that are designed to transfer permissions, I would assume that transferring any file from one computer to another resets the security permissions to a default (generally whatever a new file in that location would receive).
as technophile said, removable drives usually use FAT filesystems, so no permission info is copied at all.
on more 'direct' copies between *nix machines, if the writing process is run under root, usually there are flags to preserve permission bits and owner/group. also, most of them preserve user/group identities by the numbers. if there's no 'global' user identity database (LDAP, NIS, or even AD), be sure to look for a 'by name' identity.
some examples:
NFS: assumes 'identity by number', unless you use some 'squash' option to make every file the same owner/group.
cp: the '-p' flag preserves mode, ownership (by number) and timestamp.
scp: the '-p' flag preserves modes, but (usually) not ownership
rsync: only root can preserve ownership (-o,-g, or -p), tries to match usernames, but falls back to userids if not possible.
Why bother with permissions?
They get in the way most of the time unless you are running some sort of server.
Perhaps copy from linux FS to a FAT32, exfat, or NTFS FS so you don't have to deal with permissions?
That is what I do. I usually choose NTFS for file 'sharing' between desktop and laptop where laptop has linux and desktop has windows 7. Cannot easily do *nix laptop to *nix desktop without doing chmod multiple times (and even THAT doesn't guarantee R/W permissions)
When I tried to share between *nix's, everything was quite bad.
I need FULL read/write access by everyone on any box from any external drive.
Only problem with ntfs is if your *nix doesn't write to it or shut it down correctly.
Then I have to use windows to fix it (pain too). Hence one of the reasons I keep windows around.
Every flash and external drive I have are all NTFS except 2 of them which are fat 32 to 100% GUARANTEE no foul ups with linux demanding permissions (which many times I cannot change for some reason even with chmod).
Of course my data is plain old movies music pictures, similar domestic items.
But the same theory holds that if you don't or can't write permissions with the file, anyone should be able to use the file from any operating system.
I have gone so far as to copy a stubborn file onto a fat 32 flash drive just to strip permissions then copy it back. HATE typing command line stuff.
For me I need 100% read, write access to ANY data I have on external drives for all computers.
About using root - most linux 'suppliers' strongly discourage the use of root for doing many things.
Again, easy way around permissions is if you can copy it you can strip it by sending it to fat32. Or ntfs. And there goes the security.
If something is so sensitive that you NEED file security when file sharing then why share it in the first place?
If you want to prevent tampering with a file then burn it to a cd/dvd. That is read only. Even if they copy it and tamper with it the original is still untouched.
The leaving your wireless network open question reminded me of this.
I typically share the root drive on my machines across my network, and tie login authorization to the machines NT ID, so there is at least some form of protection.
My question, how easy is it to gain access to these drives for ill good? Is the authorization enough, or should I lock things down more?
If this is a home network with no wifi or secured wifi, it's probably not an issue. Your isp will almost certainly prevent anyone from trying anything via the larger web.
If you have open wifi, then there's a little more cause for concern. If it's properly secured so that some authentication is required, you're probably okay. I mean, a determined hacker could probably break in, but you're not likely to find a determined hacker in wi-fi range. But the risk (if small) is there. You will want to make sure the administrative shares (the \\yourmachine\c$ or \\yourmachine\admin$ mentioned earlier) are disabled if you have open wifi. No sense making it too easy.
I can't answer the main question, but do keep in mind that Windows, by default, is always sharing the roots of your drives. Try:
\\yourmachine\c$
(And then try not to freak out.)
Windows generally protects shares via two methods - permissions on the share itself, and then NTFS file permissions. Good practice would be to have the share permissions as "Authenticated User" and remove the "Everyone" group.
Personally I would make sure that usernames and passwords match up on each computer, and control permissions like that, rather than using computer name.