User installing software

E

eric inazaki

Supposedly a user (not a power user but a plain user) can't
install software but apparently this isn't completely true
(I, as a user, was able to load Google Chrome among others).

Generally speaking, what kinds of software can be installed
by a user, how porous is this restriction mechanism?

Is there some kind of policy setting that can tighten up
this restriction?

Is there a way to audit software installs?

Thanks in advance,
eric
 
V

VanguardLH

eric said:
Supposedly a user (not a power user but a plain user) can't
install software but apparently this isn't completely true
(I, as a user, was able to load Google Chrome among others).

Generally speaking, what kinds of software can be installed
by a user, how porous is this restriction mechanism?

Is there some kind of policy setting that can tighten up
this restriction?

Is there a way to audit software installs?

Thanks in advance,
eric

The user only need to copy files into a folder in which they have been
granted execute permission. This is why, for example, Google Earth can
"install" under a limited account because its installer copies the files
under the %userprofile% path and runs from there because execute
permissions are granted on those folder, and also why some admins will
change the permissions for the %userprofile% (and all child objects
thereunder) to remove execute permissions.
 
E

Eric Inazaki

The user only need to copy files into a folder in which they have been
granted execute permission. This is why, for example, Google Earth can
"install" under a limited account because its installer copies the files
under the %userprofile% path and runs from there because execute
permissions are granted on those folder, and also why some admins will
change the permissions for the %userprofile% (and all child objects
thereunder) to remove execute permissions.

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
 
V

VanguardLH

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top