• View Communities
    • Citrix Developer Network
      The place for unfiltered straight talk on Citrix products. Blogs, code downloads, best practices, APIs, and more can all be found here.
    • Citrix Ready Community Verified
      Does it work with Citrix? Application compatibility questions are a thing of the past with the new Citrix Community Verified site.
    • Blogs
      Learn the latest from the Citrix employees who are building application delivery infrastructure technologies.
    • Blogosphere
      The Citrix Blogosphere is a window into the thousands of conversations taking place about Citrix and Application Delivery.
  •  Sign In
The Citrix Blog
Personal Blog
Joseph Nord
posted by Joseph Nord

Administrators are used to the idea, that running applications under Application Streaming will permit poorly written applications to run in a multi-user terminal services environment.   For example, if the application wants to write to the \Windows directory, no problem; the application will believe that it wrote there and later if it reads the same stuff, it will see what it put there and generally, the application will work. What is less known is that that Application Streaming and XenApp publishing can be used to reduce the rights of the application at execution so that it has a reduced chance of hurting the machine.

Privilege vs. Isolation

Isolation and "privilege" are different things. Running the application "isolated" does not mean that the application can't do powerful things.   An administrator privilege ISOLATED application CAN still perform privileged operations such as adding new users to the machine, marking them as administrators and adding them to the remote desktop group where the evil doer can then remotely login, as a non-isolated administrator and easily do evil things. 

Not a problem for XenApp hosted execution

To be clear, none of this is important for XenApp hosted execution.  Here, the user is already a user and stripping power from the user to get them to user power is a "nop" because they were a "user" to start with.  This discussion of "privilege" reduction is more of a Windows XP client side, or hosted desktop statement where "admin" power users are the norm.   On Windows XP, unless you're very good at locking down the machine the end user will be running as an "Administrator" and this is not desired.  How can you make this happen as little as possible?  How can you get MOST of the applications to run with the least privilege possible?

Brain damaged applications

Some applications even CHECK to see if they are admins and refuse to run if they are not.   Awesome!  If you can't figure out how to code it, demand admin rights machine wide!    You can easily hit a situation where 90% of your desktop applications will run fine without admin rights, yet you have no choice but to make the user a full blown administrator because some small subset of the applications demand admin rights; or perhaps, even really need them.

What about the "normal" applications that don't need admin rights, or at least don't need admin rights when run under isolation?  It would sure help if we could at least make the "all powerful" user be a "lowly user" for the purposes of the majority of application execution, even if the user is really an administrator.  You can, and XenApp makes this easy.  First, some history.

DropMyRigthts

Go back in time and take a look at this 2006 technet article from Microsoft on Least User Access and a description of the DropMyRights utility by Michael Howard.   Excellent stuff and here is a related set of blogs from Aaron Margolis of Microsoft who seems to have a passion for running apps as a user!   The output of this early work was a command line utility called DropMyRights which would duplicate the user's logon token, strip the powerful rights - and then use the modified token to launch the application.  Good stuff.  As an example, here is the .BAT file I used to use to launch MS Outlook.

  • dropmyrights "%PROGFILES%\Microsoft Office\OFFICE11\OUTLOOK.EXE"

The idea of running apps on forced user privilege on Windows XP was not unique to App Streaming, but we did wrap pretty GUI around it and wrapped application publishing around it to make it easy to use - and then we didn't tell anyone it was there.  To be fair, most of the usage was server side, so it wasn't as important, but hosted desktops are changing this.

The XenApp publishing system makes this dropping of user rights accessible via easy to use GUI.

Access Management Console

Here's the AMC screen that controls this setting.  Notice that this "stripping of rights" is controlled in the AMC - not in the streaming profiler.  Could it be controlled in the profiler?   Sure.  Both of these tools are nice GUIs which could accomplish the same goal, so yes, it could be controlled in the profiler, but it isn't.  One could even make a really good argument that it is in the wrong place and SHOULD be in the profiler because this is where the admin is that knows more about the application.  I would agree, but it wouldn't matter, it's still in the publishing console whether or not this seems like the right place.  


 
When I wrote the draft for this post, I did it in a place without internet access, so I couldn't easily check the default.  I wrote that SURELY! the default is that we strip the rights before launching the app.  Surely, Shirley, what ever you call it, the default is the other way; by default, the launch leaves the user's token alone and launches the app using what ever power the user has according to logon.  If you CHECK the box, then the Access Management Console tells the Citrix IMA to tell the Citrix Web Interface to tell PNAgent to tell the Streaming Client that it should strip power from the user for the purposes of running this stream to client application.  Where the application will permit it, You should set the checkbox.

XenApp server side, it won't change anything;XenApp Client side, it will ensure that the application is launched using a user token that has "lower power".  Lower power is better...

Here are some other writings on Application Streaming related to this:

  •  Enhancing the Security of Application Streamingfor Desktops

Enjoy!

Joe Nord

Citrix Systems Product Architect - Application Streaming

Labels

xenapp xenapp Delete
xendesktop xendesktop Delete
lang-eng lang-eng Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Nov 02

    Ross Smith says:

    Interesting, thanks Joe.  Do Citrix have any plans to extend this, to autom...

    Interesting, thanks Joe.  Do Citrix have any plans to extend this, to automatically lock down applications as much as possible?

    I remember watching the release of Winternals Protection Manager with interest when that came out - it could lock down every application on a network, but with a great workflow to inform both the user and the administrator if an application tried to do something that wasn't allowed.  Unfortunately Microsoft buried it and I've been waiting in vain for them to bring out a replacement.

    Have Citrix considered adding fine tuned application lockdown to XenApp?  If XenDesktop makes this as popular as I think it might, anything that can be done to make application security easy for administrators has to be good (and would be another great selling point for XenApp).

    What I would really love to see would be:

    • Having an ability to monitor applications, and see whether they are well behaved, and what access they need to run.
    • Running applications as least-privileged by default.
    • Allowing granular registry & file access if needed (with the first step being to allow programs to write to their own areas).

    It should be relatively easy for XenApp to watch what a program uses when run, and to suggest a security template automatically.

    The really nice thing about that is it can potentially catch behaviour that is out of the norm, which is exactly the kind of thing you need to look for when viruses try to exploit a vulnerability.

    And depending on how paranoid an administrator you are, there could be a range of possible reactions:

    • Allow the action and just log it.
    • Block the action, return an error to the program, and inform the user and administrator.
    • Pause the program, inform the user, and see if an administrator can authorize it immediately.
    1. Nov 02

      Joseph Nord says:

      Hi Ross, thank you for the feedback.  App isolation makes it pretty easy to...

      Hi Ross, thank you for the feedback.  App isolation makes it pretty easy to figure out which application tried to write to places that are not permitted for write, but converting that into a reporting structure and decision matrix of what is permitted and not is pretty involved.  Maybe a better place for this is in the evolution of anti-virus or software firewalls. 

      Wearing an isolation hat, my goal is to make the ill-behaved application run; make them run when the application lacks the ability to really write to protected spaces, but requires this ability to function.  By forcing application execution privilege back to "really a user", we are able to better protect the machine because even if the app writes to places that aren't isolated, the OS will still process the request from a perspective of user privilege.  This is a good plus - the same good plus that DropMyRights brought to Windows XP, but delivered in automatic fashion wrapped in a nice GUI and publishing.

      1. Nov 04

        Ross Smith says:

        Hi Joe, I agree, its the kind of thing that I think Anti-Virus companies should...

        Hi Joe,

        I agree, its the kind of thing that I think Anti-Virus companies should be moving to, and if we were planning to roll out standard applications that's where I would be looking.

        However, I'm not at all sure that standard anti-virus or intrusion detection packages would play at all nicely with XenApp.  You can't run them on the client now, and they really aren't going to have a clue what's going on server side.

        I'm very new to XenApp, so I've got a lot to learn, but security is always close to my heart, and with the number of viruses taking advantage of vulnerabilities in 3rd party software, the more I can lock down applications, the happier I will be.  I think XenApp helps a lot, but even then I'm paranoid, so the more tools you can give me the better

        The only real concern I have with your post is you say this works "where the application will permit it".  The thing is, I don't want to only lock down well behaved applications.  If anything, it's the badly behaved and badly programmed applications that I'm the most worried about.

  2. Nov 04

    Johannes Norz says:

    Hi Joe, a great blog entry. I didn't know until now what it really does, my 1st ...

    Hi Joe, a great blog entry. I didn't know until now what it really does, my 1st gues was it runs the app as streaming service user account, but this is not true, so I just wanted to ask you about this setting. Hope, I'll find out how stripping rights works (does it just strip local group membership, i.e. local admins, power users, or can it stripp domain groups too, and if so, how does it know which ones to strip?).

    I got another problem, quite the other way round: an App that requires me to give users admin rights. On a XenApp Server. Damn. Why? It uses to write a file into the windows directory, location hard coded. The programmer must have been drunken (maybe this is normal for programmers of accounting software). More, this file has a fixed name, so the program can't run twice. Streaming helped me with the 2nd issue, but users still need to be admins, as users can't create files in windows directory. Wouldn't it be easy to create a setting in profiler that causes the streaming client to ignore rights in file system? Is my f***y program the only one in the world behaving like that?

    1. Nov 19

      Joseph Nord says:

      > local admins, power users, or can it stripp domain groups too The techniqu...

      > local admins, power users, or can it stripp domain groups too

      The technique is not dependent on local machine account vs. domain account.  It operates against the user "token" and that exists independent of where you authenticated.   There are about 20 "rights" that a user token can have.  The code strips the powerful ones to get the admin token reduced to the power of a normal user.  I don't have the code handy to look it up, but its a single API call to drop all the powerful rights.  Check the technet article reference at the top of this post.

      As for your app that "requires" admin rights, when run under isolation, the app can write to \windows all it wants and it will succeed, without writing to that location.  It will also succeed MULTI-USER friendly.  The write to \windows would fail on user account, but under isolation, the write will be converted into a write to space beneath %APPDATA%, in the user space.  Here, the write will succeed.  This also makes the app multi-user friendly as each user gets their own copy of the written file.

      The only place to get caught is if the app asks "Am I an admin"?  If it does, it will get an answer of "no" and this could cause it to conclude that it can't run when really it can.  Intuit Quickbooks used to do this; pretty sure the modern versions have this fixed.  

      1. 3 minutes ago

        Anonymous says:

        Wow, so you can strip rights, but by isolating the applications, they still run ...

        Wow, so you can strip rights, but by isolating the applications, they still run fine?

        I hadn't understood that at all.  Thanks for taking the time to explain, that's superb.  It means we can start off migrating apps to least privilege, and once we have enough migrated, we'll drop power user rights for the users who traditionally had problems with locally installed apps.

Add Comment