Fehler. Der Client besitzt ein erforderliches Recht nicht

[Jörg Wegener]

Hallo alle,<br>
ich wollte aus meiner ASP.NET Anwendung auf das EventLog von Windows 2000 zugreifen. Mit der letzten Beta-Version hat das noch funktioniert. Nun erhalte ich die Fehlermeldung, dass dem Client ein erforderliches Recht fehlt. Kann ich dies irgendwo eintragen oder den Client authorisieren?

Immerhin ist ja gut, dass nicht jeder auf das EventLog zugreifen darf. Aber ich bin doch der Admin!

Vielen Dank im voraus,

Jörg

[Andreas Kosch]

Hallo,

&gt;Aber ich bin doch der Admin!

das spielt unter .NET keine Rolle mehr. Im Gegensatz zu NT/2000/XP spielt der Benutzer nicht mehr die erste Geige, sondern über die <i>Application Domains</i> kann eine Anwendung intern aus verschiedenen Sicherheitszonen mit unterschiedlichen Rechten bestehen. Wenn man zum Beispiel den Aufruf von <b>AppDomain.CurrentDomain.SetAppDomainPolicy(Noth ing)</b> im Sourcecode unterbringt, darf die eigene Anwendung (trotz Admin-Konto) fast gar nichts mehr :-)

Mit dem folgenden Beispiel kann ich aus der ASP.NET-Anwendung heraus erfolgreich auf das EventLog zugreifen, indem ich über <b>PermissionSetAttribute</b> eigene Regeln anfordere:
<pre>
Imports System.Web.Services
Imports System.Security.Policy
Imports System.Security.Permissions
' Security-Attribute auf Assembly level
<Assembly: PermissionSetAttribute(SecurityAction.RequestMinim um, Name:="FullTrust")>


Namespace OssiSoftTechDoc
<WebService(Namespace:="http://OssiSoft.local/")> _
Public Class OSWSTechDocDBService
Inherits System.Web.Services.WebService

Public Function Version() As Integer
Version = 1
End Function

Public Function LogAction(ByVal sInfo As String) As String
Try
EventLog1.WriteEntry("LogAction", "Daten: " & sInfo)
PerformanceCounter1.IncrementBy(1)
Return "Ok"
Catch aError As Exception
Return aError.Message
End Try
End Function

Public Function GetCustomers() As DataSet
SqlDataAdapter1.Fill(DataSetCustomer1, "Customers")
Return DataSetCustomer1
End Function

End Class
End Namespace
</pre&gt

[Jörg Wegener]

Hallo Andreas,<br>
vielen Dank für die Antwort. Was ist jedoch nicht nachvollziehen kann ist, warum ich mich im Programm selbst dazu berichtigen kann auf das EventLog zugreifen zu können. Ich danke dabei immer an mögliche Fremde, die ihre .NET Sachen auf meinen Server laufen lassen. Wenn die fleissig auf EventLog zugreifen können, fände ich das nicht so witzig. Gibt es eine Möglichkeit nur als Administrator (quasi von Außen) diese <b>AppDomain</b> dazu zu berechtigen?

Außerdem habe ich in der .NETten Dokumentation gelesen, dass es bei <b>AppDomain.CurrentDomain.SetAppDomainPolicy(Noth ing)</b> (s.o.) eine ArgumentNullException geben soll.

Wie man sicherlich nachvollziehen kann, ist das Sicherheits-Thema eine komplexe und wichtige Sache. Gibt es dazu irgendeine gute Resource, Link, Website oder Buch? Momentan ist mit nur ".NET Framework Security" von SAMS bekannt, was aber noch nicht gedruckt ist.

Gruß<br>Jör

[Christoph Rüegg]

Nun, sie können sich nicht selbst Berechtigen, sie können blos Rechte anfragen (und wichtiger: alle anderen unnötigen ablehnen). Die Applikation läuft immer noch unter einem NT Account. Dessen Rechte kann man nicht untergraben.

Mit dem .NET Framework MMC SnapIn kann man bequem die Policies auf Enterprise, Maschinen und Userebene definieren. So könntest du zb. den unspezifizierten Apps der "Fremden" keine Rechte fürs Lesen eines EventLogs zuweisen, bestimmten Applikation (zb. per strongname identifiziert) jedoch schon.

Beim Terrarium Projektchen (gotdotnet.com, MSDN .NET Show) wird das ganze auch zum Thema, da dort jedermann eigene Organismen (eigenen Code) ins System einbringen können, der dann bei allen Clients ausgeführt wird; natürlich nur mit sehr eingeschränkten Rechten

[Andreas Kosch]

Hallo,

&gt;Ich danke dabei immer an mögliche Fremde, die ihre .NET Sachen<br>
&gt;auf meinen Server laufen lassen.

Als Ergänzung sei mir noch die folgende Anmerkung gestattet: Das .NET-Framework ist Dank der CLR in der Lage, zu erkennen, <b>woher</b> ein MSIL-Codeblock stammt, der ausgeführt werden möchte. Daher darf man in seinen Application Domains im Gegensatz zu Java gleich mehrere "Sandkästen" einrichten und dort jeweils eigene Sicherheitsregeln festlegen. Ein heruntergeladener bzw. aus dem Netz stammender Code darf niemals höhere Rechte anforden, als die Application Domain als Begrenzung vorsieht. Daher ist das bisherige Sicherheitsproblem von ActiveX nicht mehr relevant.

&gt;dass es bei AppDomain.CurrentDomain.SetAppDomainPolicy(Nothing ) (s.o.) eine ArgumentNullException geben soll.

Der Aufruf ist bei mir (Visual Studio .NET Enterprise Architect) erfolgreich und die Rechte sind auch tatsächlich danach nicht mehr da.

&gt;Gibt es dazu irgendeine gute Resource, Link, Website oder Buch?

Die Dokumentation des .NET-Frameworks ist mit reichlichen (fast zu reichlichen) Informationen gefüllt. Allerdings habe ich den Eindruck, dass nach dem Einspielen der MSDN-DVD <i>Library January 2002</i> (mit der Zustimmung zum Einbinden in VS.NET) die aus VS.NET aufgerufenen Hilfeseiten deutlich informativer ausfallen. Ich kann also nicht mehr sagen, wie die Hilfe im "nackten" VS.NET in diesem Punkt aussieht.