1

I'm trying to run an executable (.exe) from LAN without allowing users access to the contents of the LAN folder itself. e.g.

1) User clicks on a link in their email to an executable at a folder path e.g. I:\Folder A\setup.exe

2) On clicking the link, the installer runs

3) If user tries to access the folder i.e. I:\Folder A\, they are disallowed from seeing the contents of the folder by either a prompt or by not showing anything there.

Does anyone know how this could be done. Essentially, I just want to make sure users have execute only permissions for setup.exe. This is for NTFS permissions.

Improve this question
2

If you really want to do this, do the following (assuming that "Authenticated Users" should have rights to execute the SETUP.EXE):

  • Verify that the folder doesn't name "Authenticated Users" as having any permissions. If it does, remove them (either by removing permission directly set at that folder, or by breaking the inheritance hierarchy and then removing the permissions assigned).

  • On the SETUP.EXE file itself, set "Authenticated Users - Read and Execute" permission.

Users will able to execute the file if they know the path of the file, but they will not be able to access the folder.

I predict that your SETUP program will need access to other files in that folder, though, and won't work because the user executing SETUP won't have access to the other files. (Any why are users allowed to install software on their computers, anyway? Are they using their computers day-to-day with 'Administrator' accounts... shame...)

Improve this answer
0

I do not think it is possible. If you have to go in folder then execute permission is enough. But to read files read permission is required. In order to run setup.exe, the person must be able to read setup.exe (executable code) which requires read permission on folder.

Improve this answer
  • thanks. can you advice what's the best way to protect the exe then. i'm using autoit to compile the exe which is automatically encrypted by it on compilation. Since I can't verify to the users what the encryption methodology is (autoit does not document it), they recommend that i disable users from doing any operations to the exe other than to execute it. – Farooq Jul 16 '09 at 6:37
0

Another possibility would be to serve it from a hidden share, such as an administrative share. These are denoted by the $ sign after the share name, and don't appear on the LAN by default. In other words, you have to know it's there to use it. Kinda security by obscurity, but it might serve your purpose.

Improve this answer
  • It isn't "kinda security by obscurity"-- it is security (or lack thereof) by obscurity. "Hidden share" names, per the method you describe, still get sent over the wire when a client enumerates the shares on a server. It's pretty trivial to look at the packets on the wire (or use a client like the Linux SMBCLIENT that doesn't "honor" the "$") to see what all the shares are. – Evan Anderson Jul 16 '09 at 12:24
  • ok, i've managed to test this out. just one question: when i pass a link to the exe, it would be like: <a href = "LAN:\FolderA$\setup.exe">Installer</a> They could simply just see where the link points to to get back LAN:\FolderA$ That's the only issue I see with this way. Any comments. – Farooq Jul 17 '09 at 4:35
  • Yes they would see the location. The only other thing I can think of is to get creative with a runas batch script. – churnd Jul 17 '09 at 11:24
0

You need to go into the Advanced permissions on setup.exe. Remove all rights for the users/groups (removing inherited perms if necessary), then go into the advanced permissions and add the users/groups with just the permission "Travers folder / execute file".

This allows the users to execute setup.exe, but they could not open it in a e.g. a hex editor and view it's contents.

JR

I had another look at this following Evan's commnents. It turns out that I'm correct (of course :-) but that Evan is also correct; sort of.

Here are the details. I created a folder C:\test and left the ACLs at the defaults. The ACL on the folder doesn't seem to matter. Into this folder I copied a few Windows applets like Paint and Notepad. I also copied a ultrasimple Windows app that I wrote myself. The source for the ultrasimple app is:

#include <windows.h>

int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
  MessageBox(NULL, "Hello world\n", "Hello world\n", 0);

  return 0;
}

which I'm sure you'll agree is pretty simple. Now I edited the permissions on all the files. I disabled inheritance, removed all the permissions and set the ACLs to contain just the one entry granting Everyone the permission "Traverse folder / Execute file".

Now if I drag any of the files into Notepad I immediately get an access denied error. If I try to copy any of the files into another folder I get an access denied error. This shows that read access to the files has been denied.

Now I double click my simple app, and it launches. Just for completeness I copied in another rather bigger app I'm working on, and after setting the permissions this too worked. This is the point I got to when I first posted, and it's why I was confident my answer was correct.

But, when I try to run mspaint.exe or notepad.exe they do not run. Instead I get an access denied error. This is the point where I'm grudgingly inclined to admit Evan may have a point :-)

My interpretation of this is that both Notepad and MSPaint have resources that Windows tries to load when they are started. This requires read access to the file, in order to read the resource, and because read access has been denied the attempt to launch the file fails. Because my app has no resources Windows manages to launch it quite happily. I imagine this would apply to any but the most simple of Windows apps, so although my original posting was technically correct, in practice just setting execute permission will not allow you to run anything useful. You will need read access as well.

Improve this answer
  • i'm looking at a solution along the same lines but when i try "traverse folder / execute file", i get an Access is denied error messagebox. – Farooq Jul 16 '09 at 7:44
  • 1
    Hmmm, i tried it on my PC before posting, so I can confirm it does work. Is it possible the setup.exe is opening some other file, or possibly opening itself for read access. In fact if it's an encrypted exe it probably is opening itself for read access so it can decrypt itself. In that case you will have to allow read access for it to work. – John Rennie Jul 16 '09 at 8:26
  • did you try this on an exe? setup.exe is essentially installing a bunch of dlls on the machine and registering them. it's been compiled using innosetup so yes, the exe should be encrypted. are you suggesting that in that case, execute and read have to happen together? – Farooq Jul 16 '09 at 9:31
  • @John: Execute permission in NTFS implies reading. If you can't read the file you can't execute it-- how else are the bits going to get to your PC's memory to be executed other than by reading? (Novell Netware had this brain-damaged concept of "execute only", but, again, in order for the bits to be in the PC's memory they had to be read. Their idiotic client software attempted to enforce "execute only", but it was fairly trivial to break into a debugger after the client made the calls to read the file and write the file out of memory back to the disk on the local PC.) – Evan Anderson Jul 16 '09 at 12:16
  • @John: Make a folder w/ Administators / Full Control permission and Users / Traverse Folder permission and no other permissions. Put an EXE into it as an "Administrator". Logon as an unprivileged user and attempt to access that folder. You're going to find that you can't execute the EXE you put there (or even see it in directory listings). – Evan Anderson Jul 16 '09 at 12:19
0

Maybe I'm crazy, but couldn't you just remove the "List Folder Contents" right for that folder from their accounts?

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy