[JIRA] (IDP-1927) Make Jetty run under its own credentials for windows installs

Wed Oct 5 12:16:15 UTC 2022

Rod Widdowson ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=59fb32bbc24efb3c4ed3c977 ) *commented* on IDP-1927 ( https://shibboleth.atlassian.net/browse/IDP-1927?atlOrigin=eyJpIjoiMzVlNDM0NWE0NDlkNGViNjgyZjBkYjdhOTBlODE3YmEiLCJwIjoiaiJ9 )

Re: Make Jetty run under its own credentials for windows installs ( https://shibboleth.atlassian.net/browse/IDP-1927?atlOrigin=eyJpIjoiMzVlNDM0NWE0NDlkNGViNjgyZjBkYjdhOTBlODE3YmEiLCJwIjoiaiJ9 )

> 
> 
> 
> I thought there was a way to have a root-like account impersonate a
> lower-privilege one at runtime.
> 
> 

Absolutely. It's what servers (like SMB and indeed) use to pretend that they are the user who’d data they are servicing. (Of course when they came to do V1 of docker they introduced an entirely different mechanism, but I digress).

I’ve been avoiding this for several reasons

* It’s all done programmatically and I’m still hoping to avoid writing any C/C++/C# to make this work. (actually I’d need a great deal of persuasion to write code)
* Impersonation is a per-thread characteristic - I’d need to be completely convinced that the JVM was inheriting the impersonation token correctly when it created threads (and I have never been impressed by the Windows expertise demonstrated by the Windows JVM writers).
* When it comes to it there is still a privileged process kicking around.

Running a service as a specific process is the “Windows way”, but it comes at the cost of needing a password to start the process (AFAIK - but see below). You don’t actually need a password to start a process - just call CreateProcessAsUser ( https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessasuserw ) ).

The nice thing about creating a process as a user (with or without password) is that there is no way that privilege can escape. The user can be as unempowered as we choose (it just has to have read and write access to the right files and be allowed to listen on port 80 & 443).

We are diving deep into the area about which I know nothing but it appears that Virtual Accounts ( https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-service-accounts ) offer some of the advantages of the rather more coherent Unix “Run as this process which doesn’t have a password” (How hard would that have been to orchestrate for Windows?)

Of course the architecturally correct (but probably infeasible) way to do this is to spot that Jetty wants to start itself as a slave process (indeed, the installer sweats buckets to stop it doing that). So there is an natural alignment between the Windows Service idea of “Do something on Start”, “create a process”, do “something to stop” and Jetty. But that would require mixed mode code and surgery inside Jetty where it forks the process (to make it call CreateProcessAsUser). it would probably also require some abuse of the Windows Service architecture as well.

We are *so* not in that business (which not to say that the jetty people should be - but if they had cycles they would be better invested in doing a decent runtime JVM).

On reflection overnight I am reasonably convinced that creating a user as part of the installation is the wrong way to go. It seems like a far better bet to pass the name of an already existing account in to the installation (and we can persist a username so that we can survive updates). That puts the question of passwords and passwordless deployment back on the deployer who should be the domain expert (or of course our colleagues in the Federations who have to support them).

I have some further and details spelunking to do around the service installation (about password inheritance) which I’ll detail in further technical notes but my current plan (once my research is done is)

* Document how to take an existing installation and make it run as a non privileged account. (Possibly with notification of things you need to redo after every update)
* If possible, encapsulate this into the installer ( msiexec /i idp.msi SHIBD_USER=.\foobar )
* Otherwise (and again only if possible) investigate (or encourage others to investigate) writing scripting post installation options (ugh, powershell I really don’t want to learn that)

( https://shibboleth.atlassian.net/browse/IDP-1927#add-comment?atlOrigin=eyJpIjoiMzVlNDM0NWE0NDlkNGViNjgyZjBkYjdhOTBlODE3YmEiLCJwIjoiaiJ9 ) Add Comment ( https://shibboleth.atlassian.net/browse/IDP-1927#add-comment?atlOrigin=eyJpIjoiMzVlNDM0NWE0NDlkNGViNjgyZjBkYjdhOTBlODE3YmEiLCJwIjoiaiJ9 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100207- sha1:427dab2 )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/commits/attachments/20221005/e224ffac/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-003d7c2a-60a6-4eec-8065-b2f45621bb63
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20221005/e224ffac/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-b0c33cbe-33c6-451b-93f3-1eafa43a4c76
Type: image/png
Size: 457 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20221005/e224ffac/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-0ad260e0-dffb-416c-8ff4-13fca907d85b
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20221005/e224ffac/attachment-0005.png>