How do Security Rights Get Stored in a .VSA File?
Filed under:
Software Virtualization Solution
Security
Submitted by tfronza on 27 January, 2007 - 07:48
Q:
Tony asks: How are security rights set on folders conveyed when the VSP is distributed? Do the rights maintain the same structure that was given to them when the layer was captured? If I give a domain group say Full Control to a folder in that layer, does that convey through to the clients after activation?
A:
If you crack open a .VSA file, you will see a file called "acl" in each sublayer. This is where SVS stores file system permissions. Registry permissions are in the "fslreg" files. So permissions for domain users and groups -- as well as all users/groups with well-known SID's like "Administrator" and "Guest" -- do get transported in the archive and are made effective on clients when the package is distributed.
(10 votes)
Quick question
This is great info. Quick question, how do you "crack open" the vsa? I go to "advanced layer properties" but don't see anything regarding acls.
Thanks!
How to crack
SVS archive files (.vsa) use standard zip compression. If you change the extension of the file to .zip you can open it in windows or any compression utility supporting the zip format.
Just to say that it works
Just to say that it works as explained in your post, interesting info and sometime could be help to understand how VSA include information in the layer.
regards
This might help
http://kb.altiris.com/article.asp?article=18292&p=3
ACL's in layers
Currently, I am assigning rights to the folders by going through the C:\fslrdr folder, tracking which directories belong to the app in question, digging into the directories and assigning rights there.
It would really be nice -- not to mention greatly speeding up development time -- if this functionality were built into the layer editor.
Just a suggestion,
Ron Traweek
Systems Administrator
The Cleveland Clinic Foundation
Security Descriptor Definition Language
The ACL file included in the layer uses the "Security Descriptor Definition Language" or SDDL. This can be hard to decipher if you look at the file with a text editor, e.g. "(A;OICI;0x1200a9;;;BU)". However, there is a tool located here
called SDDLTranslate that will convert them to readable form like this:
Type => ACCESS_ALLOWED
Trustee => ALTIRIS\Heath.Doerr
Flags => OBJECT_INHERIT
etc.
Assigning permissions
The more I read about this, the more I get really cross...
How many people use the Wise Package Studio setup capture to create SVS apps?
The methods described here all seem to point to the fact that most people use the SVS client tool to capture applications, where IT IS possible to set the rights on the redirection layers prior to exporting the SVS, however this is not possible (as far as I have been able to get down to)when capturing applications using the setup capture tool.
Capturing apps with the SVS client tool leave user specific SID information in the package, that cause clutter. Do I have to rename the file to zip, and edit it manually? Add custom actions to the events manually? This is unprofessional, especially if I consider the cost of WPS, and I should be able to do all this in the Workbench (ok. I can set wse CA's for events, but as soon as I need to add something to the META layer, I have to do this manually).
We have go onto setting rights on the redirection areas on the PostImport event, but even then, there are problems if files / directory's and registry keys exist on the base, as those rights take presidence over permissions set on the redirection area.
Don't get me wrong, I love SVS, I think it is a really great technology, but I feel that the tools available at the moment do not do justice to the possibility's that SVS provides as a solution.
Just my tuppence...
SVS capturing
Phil,
I feel responsible to give you some practice information on packaging.
Yes, in bigger environments Wise packaging studio should be the way to go.
BUT, I package a lot in SVS admin, because it can do lot's of good stuff also. But you have to do a lot manually.
The onpost and onpre events should be created manually. In packaging studio they are created automatically.
When capturing a application i alway's follow the steps below:
1: Package the application.
2: Export the vsa to a temp directory.
3: Start the applikation once to see if every thing is okay.
4: De-activate the package.
5: set permissions if necessary on c:\fslrdr
6: set permissions on HKEY_LOCAL_MACHINE\software\system\fsl
7: export the package
8: test and set in production.
Steps 5 and 6 ensure permissions and altered key's are inside the package.
Never rename the file to zip, and then alter because this is a good way to corrupt your pacakge.
If you need to alter files, import the applikation and doubleclick on it.
Then you can alter on the read write to test, and if okay you can change on the read layer.
Good packaging.
Regards
Erik
www.dvs4sbc.nl
Calmed down now...
Hi Erik,
thanks for your reply, and your advice on repackaging...
I go along a slightly different route, because we package both legacy -> msi / msi + mst and legacy/msi -> SVS.
Therefore I would like / and attempt to maximize my WPS environment and the automation that I have implemented, i.e. Global exclusion list (not possible with SVS client) and my svs template (not possible with SVS Client). I would like to have all the user specific SID info binned from the start (not possible with SVS) and also be able to capture files from other hardrives other than C: (system drive) only possible in SVS Client due to a bug in the Virtual Package Editor, more on that later.
Some Clients insist that the wvp file be delivered with the vsa, so using the SVS Client standalone is a no go.
We use the template because we can have our standard wse CA's in the template, so that there is no need to manually add them later. I am just bitterly disappointed that the WPS is not able to combine everything "under on hood".
As to "never rename the file to zip..." how do you include custom CA's / executables / files to the meta layer without doing this?
As for the bug with the Virtual Package Editor, try capturing an application that installs to C:, and also installs files to D: (be it a partition of the same physical drive, or a second physical drive) then when the package is imported and activated, then the D: drive is shown as C:\D\your d-drive folder...
As I mentioned earlier, we set permissions using a wse that creates an inf file on the fly (because of the magic number not being known until import) and setting the rights on the redirection area (c:fslrdr\%MN%\whatever + HKLM\SW\flsrdr\%MN%\whatever using SecEdit. The inf and log file are deleted by the CA, and a CA on the event OnPreDelete gets rid of the sdb.
We get our applications working, but the process is not optimal because of the "cable-guy" workarounds we are having to perform and I cannot maximize the automation that the WPS usually provides.
Anywayup, don't mind me, I'm just having a gripe ;-)
And thanks for your input, I really appreciate it, especially coming from an SVS guru...
Best regards
Phil
Calmed down
As to "never rename the file to zip..." how do you include custom CA's / executables / files to the meta layer without doing this?
And thanks for your input, I really appreciate it, especially coming from an SVS guru...
Best regards
Phil
In SVS you have a good way to get rid of the users SID.
You can create a template SID for your environment, and replace the user sid with that one. Just by de-activating the applikation, and then doubleclick on it, you can change everything you want. Just drag and drop files.
On the registry tab, do a right click and the magic appears. Import reg files.
I aspect a new version of WSP comingup soon, and that will incorporate all the good things of SVS.
Jordan is also placing some very cool stuff to to write your own programs.
Thanxs for calling me a Guru, but i´m just found a solution for so many problems my customers experience, and i love it. It is called SVS.
Regards
Erik
www.dvs4sbc.nl
I agree
@philBenson
I agree that SVSadmin and SVScmd (though I think SVScmd does most of what you probably would want to do with the command line) are lacking in certain areas--especually with onEvent. That's one of the reasons I'm doing my articles on the SDK because writting something that does onEvent is actually not that hard in .Net with my FSL2 class (I should be covering onEvent in a few weeks).