CLR Strikt säkerhet på SQL Server 2017

Hur kan en CLR-sammansättning skapad med PERMISSION_SET =SAFE komma åt externa systemresurser, anropa ohanterad kod och skaffa sysadmin-privilegier?

Detta beror på säkerhetsändringar som gjorts i .NET Framework, från och med version 4.5 (tror jag).

MSDN-dokumentationen för Code Access Security Basics säger:

.NET Framework tillhandahåller en mekanism för att upprätthålla olika nivåer av förtroende för olika kod som körs i samma applikation som kallas Code Access Security (CAS). Code Access Security i .NET Framework bör inte användas som en mekanism för att upprätthålla säkerhetsgränser baserat på koduppkomst eller andra identitetsaspekter. Vi uppdaterar vår vägledning för att återspegla att kodåtkomstsäkerhet och säkerhetstransparent kod inte kommer att stödjas som en säkerhetsgräns med delvis pålitlig kod, särskilt kod av okänt ursprung. Vi avråder från att ladda och köra kod av okänt ursprung utan att vidta alternativa säkerhetsåtgärder.

Och pekar sedan på sidan för säkerhetsändringar i .NET Framework som säger:

Den viktigaste förändringen av säkerheten i .NET Framework 4.5 är stark namngivning.

Vilket sedan pekar på dokumentationen för Enhanced Strong Naming som säger:

Starka namnnycklar består av en signaturnyckel och en identitetsnyckel. Sammansättningen är signerad med signaturnyckeln och identifieras av identitetsnyckeln. Före .NET Framework 4.5 var dessa två nycklar identiska. Från och med .NET Framework 4.5 förblir identitetsnyckeln densamma som i tidigare .NET Framework-versioner, men signaturnyckeln förbättras med en starkare hashalgoritm. Dessutom signeras signaturnyckeln med identitetsnyckeln för att skapa en motsignatur.

OCKSÅ står det i dokumentationen för Secure Coding Guidelines:

Code Access Security och Security-Transparent Code kommer inte att stödjas som en säkerhetsgräns med delvis betrodd kod. Vi avråder från att ladda och köra kod av okänt ursprung utan att införa alternativa säkerhetsåtgärder...

Så säkerhetsmodellen för .NET ändrades för flera år sedan, men SQL Server (fram till SQL Server 2017) har fått fortsätta använda den gamla säkerhetsmodellen. Det verkar som om, från och med SQL Server 2017, beslutet togs att inte längre stödja den gamla säkerhetsmodellen.

Jag misstänker att det att tillåta den gamla säkerhetsmodellen var:

förhindrar att SQL Server (åtminstone den CLR-relaterade funktionaliteten/komponenterna) baseras på de nyare .NET Framework-versionerna, och
ansvarig för det abrupta avlägsnandet av SQLCLR som en funktion som stöds från Azure SQL Database (stöd hade lagts till i slutet av 2014 med lanseringen av v12, men togs sedan bort helt från och med den 15 april 2016).

Så ja, det här suger lite. Vad det betyder (åtminstone för tillfället) är att man måste först skapa ett certifikat eller asymmetrisk nyckel (som har använts för att signera alla sammansättningar som ska laddas) i [master] för att sedan skapa en inloggning från och sedan bevilja UNSAFE ASSEMBLY till den inloggningen. Detta är samma sekvens av händelser som man behöver göra när man laddar EXTERNAL_ACCESS och UNSAFE Montering, men nu, tyvärr, måste göras för ens SAFE Sammansättningar.

Det finns för närvarande ingen mekanism för att hantera detta på ett helt portabelt sätt (dvs inte förlita sig på externa filer) och kan inte hanteras av Visual Studio / SSDT utan manuellt ingripande. Detta var ungefär redan fallet, men det var åtminstone möjligt att skapa en uppsättning för att hantera detta på ett helt portabelt sätt (dvs. helt inneslutet i ett .sql-skript):se Stairway to SQLCLR Level 7:Development and Security för detaljer (detta är en artikel som jag skrev).

Det är möjligt att skapa ett certifikat från hexbytes (dvs. FROM BINARY = 0x... ) men det fungerar inte med Visual Studio (som är beroende av MSBuild) / SSDT eftersom användning av certifikatet kräver användning av signtool och MSBuild använder sn .

För att detta ska göras fungerande så att Visual Studio/MSBuild/SSDT-publiceringsprocessen fungerar (vilket i sin tur skulle innebära att vem som helst skulle kunna skapa ett helt fristående .sql-skript som kan skapa den asymmetriska nyckeln utan att förlita sig på en extern fil), CREATE ASYMMETRIC KEY kommandot måste förbättras för att kunna skapas från en binär sträng. Jag har gjort det här förslaget på Microsoft Connect – Tillåt att asymmetrisk nyckel skapas från en binär hexbytesträng precis som SKAPA CERTIFIKAT – så stödja det :-).

Alternativt (för tillfället, tills MS förhoppningsvis skapar en bättre metod, såsom mina förslag på asymmetriska nyckel), kan du prova någon av de två teknikerna jag beskriver i följande blogginlägg (båda fungerar fullt ut med SSDT):

SQLCLR vs. SQL Server 2017, del 2:"CLR strikt säkerhet" – Lösning 1
SQLCLR vs. SQL Server 2017, del 3:"CLR strikt säkerhet" – Lösning 2

Som en sista utväg kan du överväga följande tillvägagångssätt:

TILLÄMPLIGT ställ in [master] Databas till TRUSTWORTHY ON

För nästa steg (dvs. CREATE ASSEMBLY ) för att utföra framgångsrikt, inloggningen som är databasägaren (dvs samma SID som används av [dbo] Användare av [master] ) måste ha UNSAFE ASSEMBLY lov. Om [master] ägs av sa eller någon annan sysadmin, då har den alla behörigheter och detta krav har uppfyllts. Men om [master] ägs av en lågprivilegierad inloggning (en "bästa praxis"), måste du köra följande sats för att CREATE ASSEMBLY att fungera när TRUSTWORTHY är ON :
```
EXEC (N'USE [master]; GRANT UNSAFE ASSEMBLY TO [{DB_Owner_Login}];');
```
Skapa sammanställningen i [master]
Skapa den asymmetriska nyckeln från sammanställningen
Släpp monteringen
ställ in [master] Databas till TRUSTWORTHY OFF
Skapa inloggningen från den asymmetriska nyckeln
Bevilja UNSAFE ASSEMBLY till den inloggningen (detta ersätter behovet av att DB där församlingen laddas ställas in på TRUSTWORTHY ON och för dess ägare Logga in för att ha UNSAFE ASSEMBLY tillstånd).

Observera att jag inte gjorde det inkludera den nya "Trusted Assembly"-funktionen som ett alternativ här. Anledningen till att det inte nämndes beror på att det har många fler brister än fördelar, för att inte tala om att det är helt onödigt i första hand med tanke på att befintlig funktionalitet redan hanterade situationen som "Trusted Assemblys" var tänkt att åtgärda. För fullständig information om det och en demonstration av det korrekta sättet att hantera befintliga, osignerade sammansättningar, se:SQLCLR vs. SQL Server 2017, del 4:"Trusted Assemblies" – The Disappointment.