webForumDet fria alternativet

Köra program med admin rättigheter

.NET

9 svar · 482 visningar · startad av clarkbones

Medlem sedan feb. 20013 023 inlägg
Frågan#1

Hej!

Finns det några möjligheter att köra en .NET-applikation med administratörsrättigheter trots att den inloggade användaren som startar applikationen inte är det?

Medlem sedan juni 20019 024 inlägg
#2

Icke-svar (fundering):

Låter inte speciellt logiskt att man kan ådra sig rättigheter som man inte har tillgång till. Det skulle innebära en enorm säkerhetsrisk.

Medlem sedan feb. 20013 023 inlägg
#3

Tja, det är ju endast applikationen, inte användaren som skall ha dessa rättigheter. Bör inte vara någon större fara så länge applikationen är korrekt skriven.

Jag vet att det går att göra, men jag vet inte hur...

Medlem sedan dec. 19991 072 inlägg
#4

Vet inte om det här är vad du är ute efter (eller om det ens funkar så...). Men man kan mha av CAS åsidosätta en användares rättigheter när det gäller speciella permissions.
Om en användare tex. inte har rättigheter att ändra i registret kan man köra:

Dim s As New Security.Permissions.RegistryPermission(Security.Permissions.PermissionState.Unrestricted)

'Be om tillåtelse...
s.Assert()

'KÖR KOD MOT REGISTRET HÄR

'Ta tillbaka förfrågan
s.RevertAssert()

För att då ändå få åtkomst. Du hittar fler olika Permissions under "System.Security.Permissions"

Medlem sedan feb. 20002 300 inlägg
#5

clarkbones skrev:

Tja, det är ju endast applikationen, inte användaren som skall ha dessa rättigheter. Bör inte vara någon större fara så länge applikationen är korrekt skriven.

Jag vet att det går att göra, men jag vet inte hur...

Det skulle innebära att man hur enkelt som helst skulle kunna skriva ett program som plockar åt sig admin-rättigheter, skapar ett nytt konto åt dig med admin-rättigheter och således få tillgång till hela burken...

Medlem sedan feb. 20013 023 inlägg
#6

Phorpher skrev:

clarkbones skrev:

Tja, det är ju endast applikationen, inte användaren som skall ha dessa rättigheter. Bör inte vara någon större fara så länge applikationen är korrekt skriven.

Jag vet att det går att göra, men jag vet inte hur...

Det skulle innebära att man hur enkelt som helst skulle kunna skriva ett program som plockar åt sig admin-rättigheter, skapar ett nytt konto åt dig med admin-rättigheter och således få tillgång till hela burken...

Möjligt, men nu har ju Microsoft i .NET Framework gett oss möjligheten att ändra rättigheterna i a f. Det verkar mycket troligt att detta kan utnyttjas i skadligt syfte. Ju mer jag tänker på det desto mer inser jag hur kraftfullt det är.

Kanske borde vidare diskutera frågan i Datasäkerhetsforumet?

Medlem sedan feb. 20013 023 inlägg
#7

fredrik skrev:

Vet inte om det här är vad du är ute efter (eller om det ens funkar så...). Men man kan mha av CAS åsidosätta en användares rättigheter när det gäller speciella permissions.
Om en användare tex. inte har rättigheter att ändra i registret kan man köra:

Dim s As New Security.Permissions.RegistryPermission(Security.Permissions.PermissionState.Unrestricted)

'Be om tillåtelse...
s.Assert()

'KÖR KOD MOT REGISTRET HÄR

'Ta tillbaka förfrågan
s.RevertAssert()

För att då ändå få åtkomst. Du hittar fler olika Permissions under "System.Security.Permissions"

Tack jag är en bit på väg.

Dock får jag

Access to the path "C:\val.txt" is denied.

när jag använder följande kod. Testade även att ta bort assert, men det hjälpte inte.

  Private Sub Button1_Click_1(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim f2 As New FileIOPermission(FileIOPermissionAccess.AllAccess, "C:\val.txt")
        f2.Assert()
        File.Copy("C:\apa.txt", "C:\val.txt", True)
    End Sub
Medlem sedan feb. 20013 023 inlägg
#8

Hittade följande förklaring.

Sammanfattning: Det jag vill göra går inte. Windows säkerhet begränsar. Och det kanske är lika bra.

What you're running into here is not the .NET security system, but rather the Windows NT security system. Since .NET lives on top of
Windows Security, you won't get any additional permissions from managed code that you wouldn't be able to get from unmanaged code.
However, you can be restricted further. For instance, a non-administrator on the machine won't be able to write to c:\boot.ini, even if they're granted
FullTrust by the .NET Security System. However, an administrator (who would be able to write to c:\boot.ini in unmanaged code), will not be able
to write to it unless he has the proper FileIOPermissions.
More to your specific problem -- since you're running as an ASP.Net application, you need to make sure that the account the ASP.Net
service is running under has access to the e:\data\mydata.txt file. (By default the account is ASPNET).

Medlem sedan maj 20018 027 inlägg
#9

Phorpher skrev:

clarkbones skrev:

Tja, det är ju endast applikationen, inte användaren som skall ha dessa rättigheter. Bör inte vara någon större fara så länge applikationen är korrekt skriven.

Jag vet att det går att göra, men jag vet inte hur...

Det skulle innebära att man hur enkelt som helst skulle kunna skriva ett program som plockar åt sig admin-rättigheter, skapar ett nytt konto åt dig med admin-rättigheter och således få tillgång till hela burken...

Det beror nog på hur utförandet av systemet är. I unix kan man köra program som suid root under förutsättning att programmet ägs av root, och att en så kallad s-bit är satt. Såvitt jag vet kan bara root sätta s-biten så att andra kan köra programmet som suid root. Visst kan det öppna för säkerhetsrisker om man inte tänker sig för, men det är inte så enkelt som att bara programmera ihop något själv och stoppa in på en dator som man inte har root-privilegier på. Är man försiktig med hur man använder den finessen, uppnår man fördelen att användare faktiskt kan tillåtas göra vissa saker som egentligen kräver root-privilegier, helt utan att själva logga in som root. Det kan ju faktiskt vara en fördel för säkerheten att låta dem få göra enbart vissa saker som man har kontroll över, istället för att de tillfälligt kan göra vad som helst.

Medlem sedan juni 20014 290 inlägg
#10

UlfT skrev:

Det beror nog på hur utförandet av systemet är. I unix kan man köra program som suid root under förutsättning att programmet ägs av root, och att en så kallad s-bit är satt. Såvitt jag vet kan bara root sätta s-biten så att andra kan köra programmet som suid root. Visst kan det öppna för säkerhetsrisker om man inte tänker sig för, men det är inte så enkelt som att bara programmera ihop något själv och stoppa in på en dator som man inte har root-privilegier på. Är man försiktig med hur man använder den finessen, uppnår man fördelen att användare faktiskt kan tillåtas göra vissa saker som egentligen kräver root-privilegier, helt utan att själva logga in som root. Det kan ju faktiskt vara en fördel för säkerheten att låta dem få göra enbart vissa saker som man har kontroll över, istället för att de tillfälligt kan göra vad som helst.

Det är riktigt att SUID fungerar så MEN det är en stor säkerhetsrisk med SUID'ade program.

Ett enkelt exempel, säg att du kör ett program som SUID till root och det programmet tillåter att man startar andra program (ex. ett shell) då kär man det programmet också som root!

Så skall man ha ett så säkert system som möjligt så skall man ha så få SUID program som möjligt!

303 ms totalt · 4 externa anrop · v20260731065814-full.86ec41c2
163 ms — deklarationer (db)
0 ms — hämta statistik (cache)
137 ms — hämta tråd, inlägg och bilagor (db)
160 ms — ändringar (db)