I am trying to run a .Net 2.0 application from a network share without using the FullTrust permission set. I want to create a new permission set that has just the permissions my assemblies require, and then assign that to the exe on the shared path. Is it possible to do this?
From my limited experiments, I find that I am unable to do get any application working from a network share without FullTrust. I tried creating a new perm set, and also tried the Everything and other perm sets, but none seem to work. Has anyone had any experience with this?
You need to sign your assemblies with a strong name and then set the cas-policy for your strong-name to full trust.
The easiest way for setting up FullTrust to all code signed with your strong-name is:
caspol.exe -q -m -ag MyZone -strong -hex [HexCodeOfYourStrongName] -noname -noversion FullTrust -name MyCode -description "Code trust for my code"';
If your code is split up to multiple assemblies you need every assembly to be signed with that strong name. You may need to set the SecurityPermission-Attribute with a link demand, that the security of the caller taken over.
[SecurityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.ControlPrincipal)]
Prior to .NET 3.5, you need to fully trust the share to run a .NET application from there. Shawn explains this here with: "without some modification to the default CAS system, we're in a never ending cycle between loading assemblies that contain security objects and granting them policy. ... enter the FullTrust list."
In .NET 3.5 this limitation is overcome by "... granting set of FullTrust by default, making them act the same as if they were launched off of your computer directly" (from Shawn's another post here)
Giving the strong named assmebly FullTrust permission sounds good, but unfortunately my assembly references several third-party COM Dlls which are also required to be strong-named if I strong-name the main assembly. I'm guessing then that giving FullTrust to the path as given by Shawn is the best solution:
CasPol.exe -pp off -m -ag 1.2 -url file://\ShawnFa-Srv/Tools/* FullTrust
Related
I've been having issues with people modifying powershell scripts and causing mayhem. Is there a one liner that I can insert into a current script to require a password that I set in order to modify the script? I still need everyone to be able to run it.
The easiest and most straightforward way is to put the scripts somewhere that the problem users don't have write access to. There's nothing you can do in the language itself to prevent a user from modifying a file they have write access to.
If you can't do this for some reason (they are admins and have too much access), then you can do a few other things.
Signing
Apply a digital signature to your scripts.
For this to work, you need to be able to enforce an execution policy of AllSigned (or RemoteSigned if these scripts are executed directly off of a share). You might do this with Group Policy.
You also need to control access to the signing certificate and ensure that it's the only one that's trusted.
Note that these users can still copy the script locally, make modifications, run powershell.exe -ExecutionPolicy Bypass and still run their modified script.
The difference is that this is their copy and doesn't break it for anyone else. And if they overwrite the central script without signing it or signing it with an untrusted certificate then everyone will notice.
If the users are privileged enough they be able to override more of this.
Central Deployment
Put the scripts in a custom local repository and use the package management functions Find-Script / Install-Script so everyone is referring to the same ones, and have a well-thought out deployment process. This can be combined with signing.
But...
Ultimately if these users are privileged and they are acting in bad faith, this is a personnel problem and can't effectively be solved with technology. In that case, The Workplace may be able to help.
I am encountering several situations where, in a Chef recipe with powershell_scipt, a command appears to fail, whereas if I run the same command in powershell outside of Chef, the same command works.
The two in particular are "regedit", which I am trying to use to set a key for app compatibility and the other is "net use z:...." to created a mapped drive. Both of these seem to work fine if I run them in powershell, but if I use them inside a recipe inside powershell_script, they don't appear to do anything.
So I'm wondering is this because Chef runs commands that are inside powershell_script at some lower privilege level?
Also if so, how do I change it so that the regedit and net use would work?
Thanks,
Jim
EDIT 1: This seems to work for adding the registry entry I needed:
registry_key "HKEY_CURRENT_USER\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags" do
values [{
:name => "{2b9034f3-b661-4d36-a5ef-60ab5a711ace}",
:type => :dword,
:data => 00000004
}]
action :create
end
That prevents the compatability popup that I am getting when we run the Sharepoint installer.
EDIT 2: I hope that this is ok, but for the record and more visibility and hope that I remember this, I found this re. mapping drives in Windows and Chef:
Mount windows shares on a windows node with Chef
and:
https://tickets.opscode.com/browse/CHEF-1267
I haven't tried that yet, but that seems like the answer to my drive mapping need.... hopefully..
The chef client service runs as Local System (SYSTEM) by default.
In Windows, that user has full privileges on the local system, like root basically, but on the network it authenticates as the computer object.
So it you are trying to use regedit to change something in for example HKEY_CURRENT_USER then you need to remember that the code will not see the same "current user" as you will when you run it in interactively. Also, regedit is an .exe; you should really do what you need through the PowerShell providers or .Net objects.
For net use you are trying to map a drive. It's likely that the computer account doesn't have the rights to the share that your user has. Again, net.exe is a separate executable. net use maps a drive to a drive letter (usually) and you shouldn't be doing that in a configuration script, in my opinion. You should access the UNC path directly, but either way I still think that you're probably running into a permissions issue here.
You could change the credentials of the service to use a user account that has all the rights you want, but before doing something like that you should consider changing your workflow to not need that.
I'm considering using shims to get around a game demanding Admin privileges (I tried editing the embedded "requestedExecutionLevel" tag with Resource Hacker and using .manifest files, but discovered the launcher software always downloads a new version of itself before running, thereby overwriting "asInvoker" with "requireAdministrator"). If I write protect the exe it exits with an error.
I understand that the shim required to spoof Admin privileges will probably add no appreciable overhead in itself; but MicroSoft's Application Compatibility Toolkit (ACT) that you need to install to enable shims uses a database to keep track of which application requires which shim. I'm sure this could be done with little overhead; but having seen MS' (and other corporates') past bloatware, I'm concerned my entire system will be slowed down if I install it.
Does anyone have DIRECT experience of installing ACT and KNOWS whether it slows the system down generally?
I've discovered you can add RUNASINVOKER as the value of a STRING key given the name of the application's full path here:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
and it will do the job without you having to install Microsoft's ACT package.
Example: if you had an application called Smeagol.exe in the directory c:\LordOfTheRings, then create a STRING key called:
c:\LordOfTheRings\Smeagol.exe
in
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
and give it the value of
^ RUNASINVOKER
and it will run without requesting Admin privileges.
I'm trying to create a directory with a perl script after calling it via Ajax through a web interface. I'm using IIS7.5 to run my webserver.
The problem arises when I use either mkdir($path) or system("mkdir", $path), with the errors being "Permission denied" or "Access is denied", respectively. I believe I've set up the permissions correctly to give read/write/execute permissions as well as special permissions to create files and folders to the script.
Please let me know also if this should should be posted elsewhere, thanks!
I would think you could find the user running the script with "whoami".
Also, I'm not clear on what context the script is running in, nor where is the directory it is trying to create. It might be necessary to add the "-p" option so that necessary parent directories are created.
No comment on the safety of this ... I assume that those checks are being made elsewhere.
Please keep in mind that , the folder that you are planning to create this new folder in , must be owned by apache ( or any other web server software, you might be using ).
sudo chown apache *rootfolderfornewfolder*
I hope this helps
As I've explained in my other question, I'm busy setting up a PowerShell module repository in my enterprise.
My plan is to have a master repository (r/w access to a limited group of people) and slave repositories (read only access to everyone). I need multiple repositories because clients are located in different security zones and I can't have a central location reachable by all clients.
For this reason, I need to configure the PowerShell profile of the clients so that they can point to the correct repository to find the modules. I would like to define a $PowerShellRepositoryPath environment variable for this purpose.
Also, the profile needs to be customized in order for it to execute a script located in the repository (thus where $PowerShellRepositoryPath points to) when PowerShell starts (my goal here is to automatically add the latest module versions to the PSModulePath of the clients on startup).
We have a mixed environment with domain members and stand-alone servers in different network zones.
How would you proceed? Is it possible to push that variable and the profile via a GPO for domain members? Would customizing the $Profile variable via GPO be an option?
What about the standalone servers?
Edit:
I think that for creating the environment variable, I'll just use a GPO to create it and use it in PowerShell via $env:variableName. For non-domain situations, I'll probably have to use a script though..
I am not sure about pushing $profile via GPO. But, I'd simply put a logon script that copies the profile script from a network location based on the user's group/security membership.
Well if you're going to change the path to the modules, I'd have a file in the repository (say current.txt) that has the name for the current module (or current file path, whichever you are changing) in it. Then have the $profile script read the content of that file, and set the variable based on the contents. This way you don't have to screw around with updating the profile scripts, just update the central repository current.txt file with the path (or partial path, the part that changes, or filename or whatever), and when it replicates to the client repositories, all powershell profiles get updated with the latest modules when the profile script is executed.
Out of curiosity, why not just overwrite the module files in the client repositories with the latest version? If you did it that way, all clients would always have the latest versions, and you wouldn't have to update the $profile scripts.
Alternately you could always write another script to replace the $profile script on all machines. I think the first route I suggested would be the cleanest way of doing what you are after.
As far as the GPO thing goes, I don't believe you can do this. There is no GPO defined to control what is in the profile script. I would say you could maybe do it with a custom ADM file, but the profile script path is not controlled by the registry, so no go there.