Running Emby Server as Windows Service under Restricted User Account

[Guest]

@softworkzare there considerations being made regarding the security context in which the Emby Server application itself is running? I've spent a non trivial amount of time on filesystem ACLs to ensure that with the Emby Server application running as a service in the context of a non privileged user account things will still work. It would be nice if this kind of thing could be documented as a best practice for administrators, or even that the application itself will generate a warning if it detects that it's running in an administrative context.

 

[softworkz 5073]

Hi,

I've split out your post into a new topic as it is just loosely related to the Incident Report.

Having a Windows installer which installs Emby as service into ProgramFiles with the data in ProgramData is one of the oldest items in my list but it had gotten permanently surpassed by higher-priority items and at some point even closed as there didn't seem to exist much interest in it.

After the incident I have added it to a list of possible consequent changes 

 

Creating the setup is between easy and challenging, depending on how much automation is desired (user account creation, assigning permissions, service installation). 
Setting up permissions can be quite a task, and user experience is another part: Windows users are not accustomed to the need of setting permissions everywhere before they can even see and browse to select a folder.

How was your experience and how did you set it up?

[Guest]

When I first set it up I used the windows installer. I converted it to a portable install and set it up to run under a standard user account. I reorganized my library video folders to move some subdirectories higher in the tree and then at the appropriate level granted the user account appropriate permissions. Initially I wanted to deny delete (partially breaking emby functionally) but decided that my Snapraid delete protection and full/delta backups could cover malicious deletes. Of course I restrict delete only to admin users in Emby itself.

Overall not a bad experience. Just took a little planning and some migration work.

[rbjtech 5284]

I run Emby as a windows service on a non-priviledged account - to keep things simple, I've just added the Service Account with RW permissions on the emby install folder (and all other 'external' folders - cache, logs, metadata, media (for writing metadata) - via remote shares using the same service account etc

using something like sysinternals - it pretty easy to see exactly what is being written to on startup and emby usage - but I'm not sure if we want to go down to what files 'could' remain read only - or need privledge escalation for updating (I'm thinking new releases, or plugin updates for example).    The way I currently upgrade, is to stop the Service - and then run the standard App as my current user (a member of the Admin group..  ) - so actually, this is not great lol - Emby 'should' be able to upgrade as a service - I don't see why it could not.

I'm sure there are also lots of other permissions required to actually 'install' emby - such as registering DLL's, Firewall Rules etc - all that I believe will NEED Admin.  But once setup, Emby itself runs perfectly well without needing Admin - As I have been running it in this state for a while.

[softworkz 5073]

6 minutes ago, andrewds said:

I used the windows installer

This is a click-2-run installer. It installs Emby on Windows, but it's not a "Windows Installer (MSI)" setup. And it can only install for the user who is logged-in and runs it.

[Guest]

Yes. And I converted my install to the portable version.

[softworkz 5073]

7 minutes ago, rbjtech said:

Emby 'should' be able to upgrade as a service - I don't see why it could not.

Installation requires permissions to make changes to the Program Files folder - which the service account itself should not have, exactly for the purpose that it is not able to change its own executable code.

The solutions for automatic updates are:

• A second service (e.g. EmbyUpdateService) which runs under the LocalSystem account, and its only purpose is to stop the service, install an update and restart the service afterwards
• A scheduled task created during installation which is set to execute in an elevated context, for the same purpose like above

[rbjtech 5284]

5 minutes ago, softworkz said:

Installation requires permissions to make changes to the Program Files folder - which the service account itself should not have, exactly for the purpose that it is not able to change its own executable code.

The solutions for automatic updates are:

• A second service (e.g. EmbyUpdateService) which runs under the LocalSystem account, and its only purpose is to stop the service, install an update and restart the service afterwards
• A scheduled task created during installation which is set to execute in an elevated context, for the same purpose like above

ok - so I guess that's the point I was making above - if we are going the whole hog - and making emby run with least priviledge - then GREAT - I'm all for that - but going from 'no permissions' to 'least priviledge' permissions may be a big ask !

[softworkz 5073]

2 minutes ago, rbjtech said:

but going from 'no permissions' to 'least priviledge' permissions may be a big ask !

I'm not sure what you mean and which distinction you are up to?

[Guest]

2 minutes ago, softworkz said:

I'm not sure what you mean and which distinction you are up to?

A good example in my case would be ffmpeg. If I had attempted to truly restrict everything this account could do, ffmpeg wouldn't work. I didn't want to have to deal with that and whatever other problems it may have had. So, I just set it up as a standard user account. The filesystem took some work because I don't use all direct attached storage.

Architecting it to least privilege is more complicated than all access or no access.

[softworkz 5073]

I don't understand that "no permissions" or "no access" you won't get any executable to to run without any permissions.

[softworkz 5073]

49 minutes ago, andrewds said:

If I had attempted to truly restrict everything this account could do, ffmpeg wouldn't work. I didn't want to have to deal with that and whatever other problems it may have had. So, I just set it up as a standard user account.

A suitable starting point for the permissions of the service account is the permission set of the built-in "NETWORK_SERVICE" principal. It includes all the basic permissions for running a .net application. Our service user can inherit permissions from NETWORK_SERVICE. Starting from there, it should be a reasonable task to figure out all the permissions that are needed on top of this and have the installer apply them after creation/cloning.

Edited June 23, 2023 by softworkz
Clarified relation to NETWORK_SERVICE

[rbjtech 5284]

14 hours ago, softworkz said:

I don't understand that "no permissions" or "no access" you won't get any executable to to run without any permissions.

ok - 'no permissions' on my part was bad terminology - I meant 'existing' permissions - so execute under a 'normal' non-admin account.

14 hours ago, softworkz said:

A suitable starting point for the permissions of the service account is the permission set of the built-in "NETWORK_SERVICE" principal. It includes all the basic permissions for running a .net application. Our service user can inherit permissions from NETWORK_SERVICE. Starting from there, it should be a reasonable task to figure out all the permissions that are needed on top of this and have the installer apply them after creation/cloning.

Possibly - all I know is I currently run emby as a basic 'user' (as a service, thus granted 'Logon as a Service' rights - it may inherit the NETWORK_SERVICE credentials/principle above, I'm not sure) - and have simply given that service account full write permissions on everything under my emby folder, plus remote shares for the media/metadata.

For code execution, this is running fine - but for updates/change to critical files, emby does not update via a service, so I would like this to be taken one step further and need an elevated priviledge to do so.   The idea of a 'UpdateService' account sounds great - this may just be a member of Admin, or have exclusive rights to modify/change the critical files.  This account is obviously not exposed in any form to the Emby API or internal code.    During an update, I would presume the Emby Service would be stopped and the update service started, once permission has been manually granted (not auto, that is a poor security practice) , then it updates, closes and restarts the main Emby Service.. ?

Edited June 24, 2023 by rbjtech

[softworkz 5073]

6 hours ago, rbjtech said:

Possibly - all I know is I currently run emby as a basic 'user' (as a service, thus granted 'Logon as a Service' rights - it may inherit the NETWORK_SERVICE credentials/principle above, I'm not sure) - and have simply given that service account full write permissions on everything under my emby folder, plus remote shares for the media/metadata.

NETWORK_SERVICE has a lot less permissions than a regular user. Write permissions are only required for everything under "programdata" (=> "Program Data") but not for "system" (=> "Program Files").

6 hours ago, rbjtech said:

For code execution, this is running fine - but for updates/change to critical files, emby does not update via a service, so I would like this to be taken one step further and need an elevated priviledge to do so.   The idea of a 'UpdateService' account sounds great - this may just be a member of Admin, or have exclusive rights to modify/change the critical files.

That service would run as "LocalSystem"

6 hours ago, rbjtech said:

During an update, I would presume the Emby Service would be stopped and the update service started, once permission has been manually granted (not auto, that is a poor security practice) , then it updates, closes and restarts the main Emby Service.. ?

The UpdateService would be running continuously and be installed by the setup to run under the LocalSystem account. 

It would also handle shutdown and restarting of the Emby service. It would check for and download updates (we can't let the Emby server download the update, because then we can't be sure whether it's genuine).
If an update is available and ready for installation, the update service would notify the Emby service. The Emby service can then tell the update service to perform the update (same for restart or stop). What makes this architecture secure is the the minimal "vocabulary" of interaction between the two services. It would be flawed when the Emby service would be able to send an arbitrary command to the Update service for execution, but this way, 'update', 'restart', 'shutdown' is all it can tell the UpdateService to do.

Edited June 24, 2023 by softworkz