[Win32/C#] Impersonate LocalSystem

[johnwoo]

Stel: ik heb een Windows service gebouwd. Deze draait als LocalSystem. De service leest zijn configuratie uit enkele bestanden in z'n executable folder. De configuratiebestanden worden geschreven door een wizard welke door Administrator wordt uitgevoerd. Enkele configuratie strings zijn echter van gevoelige aard (wachtwoorden).

Op dit moment (nog in testfase) "beveilig" ik deze wachtwoorden door de installer de programmafolder enkel lees- en schrijfbaar te maken voor Administrator (om de configuratie te kunnen wijzigen) en LocalSystem (zodat de service de bestanden kan inlezen) en alle andere users te weren.

Maar eigenlijk wil ik de wachtwoorden encrypten met de hiervoor uiterst geschikte ProtectedData API. Hiermee kan ik een string wegschrijven die enkel door hetzelfde account weer kan worden gelezen. En daar zit het probleem: dat zijn twee gebruikers, Administrator en LocalSystem. Om dit toch voor elkaar te krijgen wil ik de configuratiewizard het LocalSystem account laten impersonaten, zodat de service ze toch kan lezen.

En dat wil niet echt vlotten. Ik blijf een "unknown username or bad password" melding krijgen wanneer ik als password null of "" opgeef, en als username/domain heb ik allerlei varianten op "NT AUTHORITY\LocalSystem" geprobeerd. Hoe impersonate ik (als Administrator) de LocalSystem user? Voor zover ik weet hebben speciale system accounts geen wachtwoorden maar is een impersonation privilege benodigd om ze te impersonaten. Of is er een andere oplossing om de configuratiebestanden te versleutelen zodanig dat beide processen ze kunnen lezen en schrijven, zonder het probleem te verplaatsen door symmetrische encryptie met een gebruiker-onafhankelijke sleutel te gebruiken die vervolgens weer ergens moet worden opgeslagen?

Op zich zou het blokken van bestandstoegang de configuratie redelijk veilig moeten maken voor andere gebruikers, maar we weten allemaal hoe ingeburgerd het is in de Windows wereld om je eigen gebruikersaccount Administrator-rechten te geven, dus het doel van deze stap is meer het voorkomen dat iemand de wachtwoorden zomaar in cleartext kan lezen als de eigenaar zichzelf ingelogd laat terwijl hij even niet bij de PC zit.

P.S. enige uren google hebben tot heden niks opgeleverd, enkel wat informatie over het impersonaten van NetworkService/LocalService, maar dat mag alleen LocalSystem en heeft dus geen nut voor het configuratieprogramma (als ik de LocalSystem impersonation al niet verkrijg )

[ Voor 18% gewijzigd door johnwoo op 24-01-2008 15:05 ]

[Niemand_Anders]

Lees eens de MSDN! ServiceProcessInstaller class, property Account.
Als je ServiceAccount.LocalService doorgeeft hoeft je geen losse username en password meer mee te geven.

Maar kon je dit antwoord niet via Google vinden? Als ik zoek op 'C# windows service LocalService ' is het bij mij al raak bij het eerste resultaat.

Daarbij is Administrator niet hetzelfde als LocalService . LocalService is net als Administrator een systeem user. Omdat je het wachtwoord van LocalService niet weer, kun je ook niet impersonaten onder dat account.

Daarom hebben services ook de mogelijkheid om gewoon standaard als LocalService of NetworkService te draaien.

Daarbij mag LocalService standaard niets, vergelijkbaar met de 'guest' user. Heb je meer rechten nodig, gebruik kan LocalSystem.

Maar nogmaals, dit staat allemaal ook in de MSDN welke geinstalleerd is bij Visual Studio en anders ook nog online op http://msdn2.microsoft.com/library.

[Gerco]

Niemand_Anders schreef op donderdag 24 januari 2008 @ 16:42:
Lees eens de MSDN!

Lees eens de startpost!

De TS heeft zijn service al als LocalSystem draaien. Wat hij wil is een *ander* programma ook als LocalSystem laten draaien om wat data te versleutelen die vervolgens door zijn service gelezen moet worden.

ontopic:
Het impersonaten van LocalSystem heb ik geen idee van, maar kun je het probleem niet omzeilen door niet je administratieprogramma maar de service zelf die gegevens te laten encrypten? Maak dan via Remoting of 1 of ander IPC mechanisme een verbinding met de service en laat deze een methode aanbieden om de settings te wijzigen. Kun je als bonus ook nog aan remote administratie gaan doen (indien je Remoting of sockets kiest).

[sig69]

Of je detecteert wijzigingen in de configuratie mbv een FileSystemWatcher, leest de nieuwe configuratie in en slaat 'm direct weer versleuteld op.

[johnwoo]

Ik gebruik al een FileSystemWatcher; als de configuratiewizard een verandering opslaat wordt die direct doorgevoerd in de service (als die op dat moment draait uiteraard). Op zich is het wel een idee om voor iedere "secure" string ook op te slaan of deze encrypted is of niet, en zo niet, om de service hem dan encrypted op te laten slaan, echter blijven de strings dan plaintext staan tot de service weer gestart wordt als die op dat moment niet draait. Datzelfde nadeel geldt voor de IPC methode; de service moet dan draaien. Nu is het zo dat de service direct na installatie ook pas gestart wordt door diezelfde wizard als de initiele configuratie voltooid is. Het netste lijkt me toch om beide processen bij het bestand te laten.

@Gerco: LocalSystem, niet LocalService

[ Voor 4% gewijzigd door johnwoo op 24-01-2008 18:37 ]

[H!GHGuY]

Doe het eens omgekeerd.

Laat je LocalSystem de Administrator account impersonaten.

[johnwoo]

Liever niet; Administrator is een gewone account met password, en ik zet liever niet een Administrator password plaintext in een config file (die kan niet encrypted in LocalSystem's account, omdat je dan geen manier hebt om 'em in te stellen).

[Gerco]

Is het trouwens wel handig om die service als LocalSystem te draaien? Dan kan elke andere service (die meestal ook onder LocalSystem draaien) ook gewoon bij die config. Als die compromised worden, kan die data dus uitlekken zonder dat jouw service compromised is geweest.

Misschien een idee om die service te laten draaien onder een ander, dedicated, user account? Dan heb je ook gelijk geen problemen meer met impersonation.

[Verwijderd]

Gerco schreef op donderdag 24 januari 2008 @ 20:08:
Misschien een idee om die service te laten draaien onder een ander, dedicated, user account? Dan heb je ook gelijk geen problemen meer met impersonation.

Precies wat ik dacht. De applicatie moet dan natuurlijk ook impersonaten met dat account. Alleen dan wordt het pas écht lastig voor andere software om je wachtwoord uit te lezen. Grote nadeel hiervan is dat de service dan nauwelijks toegang heeft tot het systeem; LocalSystem mag in principe overal bij.

Trouwens, de eigenlijke gebruikersnaam van LocalSystem is SYSTEM, zie ook task manager. Probeer daar eens mee te impersonaten? Ik denk trouwens dat je sowieso niet zal kunnen impersonaten als SYSTEM, denk je eens wat voor gevolgen dat heeft. Ik weet niet wat de standaard instellingen van Windows zijn, maar als het kan dan is het iig met SYSTEM.

Nog een optie is de token nemen van je service en je applicatie daaronder te impersonaten. Dan ben je gegarandeerd van de juiste token. Je moet hiervoor wel privileges hebben die Administrator standaard niet heeft (SYSTEM wel). Wijziging in de security policy dus, wellicht niet mogelijk in jouw situatie.

En anders, wat ik sowieso verreweg het netst vind, gebruik een der IPC technieken om je service de data op te laten slaan. .NET Remoting, Named Pipes, etc afhankelijk van de taal waar je mee ontwikkelt.

Wellicht nog geschikter is de system scope van ProtectedData te gebruiken. Ik vind SYSTEM in deze context breder in scope dan gebruiker, en mij lijkt LocalMachine geschikter voor services. Zie MSDN:

The protected data is associated with the machine context. Any process running on the computer can unprotect data. This enumeration value is usually used in server-specific applications that run on a server where untrusted users are not allowed access.

Dit stelt alle applicaties dus in staat om te decrypten en is wellicht niet wat je wilt.

Meest veilige is een speciale gebruiker met wachtwoord aanmaken. Anders service het wachtwoord laten opslaan.

Maargoed, dit alles afhankelijk van je applicatie.

[ Voor 12% gewijzigd door Verwijderd op 25-01-2008 01:23 ]