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.
Related
I'm currently working on a migration from svn to mercurial. My needs are plain and simple, I need source control over an intranet in our company. I see examples everywhere for setupping remote repos over IIS. I just don't see the point when I can just make a share on a server.
Can I still setup authorizations and authentications on repos using NTFS permissions?
Am I missing something?
Thank you
Putting a repository on a file share works, but it's not the way recommended by the Mercurial team.
See the "shared disk" part of Publishing Repositories on the HG wiki:
generally restricted to intranets, not generally recommended due to general issues with network filesystem reliability
Be sure to check out Chris Becke's answer as well, because he points out another valid disadvantage (people with write access deleting stuff from the network share, be it intentionally or not).
If you are aware of (and can live with) these things, putting the repositories on the network share is without a doubt the easiest way to setup.
My personal experience is that it works perfectly as long as the Windows share is on a "real" Windows machine.
At work we're using a share on a real Windows server without problems, but at home I ran into issues with a NAS (which behaves like a Windows share but actually runs on Linux).
You can read more about my experiences here:
Can you 'push' to network share using Mercurial on 64bit Windows 7?
There are a number of reasons to prefer, well, anything at all to a writable file share.
In essence it comes down to, there is a limited amount of damage someone can do with the ability to do a push via a web-method.
A read/write share on the other hand is necessary to do a push, but also allows a user to delete an entire repo, history and all.
Without even invoking malicious intent, people (or rogue software agents) have been know to navigate to random network shares and accidentally drag a file to someplace it doesn't belong.
The best reason to lock your PC is not because your co-workers find it amusing to use an unlocked email account to send porn to HR, but because its amazing what a cleaning lady can do with a rag and a keyboard. Its also amazing what Music Library applications can find while scanning all shares in a workgroup, and carefully "move" and catalog to someones Library.
I searched, so hopefully this isn't already a posted question already.
Basically, when we have users connect to the network via VPN, even though the login script will run and map their network drives, their home share drive (in this case P:) does not reflect the network version and shows the "offline" version.
The problem is they don't see all their files, and of course don't know how to trigger synchronization. Of course ideally we would just turn it off and there would be no problem, but as most of you know, working in a corporate environment we're bound by the decisions of the guys in another department.
So, is there a way to trigger folder synchronization? OR is there a way to force Windows when mapping the drive to look to the network version? I tried the true switch on the mapnetworkdrive method of the WSHnetwork but no joy.
Found a simple solution, you can call "mobsync.exe /logon", closing thread.
Details from microsoft, their pages move around so this is just a search.
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.
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.