#113 Reducing permissions as a Windows service

[Heinrich Moser]

Currently, on Windows, E-MailRelay installs itself as a service running as "Local System". According to the documentation, there is no user-id switching on Windows, so the service runs with full system permissions.

To mitigate the effect of potential 0-days, I'd like to run the service with lower permissions - for example, with the built-in NT Service*Servicename* account. I am aware that this means that I'll have to assign appropriate permissions to the log, queue, etc. directories.

Has this been done before? Is this a "supported configuration"?
* If yes, is there a checklist of permissions that need to be set?
* If no, should it work in principle, or are there some known issues that make it not worth trying?

[Heinrich Moser]

(Should be NT Service\Servicename, the backslash messed up the formatting.)

[Graeme Walker]

That's a good idea. I expect this has been done many times, but I have had no feedback to share with you.

In my (limited) understanding you can set the account used by the service easily enough using the "Services" tool. The emailrelay service is actually a service wrapper that executes the emailrelay server in a separate process, and the account propagates from the service wrapper, on to the main emailrelay server process, and then on to any filter or address-verifier scripts.

If you control the account permissions carefully I am not sure there is much benefit in doing any userid switching as is done on unix, but I am open to persuasion on that point.

What would be the 'output' of this excercise? Perhaps a powershell script to set up a suitable account? I would be happy to help with feedback and testing.

[Heinrich Moser]

Thanks for the feedback.

I agree that userid switching on Windows probably won't make sense: AFAIK, Windows does not have the "privileged ports < 1024" restriction that requires root on Unix, and you cannot easily do a "user switch without a password" anyway. The idiomatic way on Windows is to run the service itself with a lower-privileged account.

As "output", I guess documentation, i.e. a checklist of permissions that are required, would already be a helpful first step for users who want to harden their system.

I'll do some tests in the next days and report back my findings.

[Heinrich Moser]

It worked!

I changed the service user to its virtual service account and granted modify permissions to emailrelay.pid, the spool directory and the log directory. Here are the exact cmd commands I used. (To future readers: note that I used a non-standard log directory, you might need to change that path.)

net stop emailrelay
sc config emailrelay obj= "NT Service\emailrelay"
icacls "C:\ProgramData\E-MailRelay\emailrelay.pid" /grant "NT Service\emailrelay":M
icacls "C:\ProgramData\E-MailRelay\spool" /grant "NT Service\emailrelay":(OI)(CI)M /T
icacls "E:\LogFiles\E-MailRelay" /grant "NT Service\emailrelay":(OI)(CI)M /T
net start emailrelay

Notes:

• This works for my configuration, it might not work with features I do not use (filters, Windows event log, etc.).
• By default, the "Users" group has read permissions to C:\ProgramData and its subfolders, so it's not necessary to assign explicit read permissions to C:\ProgamData\E-MailRelay.
• An alternative would be to grant modify permissions to the whole C:\ProgramData\E-MailRelay directory. That's easier, but it also allows the process to modify its own configuration files, so it's arguably less secure.
• For the super-paranoid, I suspect that it might be possible to tighten the log file directory security so that only new files can be created and existing files can only be appended (instead of modified), but I didn't try that.
• The space after obj= in the sc command line is important. Yes, sc's syntax is weird.

[Graeme Walker]

That's really useful, thank you. I'll add that information to the 'running as a service' section of the emailrelay 'windows' document.

[Heinrich Moser]

Glad to hear that it's useful.

Oh, and thanks for your help and for maintaining E-MailRelay! Since Microsoft removed its built-in SMTP server in Windows Server 2025 and hMailServer is no longer maintained, there are not many simple and free mail forwarding alternatives left on the Windows platform.

[Graeme Walker]

Unfortunately the virtual service account is a member of the Users group, which allows it to create files with few restrictions. That makes it pretty useless for a zero-trust install, as far as I can see (IANAWA). For that I think you would have to set up a (non-virtual) account with a password and take a hit on password management.

[Heinrich Moser]

True, a non-virtual account would allow further restrictions. Still, the virtual service account is already much more secure than LocalSystem, so I'm happy with the solution. It hits the sweet spot balancing security and convenience for me.