Novicane All American 15414 Posts user info edit post |
Problem: Our engineering team is looking to just lock down an EXE in Windows XP.
We have a special calibrated windows XP machine that runs a pretty intense operation. The program is calibrated and setup perfectly until unauthorized employees who do not have the latest training run this program and change settings.
This machine has a shared network login and that login has admin rights on the machine. Engineering wants to require a password to run the program. They would like to allow multiple password with unique user names to run the program - to avoid people just saying "hey the password this week is ABC" - some sort of access list with time stamps would be ideal for the EXE if anything.
I told them pretty much this isn't an IT problem and they should fire their employees but alas this is the real world and that won't happen...my solution was maybe some type of usb fingerprint scanner tied to an EXE launch script...
[Edited on June 4, 2013 at 7:39 PM. Reason : ss] 6/4/2013 7:39:19 PM |
Shaggy All American 17820 Posts user info edit post |
remove the shared login. remove execute permissions on the .exe for everyone except for an ad group that contains the domain users who should have permission to run it. 6/4/2013 7:54:24 PM |
BIGcementpon Status Name 11318 Posts user info edit post |
^That sounds about right to me. 6/4/2013 9:25:46 PM |
smoothcrim Universal Magnetic! 18964 Posts user info edit post |
put a vm on the machine with local credentials (assuming no domain) give the credentials to the people that need them. run the app inside the vm 6/4/2013 9:35:58 PM |
richthofen All American 15758 Posts user info edit post |
Both above solutions would work well. In a nutshell, you're going to have a much easier time controlling this by login than by trying to actually secure the .exe in a shared-login environment. It's possible but it'd be a pain in the ass. 6/5/2013 12:01:38 AM |
Perlith All American 7620 Posts user info edit post |
That shared login with admin rights is going to be the biggest problem. People WILL figure out whatever scheme you come up with and with admin rights figure out how to circumvent it. Shaggy's solution works nicely if you can get rid of the shared login.
If you can't get rid of the shared login, put the program on a shared network drive that requires different credentials to mount. Instruct the "real" users to always mount the drive as the same drive letter, run the program, and unmount when they are done. 6/5/2013 7:39:20 PM |
Novicane All American 15414 Posts user info edit post |
the shared login will have to stay as admin rights are done in the enterprise by an exception form that auto adds the login as the admin once approved. Admin rights are required to run this program and some system variables are modified.
The user base can easily be tricked. Something as simple as click this shortcut to run the program. They wouldn't search through the C:\ looking for it or right click and debug some VBS script i could write.
[Edited on June 5, 2013 at 8:33 PM. Reason : ss] 6/5/2013 8:30:55 PM |
FroshKiller All American 51908 Posts user info edit post |
I don't know, dude, it sounds like your engineering team doesn't know how to Windows. Shared logins are basically always a bad idea. 6/6/2013 8:50:50 AM |
Novicane All American 15414 Posts user info edit post |
Im going to write something in visual basic. 6/6/2013 9:20:08 AM |
lewisje All American 9196 Posts user info edit post |
a gui interface plz 6/7/2013 11:01:06 PM |
aaronburro Sup, B 52977 Posts user info edit post |
If you have to have the shared logins, which is something you should never do, then just tell all the users that the next person who fucks up the settings will be fired, and then fire the next moron who fucks up the settings. No one will touch it after that. Problem solved. 6/9/2013 5:25:08 PM |
lewisje All American 9196 Posts user info edit post |
better have them digital forensics tools so you can match up the time the settings were changed with the times your employees were at the computer 6/9/2013 6:35:55 PM |
AntecK7 All American 7755 Posts user info edit post |
Are the settings in a different config file? You could put a script to restore the settings on log in
Ice startup script that copies settings.INI from a network location to overwrite the potentially modified file
[Edited on June 13, 2013 at 9:43 PM. Reason : dd]
You could also use deny rights for the shared account in NTFS...as long as they don't take ownership
Ice allow read and execute and list deny modify
[Edited on June 13, 2013 at 9:46 PM. Reason : dd] 6/13/2013 9:41:42 PM |
Stimwalt All American 15292 Posts user info edit post |
Why not just encrypt the config file of the executable, so it cannot be changed even via the GUI?
[Edited on June 14, 2013 at 10:33 AM. Reason : -] 6/14/2013 10:31:11 AM |
smoothcrim Universal Magnetic! 18964 Posts user info edit post |
how would the application be able to read the encrypted file? if the application could, what's preventing the users?
[Edited on June 14, 2013 at 11:03 AM. Reason : encryption also has nothing to do with permissions] 6/14/2013 11:03:22 AM |
richthofen All American 15758 Posts user info edit post |
I like AntecK7's idea to restore the settings on login, unless the settings are dynamically changed by the operation as it runs.
If the user base is as easily tricked as you imply, you could hide the shortcut somewhere and only give the locataion to authorized users. That is assuming they wouldn't give the location away, navigate to it, or leave the folder open in the presence of an unauthorized user. It's not at all secure and it's not particularly elegant but it's near-zero effort to try. 6/14/2013 11:14:58 AM |