Source
The designers of Windows Vista's User Account Control expressly decided not to incorporate functionality like
setuid/suid or
sudo found in Unix and Unix-like OSes such as Mac OS X. I think they made the right decision.
Large parts of the Windows ecosystem have a long legacy of assuming
that the end user has administrative permissions, and consequently a lot
of programs work correctly only when run that way. (I'm not going to
delve into that history here, nor will I entertain any finger-pointing
on the topic at this time. One of these days I'll post my thoughts on
that subject.) As computer security has become increasingly important,
breaking that cycle became absolutely imperative. It is with the release
of Windows Vista that the first major move in that direction is
achieved. Indeed, the primary purpose of the technologies that comprise
UAC is to make the "standard user" the default for Windows, encouraging
software developers to create applications that do not require admin.
It's not perfect by any means, but changing the ecosystem will take a
long time, and UAC is a good first step.
Pre-approving code to run with elevated permissions without going
through an elevation prompt, as described in the bulleted scenarios
above, seems at first glance to be both useful and convenient. However,
the negatives far outweigh those benefits. In particular:
- The "standard user by default" vision would become impossible and ultimately never happen;
- Elevation of privilege (EoP) would be trivial – any compromise could lead to full system compromise.
If it were possible to mark an application to run with
silently-elevated privileges, what would become of all those apps out
there with
LUA bugs?
Answer: they'd all be marked to silently elevate. How would future
software for Windows be written? Answer: To silently elevate. Nobody
would actually fix their apps, and end-user applications will continue
to require and run with full administrative permissions unnecessarily.
What if the application could not mark itself for silent elevation
but instead had to be marked by the consumer or enterprise administrator
installing the application? Answer: the developer of the installation
program (which necessarily runs with admin/system permissions in order
to install machine-wide) would figure out where the setting lived, and
set it. (Several major ISVs told us directly that they would in fact do
exactly that.) There would be no real way to protect that setting from
anything running as admin. This would be especially true if it were
settable via Group Policy (which would be expected, if not demanded).
"Well, so what? We're only talking about applications I approved!"
OK, let's say that's true, but how do you ensure that a malicious user
cannot use the application for purposes other than those for which it
was intended? And at least as important – how do you ensure that malware
that has infected the user's session cannot drive a setuid application
programmatically to take over the system? Ensuring strict behavioral
boundaries for complex software running with elevated privileges is (at
best) incredibly difficult. And ensuring that it is free of exploitable
design and implementation bugs is far beyond the capabilities of
software engineering today. The complexity and risk compounds when you
consider how many apps have extensibility points that load code that you
or your IT admin may not be aware of, or that can load code or consume
data from user-writable areas with minimal if any validation.
Privilege escalation due to setuid and sudo has plagued Unix-like
systems for many years, and continues to do so. In fact, several of the
bugs in the recent
Month of Apple Bugs fell into this category. Follow these links for lots more references: (*)
In the past, elevation of privilege has tended not to be noticed in
Windows – there is no real "elevation" if you're already running as
admin. (**) With the Vista shift toward "standard user", EoP threats
become much more important, and it is vital that Windows do as much as
practical to mitigate them. That is also why Windows services are no
longer able to interact with the user desktop. Taking on the setuid
headaches that *nix has had to live with does not seem like a profitable
deal.
We expect that in ordinary day-to-day usage, users should rarely, if
ever, see elevation prompts, since most should rarely, if ever, have to
perform administrative tasks – and never in a well-managed enterprise.
Elevation prompts are to be expected when setting up a new system or
installing new software. Beyond that, they should be infrequent enough
that they catch your attention when they occur, and not simply trigger a
reflexive approval response. This will increasingly be the case as more
software conforms to least-privilege norms, and as improvements in the
Windows user experience reduces prompting further.
Having said all that, there
is a Local Security Policy
option to change the behavior of the elevation prompt for Administrators
to "elevate without prompting". With this option selected,
anything
that requests elevation gets elevated without prompting the user. (The
default setting is "prompt for consent"; the third option is "prompt for
credentials". Note that "elevate without prompting" is available only
for members of the Administrators group. The options for standard users
are "prompt for credentials" and "automatically deny elevation
requests".) While "elevate without prompting" may be useful
in well-constrained, secure environments
for automated testing and possibly for initial system setup, having
this option selected otherwise is very risky and strongly discouraged.
(Note also that Vista's Home SKUs do not include the policy editor.)
Nitpicker's corner (***)
(*) Pointing out the obvious: local privilege escalation by
definition means that the bad actor is already on your system. However,
there's a
huge difference between malware running as you
(non-admin) and malware running with root privileges. If there weren't,
there would be no point (from a security point of view) in running with
least privilege.
(**) "Elevation of privilege" in this context means "
unauthorized
elevation of privilege". Technically, yes, Administrator is not as
powerful as System (in that there are operations that Administrator will
get Access Denied where System will succeed), and System is not as
powerful as kernel-mode code (in that there are operations that fail for
user-mode code running as System that succeed when called from kernel
code). However, two of the things that Administrator
is
authorized to do include: 1) configuring arbitrary code to run as
System, and running it; and 2) loading arbitrary code into the kernel,
and running it. Hence, if code is running as admin, there is nothing it
is not authorized to do.
(***) "Nitpicker's corner" might be a trademark of
The Old New Thing.
--------------------------------------
if wscript.arguments.named.exists("elevated") = false then
createobject("Shell.Application").ShellExecute "wscript.exe", """"
& wscript.scriptfullname & """ / elevated", "", "runas", 1
else
'what you want to do with elevated rights
end if
=================
Source
The VB Script below will raise a UAC challenge, then invoke your batch file, but it won't turn off UAC.
'---------------------------------------------
'Invoke a batch file under elevated privileges
'25.2.2011 FNL
'---------------------------------------------
bElevate = False
if WScript.Arguments.Count > 0 Then If WScript.Arguments(WScript.Arguments.Count-1) <> "|" then bElevate = True
if bElevate Or WScript.Arguments.Count = 0 Then ElevateUAC
Set oWshShell = CreateObject("WScript.Shell")
oWshShell.run "d:\temp\Ariel.bat"
'-----------------------------------------
'Run this script under elevated privileges
'-----------------------------------------
Sub ElevateUAC
sParms = " |"
If WScript.Arguments.Count > 0 Then
For i = WScript.Arguments.Count-1 To 0 Step -1
sParms = " " & WScript.Arguments(i) & sParms
Next
End If
Set oShell = CreateObject("Shell.Application")
oShell.ShellExecute "wscript.exe", WScript.ScriptFullName & sParms, , "runas", 1
WScript.Quit
End Sub
===============================
It seems that you want to run the copy action as an administrator using the script itself.
===============================================
You should be able to get around this by using the runas command:
runas /user:administrator /savecred c:\batchfile.bat
you can also use the run as to place the admin's username and
password in plain text, but that less desirable. In the above example,
the batchfile.bat would contain all of your copy and install commands
for the citrix client.
LibreOffice
Firefox
