locked
Security in App-V 5.0 RRS feed

  • General discussion

  • An overview of what I think I now from App-V 5.0 security:

    1) It is not allowed to set NTFS permissions on the packageGUID's in the App-V client package store, right?

    2) The PackageStoreAccessControl feature is deprecated since App-V 5.0 SP2 HF5 - http://support.microsoft.com/kb/2963211/en-gb

    3) App-V 5.0 SP3 brings us a new feature so only administrators can (un)publish packages to themself - http://technet.microsoft.com/en-us/libr ... unpub_pkgs

    If you read Microsoft's KB from point number 2)
    To address App-V application entitlement concerns, you can use the following features that are available today in App-V 5.0 SP2:
    By default, the location in Windows where App-V stores applications, %ProgramData%, is a hidden folder that most users will not understand how to browse. You can use this hidden folder that has the "Pending Unpublish" feature in App-V 5.0 SP2 to reduce some entitlement concerns.
    To prevent your end-users from copying shortcuts and executables from the Program Data folder, consider the following:
    User-copied shortcuts cannot be used to start an App-V application if the user does not have permissions to the package.
    Copying executables from Program Data will not let users run the application outside an App-V environment, except for simple applications without any subsystems or integration.


    Q1) Locking down a desktop (with group policy or ...) so a user cannot browse in the C:\ProgramData\AppV folder is not really what I call highly secure.. I can imagine that a user could find a way into this folder through another application. How can one really be sure that a user cannot copy/start stuff out of the App-V client package store?

    Q2) Is it allowed to put NTFS security rights on the folders on the shared content store?
    Wednesday, December 17, 2014 2:31 PM

All replies

  • If a user goes into the ProgramData Dir and tries to run exes the app simply won't run, they won't see anything.
    You can open other files, like a txt file, or image file without it being published to you, you can't save though (even as an admin).

    Previous to SP3, a user could open up powershell, and do a publish-appvclientpackage * and get all the apps that weren't meant for them (that were already added to the client).  If you lock it down so only admins can do this a regular user won't be able to publish applications meant for another user.  A user has always required admin rights to add a package to the machine.

    As far as copying stuff, not to make light of it, but if a user copies the entire structure of a package from Programdata to a location that isn't locked down for write access, and then gets an application to work...

    We do lock down with NTFS security the server with all the packages, not sure if you mean that as package store or are referring to the ProgramData folder.  We add the user AD entitlement group to the folder security, so if you aren't a member of the GG, you can access the folder to read or traverse.  We are experimenting with SCS, but I don't see why that wouldn't work in SCS
    You may get the app or two that require rights for the computer account, but (from my experience, so far have only seen that in 1 app) that is rare.

    You can also look into using Applocker.

    Wednesday, December 17, 2014 3:08 PM
  • If a user goes into the ProgramData Dir and tries to run exes the app simply won't run, they won't see anything.

    If the app is a simple applications without any subsystems or integration it will work.

    We are working in a secured environment so I do have a problem with that.

    My main question: Isn't there a proper way to be really sure that a user can only access the c:\ProgramData\App-V\<PackageGUID>\<VersionGUID> of packages entitled to him/her?

    You can open other files, like a txt file, or image file without it being published to you, you can't save though (even as an admin).

    Not entirely true. An admin can change the permission and modify the file without problem.

    We do lock down with NTFS security the server with all the packages, not sure if you mean that as package store or are referring to the ProgramData folder.  We add the user AD entitlement group to the folder security, so if you aren't a member of the GG, you can access the folder to read or traverse.  We are experimenting with SCS, but I don't see why that wouldn't work in SCS

    The server with all the packages is also the shared content store as SCS is a client setting which enables the stream-to-memory. I guess that there is no problem with putting security on those folders, but did not find that back stated in the documentation.

    You may get the app or two that require rights for the computer account, but (from my experience, so far have only seen that in 1 app) that is rare.

    Not sure why an computer account would need to be added to the packagestore. Can you give an example why that would be needed?

    You can also look into using Applocker.

    Applocker is a system which prevents/allows users from launching certain files. It does not prevent browsing and copying out of the client package store.

    • Edited by .dBase Wednesday, December 17, 2014 4:07 PM deleted doubles
    Wednesday, December 17, 2014 4:00 PM
  • I hear you point, but this almost seems to go down some rabbit hole of never ending what ifs.

    I'm not downplaying your concern, only suggesting I don't know what you do period, let alone with App-V that is 100%.
    Yes an admin can change the ownership of the folder, then edit the security permissions, but what are you going to lock down that someone with admin rights couldn't unlock? I would imagine you don't give users admin rights at all.

    Is this something that used to work with PackageStoreAccessControl? If so, and the replacement for this feature isn't appropriate for you, I would definitely tell MS.

    You can test changing the packageinstallationroot location to a secure drive or folder (just do it before publishing happens). 

    Also, you can always deliver applications differently.

    I'll be curious what you end up doing.

    Wednesday, December 17, 2014 5:31 PM
  • I hear you point, but this almost seems to go down some rabbit hole of never ending what ifs.

    Not sure what these rabbits are doing in this story as it is not even christmas ;)

    Yes an admin can change the ownership of the folder, then edit the security permissions, but what are you going to lock down that someone with admin rights couldn't unlock? I would imagine you don't give users admin rights at all.

    The admin change was a reply on the statement you made before.

    My main question: Is there a proper way to be really sure that a user can only access the c:\ProgramData\App-V\<PackageGUID>\<VersionGUID> of packages entitled to him/her?

    I'm not talking about an admin accessing the folder but a normal user who manages to get into the C:\ProgramData\App-V\... folder (f.e. via a program file>open dialog).

    With App-V 4.x you can put NTFS security on the package's root folder. This is not the case with App-V 5.0. So I think the question still stands. Is there a real way to prevent this from happening? And I'm not talking about the security through obscurity Microsoft is suggesting in there KB2963211:

    By default, the location in Windows where App-V stores applications, %ProgramData%, is a hidden folder that most users will not understand how to browse.

    Thursday, December 18, 2014 8:42 AM
  • Hello,

    No, that feature is not there in App-V 5. 


    Nicke Källén | The Knack| Twitter: @Znackattack

    Friday, December 19, 2014 5:18 PM
  • I'm writing App-V 5.0 guidelines for a company where security is important. So for me and maybe others I want to summarize where I do see potentially a security issue: 

    Since putting permissions on C:\ProgramData\App-V\... is not allowed, a user could browse (through another application) in the app-v client cache.  What I also understood is that putting security on the folders of the shared content store is ok. So to wrap up:

    This could lead to a user starting an unauthorized application when (Shared content store is used):

    • application is a single executable (main .exe is always local since it is in the publishing block)
    • application exists of more files (no registry items) and is locally mounted

    When shared content store is not used, sooner or later all files will be local.

    One could argue that this can be blocked by applocker or similar technology. However, coping out those files to a location where applocker is not active bypasses this.

    Besides staring an application there is the possibility of coping sensitive information out of the program files. It is against all best developer practices, I know. But hey, I've seen applications which f.e. have an access database in the program files. I see an potential issue when (shared content store is used):

    • application is mounted

    When shared content store is not used, sooner or later all files will be local.

    So to deal with this issue I only see a workaround by identifying the applications which fall in the above category during the intake process and isolate them on a separate environment (whatever that may be).


    • Edited by .dBase Tuesday, December 30, 2014 2:58 PM shared content store remark
    Tuesday, December 30, 2014 2:50 PM
  • Do you have the ability to put in tickets with MS?  Not for nothing, I hope I have been helpful, but I wouldn't base an entire company directive on a forums say so, let alone my say so :).  Heck I don't even pick out my shirts without advice from others.

    That said....

    application is a single executable (main .exe is always local since it is in the publishing block)
         I don't believe this is correct, the main exe is not part of the publishing block.  In fact I just experimented something with WinRAR, and in the XML only the .ico files were part of publishing block.

    application exists of more files (no registry items) and is locally mounted
         Do you mean applications exists of NO more files (just the main exe?) 

    When shared content store is not used, sooner or later all files will be local.
         Correct, however even with SCS, you can mount packages.  In my opinion I wouldn't consider SCS having more/less security.

    But I keep hitting my head against how NTFS folder security on each folder to ONLY the provisioned users would give you the security you want.  All it would take is 1 user who has legitimate rights to the app copying it to a shared location and then any other user copying it from there.

    But that goes back to my main point.... when it comes to security I wouldn't take it as gospel truth anything less then a response from MS (or someone in the companies ISO obviously).  I am very happy offer my opinion but I'd hate to have you write a guideline based on what I have said without verifying it.

    Good luck! 

    Tuesday, December 30, 2014 7:45 PM