Uneingeschränkte Toleranz führt mit Notwendigkeit zum Verschwinden der Toleranz. Denn wenn wir die uneingeschränkte Toleranz sogar auf die Intoleranten ausdehnen, wenn wir nicht bereit sind, eine tolerante Gesellschaftsordnung gegen die Angriffe der Intoleranz zu verteidigen, dann werden die Toleranten vernichtet werden und die Toleranz mit ihnen.

Karl Popper im Jahre 1945

Wir schreiben nun das ausgehende Jahr 2018, und haben MHO ein masssieves Problem mit Obigem, andereseits wurde im Jahr 1935 ein komplett anderes Pradoxon postuliert, schauen wir mal wie tolerant die Quanteninformatik sich heute gibt, eine gänzlich spannende & weite Materie.

J.Prof. Dr. Fred Jendrzejewski, Universität Heidelberg,'How we solve hard problems as quantum researchers', gab eine Einführung in aktuelle Forschungen aus Sicht des Quantenphysikers, und betonte, dass in Deutschland ca. sieben Zentren mit Forschung auf Spitzenniveau damit beschäftigt sind. Ansonsten hat sich wohl sehr viel in die Software und damit Simulation verlagert.
Die IBM :: Problem beschreiben und mit Quantum Computer in 100 Mikrosekunden die Lösung finden. Huch mehr Zeit ist nicht. Heute sind Brechnungen mit bis zu 20 Qubit (max. 31 in der Entwicklung)  mit realer Hardware für jede Personengruppe möglich - die Fa. scheint weiterhin die einzige zu sein, welche Hardware und Software konsequent als Open Source bereitstellt! 
Alle Wissenden betonen, egal ob reine Simulation (Atos - Bull) oder Software + Hardware, mit jeder zukünftigen Hardware 'ncht' beobachten zu können;) Sie sind also in der Lage, alle untoten Zustände Schrödingers Katze ohne Beobachtng mit einer gewissen Fehlerrate analysieren zu können.

Die D-Wave Maschinen wurden nicht wirklich erwähnt, MHO weil nicht Gate basierend - damit nicht wirkliche Quantum Computer. Irgendwie zeigt dies wohl auch deren inflationäre Anzahl an qubits um ein qubit zu simulieren..

Andererseits sucht man nach der universellen Quantum Maschine, dem auch als Wolperdinger bekanntem Wesen.

qubit_eshelter.jpg

https://m.heise.de/developer/artikel/Verwundbarkeitsanalyse-anhand-von-CPE-Dictionary-und-CVE-Feeds-4188341.html

Angeregt durch diesen Artikel möchte ich auf ein Problem in MS SharePoint (SP) Farm Solution Erweiterungen (full trust code) eingehen, welche heute durchaus noch am Markt vertreten sind, Probleme möglicherweise weiter in sich tragen, so dass der Trust nicht gerechtfertigt sein könnte. Diese Art der SP Erweiterung ist on premise auch weiterhin von MS SP voll unterstützt.

Die Rede ist hier vom sogenannten Double Hop Problem. SP unterstütze standardmäßig das NTLM System für die Benutzerauthentifizierung, aber auch die griechischen Höllenhunde können benutzt werden. Im Gegensatz zu Kerberos unterstützt NTLM keine Delegation mit Tickets.

Was passiert also hier? Ein Benutzer meldet sich per Web Browser am SP an, und kann nun seinen Berechtigungen nach Schalten und Walten. Im Hintergrund sind Services im SP integriert, welche bestimmte Aufgaben auf einem eigenen Host vom Benutzer unbemerkt angestoßen abarbeiten. Host heisst hier, SP Farm Member auf einem eigenen Windows Server OS.

Dh. nach der Anmeldung am System, stellt der annehmende Service fest, daß der angeforderte Service auf einer anderen Member Maschine gehosted wird. Somit wird die Anfrage dorthin weitergeleitet, es findet eine Delegation statt, und nur wenn hier Tickets vorhanden sind ist der angesprochene Service in der Lage, die Anfrage einem Benutzer zuzuordnen. Die Standard Services des SP sind nun alle mit einer Abprüfung auf den Benutzer ausgestattet. Somit kann kein unberechtigter Benutzer die Services für seine Zwecke verwenden, in diesem Fall wird ein entsprechender Fehlercode zurückgeben.

Leider ist diese Art der Implementation in Custom SP Services nach meiner Beobachtung nicht zwingend gegeben. Da die Software abwärtskompatibel ausgeliefert wird, aus Performance Gründen auf einen eigenen Member Host gesetzt wird, tritt das Problem selbst dann auf, wenn dieser sich selber per SP URI anspricht. In der mir bekannten Implementation wird hier bei unbekanntem Benutzer schon mal im SP auf System impersoniert, um dann weiter zu prozessieren.

Solange alles ohne unlautere Absichten im SP Kontext abläuft tut das System seinen Dienst.

Nur sind die SP Webservice Endpunkte per se offen für den anonymen Zugriff, um eine kontraktgemäße Schnittstellenbeschreibung zu liefern und die Kommunikation auszuhandeln. Somit sind hier bei Kenntnis der Datenlage beliebige Manipulationen des gesamten SP && PM Systems denkbar.

Die in der Anfangszeit 2007/2010 implementierte Lösung hat sich an dieser Stelle spätestens mit  den Versionen 2013/2016/2019 keinen Gefallen getan. Zusätzlich zu der verwendeten late binding activeX Technologie der domainspezifischen Lösung wurden mehrere PR Anfragen mit Unverständnis für die Problemsachlage abgewiesen.

Das sogenannte SP Farm Solution Model birgt also nicht nur die Stabilität von SP beeinflussendem InProcess Ablaufschema in sich, auch Sicherheitsanforderungen müssen nicht mehr mit der Papierform des eigentlichen SP Produktes übereinstimmen.

Was bleibt als Fazit?

Ideal sind also SP Systeme, welche on premise like SPonline betrieben werden. Dh. sie sind immer auf dem aktuellen Security Patch Level, Erweiterungen und Webparts basieren auf dem SPFx und gehosteten csom apps. Sehnlicher Wunsch wäre eine in place Migration-Möglichkeit von Version zu nachfolgender Version. Aber leider ist dieses Ideal häufig nur Wunschdenken, aber träumen kann ja nicht verboten werden!