Eric said:
Sure, that makes sense. So there's nothing magical about preventing the
User from installing software, it's just a matter of having/not having
the right permissions?
Thanks,
eric
If MSI (MicroSoft Installer) is used then the account type is checked.
If the "installer" does nothing but copy files, well, the user can do
that, too. If the folder permits execute permission then .exe, .com,
and other executable filetypes can be loaded into memory and ran. If
you remove execute permission from the folder then nothing in it can
execute. Go do a file search under your %userprofile% to see if there
are .exe or .com files under there.
Google isn't the only offender of using the %userprofile% as a loophole
in security regarding executable files. MagicJack, when you run its
[auto]run setup utility will also copy files there that get executed.
You might bundle some files together, like for a work project, and store
them under some subfolder in %userprofile% for archival storage but any
..exe file you put there will run from there just like it will run from
ANY other folder where your account or the group it is in has execute
permissions under that folder.
http://technet.microsoft.com/en-us/library/bb727008.aspx
http://support.microsoft.com/kb/308419
You could remove the execute permissions of folder(s) and then field the
complaints from users that are used to running apps from there (who may
not even know their apps got "installed" there). Another way is to use
SRPs (Software Restriction Policies) that permit running only
whitelisted programs. You would have to compile a rather large list of
executable files for authorized programs (and executables used by the
OS). A blacklist is shorter but you only prevent loading of known bad
programs but you won't know what they are unless you are the admin of
the actual host in question. Since SRPs are policies, you can define
them locally or push them via GPOs onto a workstation. It would take a
lot of work to build a list of authorized executable files and some
testing to ensure blacklisting everything else didn't cause problems in
using the OS and those apps. To see SRPs on a host, use secpol.msc or
gpedit.msc.
http://www.google.com/search?q="software+restriction+policy"
SRPs are built into Windows. There are lots of HIPS (host intrusion
protection) security products that will demand a user grant permission
for an executable to load into memory and then execute and will even
check if that process attempts to load another executable file and then
prompts for permission for that. The ones that I've used are oriented
to the end user of the host granting that permission, like OnlineArmor
or Comodo Firewall, but I would suspect there are enterprise-grade
security products where whitelists could be pushed to workstations to
prevent users from running anything but software on the companies
whitelist.
