Linux – Dell U2515H – questions regarding KDE adjustments and older graphics cards

Posted on by

Some months ago I wrote 2 blog articles about the use of (multiple) DELL U2515H screens on a Nvidia GTX750 TI graphics card on a Linux system.

Linux – Nvidia GTX 750 TI – Parallelbetrieb von 2 Dell U2515H mit 2560×1440 plus einem 1920×1200 Schirm
Linux – Nvidia GTX 750 TI – Dell U2515H – HDMI – 2560×1440 Pixel

Last week a reader, who had found these blog articles, asked me the following:

I am currently using a Dell U2412m with 1920×1200 resolution but I am planning to upgrade to a 2560×1440 and thought about the U2515H but I am a bit worried about how Plasma shows on such a high dpi panel. Do you have any issue with interface elements which are showed too small and are not tuneable?

Second thing I am a bit worried of my GTS 450 performance but I will upgrade my video card after the new nVidia series is launched.

I found these questions interesting and present my answers in form of this blog contribution.

Warning statement regarding older graphics cards

Before I get to the question regarding KDE and a high resolution screen as the DELL U2515H I want to make a warning statement:

The graphics card you want to use together with a Dell U2515H and the graphics card drivers MUST support high resolution HDMI (vers. 1.4, 2.0) or display port connections. Reason: The Dell U2515 does NOT provide any DVI connections!

Do not underestimate this topic for older graphics cards! Actually, I had very bad experiences in the past with a GTX 460 which provides a mini HDMI port: I never got a high resolution HDMI connection to run with this card (not under Opensuse 13.1/13.2). Despite high quality cables and in contrast to another system with a GTX 750 TI. And I really tried a lot of settings and driver versions until I gave up.

And note: Even the GTX 750TI required some effort and fiddling – but eventually it worked. This is the reason why I wrote about it.

So, if you have some money and want to avoid frustration with the DELL U2515H, I would suggest to buy a reasonable modern card which offers support for (several) display ports and/or high resolution HDMI. If gaming under Linux is not a topic (as in my case) but still some 3D applications or CUDA floating point operations are part of your work then presently a GTX 960 or the GTX 750 could be a reasonable alternative regarding the price-value relation. But look out for the number of ports supported – especially if you want to use several screens.

KDE and high resolution screens in general

It is quite clear that a screen resolution of 2560×1440 will significantly reduce the visible size of fonts and desktop elements scaled with font size. So, what you need is a very flexible scalability of fonts both for the desktop and window control elements as well as for applications you use.

The question whether Linux desktops as KDE are prepared for high resolution screens was also posed in an article with the title “Skaliert” (Scaled) published in the German “linuxuser” 10/2015. See http://www.linux-community.de/Internal/Artikel/Print-Artikel/LinuxUser/2015/10/Skaliert. Unfortunately, this article costs money to read it online. Actually, relatively small problems were described for KDE. This is very consistent with my own experience with both KDE 4.14 and KDE 5.x.

You can adjust almost all required basic font settings for the KDE desktop via KDE’s “systemsettings” and in addition most
applications offer scrollable and relatively seamless font scaling (e.g. via mouse scrolling). Playing around with font smoothing plus an enforcement of dpi resolution may pay off in case you care for smooth font displaying. (Actually I never had to apply any special contrast settings of the screen itself beyond standards for the screen to get a clear, but nevertheless smooth font display).

The spectrum of applications I primarily use consists of a mixture of QT and GTK applications:

KDE konsole and other terminal emulations, different types of graphical KDE file editors, different types of browsers (primarily FF and chromium), libreoffice, eclipse mars, aptana studio, SVN frontends, crossover with ms office applications, vmware with different types of guests, kvm with different types of guests, sound and multimedia applications, blender, etc., etc.

Almost all of my favorite applications offer internal font adjustment capabilities and the typical graphical elements of these applications scale seamlessly with font size. So, no reason to worry about KDE and its plasma desktop: In my opinion KDE is well prepared for high resolution screens.

A problem may, however, be the smooth integration of some GTK applications (as e.g. eclipse) into high resolution KDE, which is based on QT – but also there you have sufficient options with different GTK themes – and most of the problems I had were independent of the screen resolution and more GTK theme dependent. You may have to play around a bit with KDE’s settings for GTK integration – especially with the choice of the GTK design or GTK theme.

KDE and screens with different resolutions

A real problem in my opinion may result from a mixture of 2 screens with different (!) native resolutions. There is no way known to me to apply different font-settings to different screens on a KDE desktop comprising several screens in form of a Nvidia Xinerama combination.

As long as I used 2 screens – one with a resolution of 1920×1200 and one with 2560×1440 – I really suffered a bit from the display discrepancies regarding font size. Especially when I wanted to open several windows of one and the same application – as 2 windows of Eclipse – on both screens or whenever I wanted to stretch one application (e.g. VMware) over the 2 screens. You may try to find compromises – but it will never be perfect.

However, in my present daily work with 3 screens – 2 with 2560×1440 and 1 with 1920×1200 – the different display of font sizes may become even an advantage: Just by moving an application to the lower resolution screen you get a better view on details. (But I admit, this is pure luxury, not only for development work.)

Nevertheless it would be fun if KDE in the future could provide a possibility to adjust font-sizes per screen in a Xinerama version.

Performance?

I do not know exactly how a GTS 450 graphics card performs. But my guess is that even for 2 screens (with 2560×1440) performance for the simple 3D effects of a plasma desktop should be no topic at all – even for this card. Actually, it is really frustrating that you cannot use high resolution HDMI with older graphics cards – despite the fact that the graphics card may support a combined resolution of 2 x 2560×1440 for DVI capable screens and provide a sufficient performance for it.

I should, however, mention that for three screens (2 x 2560×1440, 1x 1920×1200) my GTX 750 TI works constantly with high frequencies of both CPU and memory. The card never reduces this frequencies during normal use – so it will consume more electrical power than in a 2 screen situation. For 2 screens at 2560×1440 it always reduced frequencies to lower levels when only 2D applications were used on the desktop. However, despite constant high frequencies I never noticed any heat problem under normal conditions. The ventilators operate at basic speed and temperatures are between 36 and 40 &
deg; Celsius.

With high resolution 3D games you may have a different experience – but if I play (which is seldom) I never play with extreme resolutions. So, actually I do not know how high resolution games perform on a (3D) KDE desktop.

Summary

Regarding the use of KDE with the DELL U2515H in my opinion you need not worry about font scalability and performance. You should worry more about the support of high resolution HDMI and display ports by both the physical card and the drivers for older Nvidia cards. A combination of a DELL U2515H with a screen of lower resolution will lead to problems – as visible font sizes may differ significantly.

Remark, added 17.12.2015:
Meanwhile I had the chance to test a Nvidia GTX 960 from Gigabyte together with 2 DELL U2515H connected via display port and a 1920×1200 screen connected via DVI. Works without any problems. And I see no problems with native Linux 3D OpenGL games as Red Eclipse or Xonotic at high resolutions so far. Temperatures around 43° Celsius.

Motive für eine intensivere Beschäftigung mit KVM-Hosts und Security

Posted on by

Ein Angestellter eines Kunde, bei dem ich mehr in der Rolle des Prozessberaters arbeite, fragte mich vor kurzem, warum ich in letzter Zeit so viel Zeit in das Sicherheitsmanagement von Servern stecke.

Es stimmt: Ich beschäftige mich – im eigenen Netz, aber auch im Auftrag von Kunden – immer wieder mit KVM Hosts und Web- / Datenbank-/ Mail-Servern bzw. MS Windows-Clients in Gastinstanzen. Ein Thema, das mich seit längerem – vielleicht zu Unrecht – beunruhigt, ist die Abschottung von Gastsystemen und virtuellen Netzwerkbereichen hinter (virtuellen Bridges/Switches) gegeneinander.

Mehrere Punkte und Fragen sorgen hier bei mir immer wieder für besagte Unruhe:

  • Sind iptables-Regeln für Paketfilter auf dem Host hinreichend? Sind nicht auch zusätzliche ebtables-Regeln erforderlich?
  • Ist eine Paketfilter auf dem Host und damit für die virtuellen Bridges überhaupt sinnvoll? Oder sollte jeder Netzwerkbereich seine eigene virtuelle Perimeter-Firewall bekommen? Oder beides?
  • Wie können virtuelle Bridges/Switches angegriffen werden? Was ist z.B. mit ARP-Sppofing/-Flooding?
  • Wenn Firewall-Regeln auf dem Host und übergreifend für virtuelle Bridges/Switches: Sind Regeln zu etablierten Verbindungen der Form
    • $IPTABLES -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
    • $IPTABLES -A OUTPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
    • $IPTABLES -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

    ein potentielles Sicherheitsrisiko, da damit ein Bridge-übergreifender Kontext auf dem Host geschaffen wird?

  • Welche Möglichkeiten hat eine Angreifer bei aktiviertem Routing über den Host zwischen 2 virtuellen Netzwerksegmenten?

Zu all diesen Punkten gibt es in diversen einschlägigen Foren Diskussionspunkte. Ich finde, das Spektrum der Fragen ist ein genaueres, eigenes Studium von virtuellen Bridges auf Linux-Hosts wert. Ich werden in kommenden Artikeln immer mal wieder auf diese Fragestellungen und zugehörige Scan- und ggf. Penetrations-Tests und notwendige Verteidigungsmaßnahmen zurückkommen.

Wine/Crossover Office – Positionierung und Größenänderung von KDE-Fenstern für MS Office 2007/2010

Posted on by

Im Rahmen von Beratungsaufträgen für Kunden bin ich immer mal wieder gezwungen, auf Windows Office-Anwendungen zurückzugreifen. Denn leider funktioniert in etlichen Fällen mit komplexeren Dokumenten oder Präsentationen der Weg

LibreOffice => Zip-File/Mail => MS Office => Zip-File/Mail => LibreOffice => Zip-File/Mail => MS Office

nicht völlig verwerfungsfrei.

Um Kundenbeschwerden aus dem Weg zu gehen, nutze ich deshalb – wenn erforderlich – MS Office 2010 Applikationen unmittelbar über Wine (in Form von Crossover Office) auf meinem Linux/KDE-Desktop. Nun habe ich mir kürzlich einen neuen Laptop zugelegt; zwangsläufig musste ich meine komplette SW-Umgebung vom Altsystem um- und nachziehen. Dabei stößt man dann im Zuge der Wine-, der Crossover Office- und der nachfolgenden MS Office-Installation unter einer passenden “Wine-Bottle” als MS-Laufzeit-Umgebung (oder nach einem Bottle-Ex/Import) zwangsläufig auf folgendes Thema:

Die KDE-Fenster für die Wine basierten MS Office-Applikationen lassen sich nach einer einmal durchgeführten Full-Screen-Maximierung nicht mehr wie andere Standardfenster mit der Maus über einen Drag-Vorgang mit der Maus auf der Menüleiste bewegen. Ferner funktionieren danach freie Größenänderungen des Fensters mit der Maus nicht mehr. Man kann nur zwischen maximaler Größe und einem vordefinierten Größen-Format hin und her schalten.

Das ganze Problem hatte ich früher schon mal durchlitten – und schließlich über KDE-Einstellungen gelöst – nur leider vergessen wie. Ärgerlich! Die Zeit zum Rumprobieren kann man sich beim nächsten Mal wirklich sparen. Deshalb hier eine Zusammenstellung der erforderlichen Schritte.

Einstellungen für die betroffene Wine/Crossover Bottle (“Flasche”) der Windows-Applikation

Hierzu das zentrale “CrossOver” Verwaltungsapplikation öffnen (im Terminal nach einer Standardinstallation z.B. über den Aufruf von “/opt/cxoffice/bin/crossover”).

Dort den Menüpunkt “Werkzeuge >> Flaschen verwalten” wählen. Die jeweilige “Flasche” für die Windows-Office-Installation im linken Seitenbereich auswählen, rechts den Tab “Systemsteuerung” wählen und darunter den Punkt “Wine Konfiguration” anklicken.

Im sich öffnenden Konfigurationsfenster den Reiter “Grafik” anklicken. Dort folgende Optionen auswählen:

  • Erlaube dem Fenstermanager die Fenster zu dekorieren
  • Erlaube dem Fenstermanager die Fenster zu kontrollieren

bottle1

Diese Einstellungen dienen dazu, dass der Window-Manager (ob unter Windows oder nicht) – zumindest grundsätzlich – die Kontrolle über die Applikationsfenster zu bekommt.

Wenn man bei einem Umzug auf ein anderes System die Export/Import-Funktionalität für Wine-Bottles nutzt, sollten diese Einstellungen auf dem neuen System bereits gegeben sein – soweit man sie auf dem Altsystem schon vorgenommen hatte.

Sonderregeln für KDE-Fenster-Einstellungen

Nun müssen wir noch die andere Seite – nämlich die des Window-Managers unter KDE betrachten. Hierzu die KDE Systemeinstellungen öffnen (im Terminal über das Kommando: systemsettings &).

Dort unter der Rubrik “Erscheinungsbild und Verhalten der Arbeitsfläche”
den Punkt “Fensterverhalten” anklicken. Im sich öffnenden Fenster “Fensterregeln” wählen. Dann den Button “Neu” klicken.

Wir landen im Reiter “Fensterübereinstimmung” eines sich neu öffnenden Dialogfensters.
Das Feld “Beschreibung” füllen wir mit Stichwörtern unserer Wahl (“MS Office 10 Regeln”). Nun ein Klick auf Button “Fenstereigenschaften ermitteln”. Dies hilft uns, Informationen dazu zu erhalten, unter welcher sog. Fensterklasse KDE die wine-basierten MS Office-Applikationen eigentlich führt. Klickt man mit dem angebotenen Kreuz-Cursor nun auf ein geöffnetes Crossover Fenster für Winword, so öffnet sich ein Fensterchen, in dem man bzgl. der sog. “Klasse” den Ausdruck “Wine (WINWORD.EXE Wine)” vorfindet.

Nach dieser Information klicken wir im Informationsfensterchen auf “Abbrechen” und landen wieder im Dialog zur “Fensterübereinstimmmung”.

bottle2

Bei der Combobox zum Punkt “Fensterklasse” nun den Punkt “Regulärer Ausdruck” wählen. Wir müssen einen Regex-Ausdruck festlegen, der die Fensterklassen, die KDE (bzw. X-Windows) den betroffenen Crossover-Fenstern zuordnet, am besten erfasst. In Anlehnung an die oben bereits ermittelte Information, die wir auf Excel und Powerpoint erweitern wollen, nehme ich 

.*\b(winword.exe|excel.exe|powerpnt.exe)\b.*

Bzgl. evtl. Sorgen bzgl. einer Groß-/Kleinschreibungs-Thematik siehe den letzten Kommentar unter https://bugs.kde.org/show_bug.cgi?id=173544. Wer dem Regex wegen der Großschreibung z.B. der MS Office 2010-EXE-Dateien dennoch nicht traut, kann ja versuchsweise “i”-Modifikatoren einsetzen, wird aber feststellen, dass das i.d.R. Fehler nach sich zieht. Zusätzlich ist ein Haken beim Feld “Übereinstimmung mit gesamter Fensterklasse” erforderlich.

Wichtige Ergänzung 20.11.2015:

Speziell im Falle von Powerpoint gibt es mit den bisherigen und den nachfolgenden Einstellungen Probleme, da auch kleine Grafiken bei Verschiebungen und Größenänderungen zur Erzeugung kleiner Fenster führen, die z.B. die Verschiebung während der Mausaktion anzeigen. Man muss daher die Anwendung der nachfolgenden Regeln von vornherein weiter auf die Hauptfenster einschränken. Ein wenig Experimentieren führte mich dann zu folgender Lösung: Für das Feld “Fenstertitel” wählt man erneut “regulärer Ausdruck” und

.*\b(.*)\b.*

crossover_5_800

Nicht besonders elegant- aber wirksam. (Sicher gibt es bessere Lösungen, aber ich komme grad nicht drauf.)

Nun weiter zum Reiter “Größe und Position”. Wir wollen verhindern, dass der Fenstertyp sich beim erneuten Öffnen an eine evtl. vorgenommene Maximierung erinnert und dass wir auf eine bestimmte Geometrie festgelegt werden. Deshalb sind folgende Einstellungen erforderlich:

  • Vollbild => Erzwingen => Nein
  • Angeforderte Geometrie ignorieren => Erzwingen => Ja

bottle3

Wir bestätigen diese Einstellungen durch OK. Nach dem Schließen der Dialogfenster zu den konkreten Einstellungen aktivieren wir die geänderten Einstellungen noch über den Button “Anwenden”.

Danach verhalten sich die Crossover Fenster für MS Office Applikationen unter KDE
wie normale Fenster nativer Linux-Applikationen. Falls nicht: Einmal abmelden und dann wieder in den KDE-Desktop einloggen.

beispiel1_red

Alternative Fensterhandhabung

Ein “Alt-Klick” auf ein Fenster ermöglicht grundsätzlich dessen Verschiebung auf dem Desktop. Das gilt auch für Crossover-Fenster. Das Gleiche erreicht man über einen Klick mit der rechten Maustaste auf das Fenstersymbol zu unserem Crossover-MS-Office-Fenster in der KDE Fensterleiste und eine nachfolgende Wahl des Punktes “Weitere Aktionen” im sich öffnenden Menü. Dies führt uns zu einer Auswahl von Fensteroperationen, die sich auf diesem Wege auch für Crossover Fenster ausführen lassen. Eine dieser Fensteroperationen ist auch die Größenänderung.

Links

https://www.codeweavers.com/compatibility/crossover/forum/microsoft-office-2010?msg=157908
https://bugs.kde.org/show_bug.cgi?id=329227
http://www.linuxforen.de/forums/showthread.php?230623-Wine-Fenster-l%E4sst-sich-nicht-verschieben-und-ist-immer-im-Vordergrund
https://forum.winehq.org/viewtopic.php?f=8&t=20006

Viel Spaß dann noch mit Wine und Crossover Office! Dass man mit MS Office Spaß haben wird, ist bei den Lesern eines Linux-Blogs kaum zu erwarten. Seit MS Office 2007 frage ich mich persönlich immer wieder, welcher Wahnsinnige sich wohl die aus meiner Sicht chaotische und den Arbeitsfluss nicht fördernde, sondern eher behindernde Benutzerführung ausgedacht hat … Na ja, eingefleischte MS Fans können das sicher erklären. Ich bin jedenfalls froh, dass es ein inzwischen relativ ausgereiftes LibreOffice gibt und mir das Leben leichter macht.

Datenschutz-Einwilligung – Google’s wachsender Druck auf Nutzer der Suchmaschine – wie erwartet …

Posted on by

Hatte ich doch noch vor ein paar Tagen in diesem Blog darüber spekuliert, dass das EuGH-Urteil nicht ohne Folgen bleiben wird und es auch den deutschen Datenschutzbestimmungen ein breite Bresche schlägt. Siehe
https://linux-blog.anracom.com/2015/10/13/eugh-urteil-zu-safe-harbour-und-die-reaktion-der-vordenker-zeitschrift-die-zeit/

Und was passiert: Eine wachsende Anzahl deutsche Nutzer der Google Suchmaschine erhalten nun – mit oder ohne Google-Konto – regelmäßig und mit verschärfter Tonlage eine Einblendung, über die der Anwender dem Unternehmen Google quasi eine Zustimmung zum Datensammeln erteilen muss, wenn er die Google Dienste – in diesem Fall die Suchmaschine – weiter nutzen will. Zuletzt hat der Stern darüber berichtet; siehe
http://www.stern.de/tv/google-datenschutzeinstellung–hinweise-zum-pop-up-6512842.html#mg-1_1445528506974
Dieses in die Suchmaschinenseiten eingebettete, relativ groß dimensionierte “Pop-Up” bietet keine Möglichkeit, das Verlangen von Google abzulehnen.

Das eigentlich Erschreckende – wenn auch kaum Neue – ist, dass Einem beim genauen Lesen der weiteren Dialoge (speziell beim Durcharbeiten der “Optionen”) das erklärte Ziel der Zustimmung sehr klar vor Augen geführt wird – nämlich die Erlaubnis nicht nur zur Erfassung sondern auch zur Zusammenführung letztlich personenbezogener Daten auf allen Ebenen. In diesem Zusammenhang von Daten-“Schutz” zu reden würde selbst Herrn Orwell wundern. Nun, damit ist wenigstens für Klarheit gesorgt. Verwunderlich ist das nicht – mit Persönlichkeitsprofilen und Werbung verdient Google ja schließlich sein Geld.

Google erlaubt einem dann netterweise noch einen Streifzug durch diverse browser- und dienste-bezogenen Einstellungen. Man kann zwar einige Einstellungen ändern – aber die schränken Werbung und das dafür erforderliche Datensammeln lediglich etwas ein – beendet wird das Erheben von Daten zur eigenen Person und zum Verhalten bei der Suche mit Google dadurch keinesfalls. Auch die Werbung wird nicht komplett unterbunden. Das wird fairerweise auch gesagt. Konsequenterweise bietet Google’s aktuelle Popup-Meldung auf den Seiten der Suchmaschine auch keine Option zum pauschalen Ablehnen des Erfassens und Zusammenführens meiner personenbezogenen Daten an. Das ist eine klare und deutliche Botschaft: Gib mir deine Daten oder nutze meinen Dienst nicht!

Ich finde das keineswegs verwerflich. Nur außerordentlich überdenkenswert – und mit hohem Druck auf den Anwender unterlegt. Nicht verwerflich heißt für mich dabei noch lange nicht gut. Google will angesichts der rechtlich verschärften Lage vom (deutschen?) Nutzer nun offenbar eine explizite Zustimmung erzwingen und damit Rechtssicherheit für das eigene Unternehmen schaffen. Wir haben es hier mit einem, nicht mehr ganz neuen Phänomen, das ich “Erzwingungs-Popup” nennen möchte, zu tun. Einer Art Eula für die Suchmaschine …

Noch – wohlgemerkt noch (!) – ist die Lage aber nicht ganz hoffnungslos. Wenn man als Nutzer von Google das Sammeln von Daten zum eigenen Persönlichkeits- und Verhaltensmuster auch nicht nicht mehr implizit oder pauschal ablehnen kann, so kann man es wenigstens teilweise umgehen – wenn auch vermutlich nur für einige Zeit. Auf das Wie komme ich weiter unten zurück.

Ist das Ganze eigentlich überraschend? Habe ich eigentlich etwas anderes erwartet? Nein! Schließlich stellen die zunehmend präzisierten deutsche Datenschutzanforderungen, das EuGH-Urteil und auch ein insgesamt vermehrtes Bewusstsein für Privatsphäre und informationelle Selbstbestimmung zumindest in Deutschland die aktuellen Geschäftsmodelle nicht nur von Google, sondern diverser Internet-Giganten grundlegend in Frage. Das provoziert Reaktionen und
führt fast zwangsläufig zu diesen Methoden.

Das hat auch sein Gutes – denn die Interessengegensätze zwischen Geldverdienen mit Persönlichkeitsprofilen und den Anforderungen nach informationeller Selbstbestimmung in einer Demokratie treten so klarer zu Tage. Das kann der Diskussion nur dienlich sein. Zudem sollte jedem Nutzer hierzulande bewusst werden, wie abhängig wir uns von den durchaus nützlichen Diensten der US-Internet und IT-Giganten gemacht haben – ohne regelmäßig zu bedenken, dass es im Internet nichts umsonst gibt. Wir bezahlen so oder so – mit Geld oder Daten zu unserer Persönlichkeit, unseren Gewohnheiten und Interessen. Das ist eine nüchterne Feststellung – die Kritik richtet sich hier in erster Linie an die eigenen Versäumnisse und nicht dagegen, dass Google klar definierte Geschäftsinteressen verfolgt. Das ist aus meiner Sicht zumindest im Rahmen geltender Gesetze völlig legitim.

Was kann man aktuell tun?
Zähneknirschend zustimmen mag für viele eine Option sein. Bei mir ist es zunächst so, dass ich mich ungern zu solchen weitreichenden Entscheidungen über eine Meldung auf einer Webseite erpressen lasse. Freiheit der Meinungsbildung und auch der Entscheidung ist mir konservativem Menschen eben wichtig. Meinungsbildung erfordert zudem Zeit – und nicht einen spontanen Klick mit der Maus. Nun kann man durchaus etwas auf Zeit spielen – und sei es nur deswegen, um sich die Sache nochmal gründlich durch den Kopf gehen zu lassen:

  1. Im Google-Erzwingungs-Popup bzw. in der Googlemeldung zunächst und so lange es möglich ist auf “Später lesen” klicken.
  2. Google wird sich nach einiger Zeit wieder melden und dem Nutzer im Ton und Layout der Meldung keine Wahl mehr lassen, als sich mit dem Thema intensiver zu beschäftigen.
  3. Dann erst mal die “Optionen” wahrnehmen und den folgenden, durchaus interessanten Spaziergang durch die Einstellmöglichkeiten mitmachen. Dabei das Maximale im Sinne der Privatsphäre herausholen.
  4. Dann eben nicht einfach zustimmen – es sei denn man will es wirklich. Sondern die geöffnete Webseite mit der Google-Suche schlicht schließen.
  5. Alle Cookies oder speziell die Cookies von Google löschen. (Und soweit möglich, über seinen Router vom Internet-Provider mal häufiger eine neue IP anfordern.)
  6. Firefox im Bereich “Privatsphäre” so einstellen, dass er alle Cookies beim Beenden des Browsers automatisch löscht. Für andere Browser bzw. eine ältere FF-Version analoge Einstellmöglichkeiten ausfindig machen.

Das wirkt erstmal, weil der Mechanismus hinter dem Erzwingungs-Popup z.Z. offenbar noch cookie-basiert ist. Leider verfügt Google natürlich noch über andere Mittel, eine konkrete Person bei der Nutzung der Suchmaschine zu identifizieren. Das Ganze wird also nur eine vorübergehende Lösung sein. Da ich nicht wirklich damit rechne, dass Google ein Einsehen zeigen wird, bleibt danach vermutlich nur,

  • konsequent den “Tor”-Browser zu nutzen,
  • Suchen bei Google über die Seite https://search.disconnect.me/ durchzuführen (bis Google das auch nicht mehr zulässt),
  • schlicht die Suchmaschine zu wechseln (bis auch die anderen IT-Konzerne über ähnliche Erzwingungsmethoden die Zustimmung des Nutzers zum Datensammeln erzwingen). Z.Z. lohnt sich zudem ein Blick auf Meta-Suchmaschinen wie “startpage.com” oder “https://www.ixquick.com/deu/”.

oder eben doch entnervt zuzustimmen. Man hat – egal wie – aber letztlich nur die Möglichkeit des Versuchs einer anonymisierten Dienste-Nutzung! Um die Dienste selbst kommt man kaum herum. Und schmerzlichst wird einem wieder bewusst: Leider haben wir Europäer bislang kein
qualitativ gleichwertiges Äquivalent zu Google. Ich finde zudem: den ungehinderten Zugang zu Informationen im Internet bei Wahrung der Persönlichkeitsrechte und des Datenschutzes zu gewährleisten, ist zudem eine Hauptaufgabe eines modernen, demokratischen Staates. Ich halte es für eine Mär, dass dies mit polizeilichen Schutzaufgaben nur schwer vereinbar sei.

Liebes Unternehmen Google! Ihr habt in eurem Kerngeschäft großartige Arbeit geleistet und bietet viele nützliche und wichtige Dienste an – das steht außer Zweifel. Die Suche nach und der Zugang zu Informationen im Internet ist ein wichtiges Gut, für das ihr mit den Boden bereitet habt. Ich glaube euch sogar, dass Ihr jetzt bzgl. Datenschutz noch was lernen und vielleicht auch umsetzen wollt – solange es eure Einnahmen nicht substanziell gefährdet. Aber Datenschutz fängt mit begründetem (!) Vertrauen und nicht mit Zwangsmaßnahmen an. Das müsst ihr offenbar als Allererstes lernen …. Meines jedenfalls habt ihr heute mal wieder erschüttert. So sehr ich eure Dienste auch schätze …. Offen bleibt zudem die Frage, wie denn das Vorgehen eigentlich mit dem EuGH-Urteil in Einklang zu bringen ist. Denn es gibt ernstzunehmende Interpretationen, die genau euer Vorgehen in Frage stellen:
http://www.faz.net/aktuell/wirtschaft/maechtige-internetriesen/uld-schlewigholstein-haelt-safe-harbor-fuer-nicht-umgehbar-13858360.html

Was ist eigentlich mit der Idee, dass ihr Geld für eure Dienste verlangt und im Gegenzug zahlenden Kunden garantiert, dass das Suchverhalten nicht nachverfolgt wird, keine user-bezogenen Daten erhoben werden und dass der Suchdienst primär über europäische Server läuft? Das wäre wenigstens ein klares, offenes und ehrliches Geschäftsmodell. Wie ich euch kenne, arbeitet ihr daran bereits … Und eine teilweise Kostenübernahme für bedürftige und finanziell Schwache wäre dann Gegenstand einer politischen Diskussion zur Verbesserung unseres Sozialsystems. Auch das kann der laufenden Auseinandersetzung um Datenschutz und informationelle Selbstbestimmung als Grundpfeiler einer modernen Demokratie nur dienen.

Links
https://www.datenschutzbeauftragter-info.de/google-verlangt-einwilligung-ich-stimme-zu/
https://www.verbraucherzentrale.de/google-datenschutz
http://www.stern.de/tv/google-datenschutzeinstellung–hinweise-zum-pop-up-6512842.html#mg-1_1445528506974
http://www.netz-trends.de/id/4353/Verstoesst-Google-mit-seinen-Datenschutz-Einblendungen-gegen-deutsches-und-EU-Recht/
http://www.googlewatchblog.de/2015/07/google-zeigt-hinweise-zum-datenschutz-bei-google/comment-page-1/#comment-141396
http://www.handelsblatt.com/my/unternehmen/it-medien/zugestaendnisse-beim-datenschutz-google-will-erwachsen-werden/12471656.html?ticket=ST-5951533-pfjOxbEXcfbs1bCsfajP-s02lcgiacc01.vhb.de
http://www.welt.de/wirtschaft/webwelt/article141754265/So-aendern-Sie-was-Google-ueber-Sie-speichern-darf.html
http://www.datenschutzbeauftragter-online.de/google-und-datenschutz/
http://www.deutschlandfunk.de/datenschutz-google-zwischen-transparenz-und-augenwischerei.735.de.html?dram:article_id=326641

Erste Erfahrungen mit Kali Linux 2.0 unter KVM/qemu auf einem Opensuse 13.2 Host

Posted on by

Ich muss mich in näherer Zukunft aus beruflichen Gründen stärker mit Penetration-Testing und IT-Forensic beschäftigen. Um bestimmte Szenarien nachzustellen, bedarf es einer virtuellen Übungsumgebung. Dabei liegt es u.a. nahe, Kali 2.0 auf einem virtualisierten Gastsystems zu nutzen.

Die von mir inzwischen bevorzugte Virtualisierungsumgebung für Linux-Gastsysteme auf einem Virtualisierungshost ist KVM/qemu mit virt-manager/libvirt als Frontend-Gespann. Da ich vorab von etlichen Problemen zu zu Kali 1.0, aber auch Kali 2.0 in normalen und virtuellen Umgebungen gelesen hatte, war ich etwas gespannt, was auf einem Opensuse-13.2-Host im Zuge einer KVM-Installation von Kali 2.0 alles an Ungemach auf mich zukommen würde.

Ich kann nach nunmehr ein paar Wochen Benutzung zusammenfassend nur sagen: Es gibt praktisch keine ernsthaften Probleme.

Die Installation über ein ISO-Image läuft auf Opensuse 13.2-Plattformen mit i7-Prozessor, SSD, Nvidia-Graka (mit propr. Treiber) bzw. Laptop mit Optimus-Grafik problemfrei. Ich habe inzwischen mehrere Installationen auf verschiedenen Systemen (PC, Laptops mit Optimus) mit Hilfe von “virt-manager” durchgeführt, ohne mich mit etwas Gravierendem auseinandersetzen zu müssen. (Virtualisierungsprofis werden natürlich eher auf XML-Konfigurationsdateien oder explizite Kommandos/Scripts zurückgreifen. Das ist aber sekundär.) Wichtig ist, dass der Host aktualisiert ist und die KVM-Virtualisierungsumgebung vorab auf Funktionstüchtigkeit getestet wurde.

kali_install_800

Ich erlaube mir, im Vorgriff auf weitere Artikel an dieser Stelle ein paar hoffentlich hilfreiche Hinweise zu geben:

  • RPM-Pakete zu KVM, libvirt/virt-manager:
    Ich habe die KVM/qemu/libvirt-Pakete der Opensuse 13.2-Standard-Repositories und nicht die brandaktuellen Pakete des Opensuse-libvirt-Repositories verwendet.
  • Video-Konfiguration des Gastsystems:
    Man wähle bei der Konfiguration des Gastes in jedem Fall ein Spice-Display mit einem virtuellem Video-Interface “Video QXL”. Für virtuelle Platten nehme man “debianwheezy.qcow2”-Devices mit virtio-Treiber. Auch die virtuellen NICs sollten mit virtio-Treibern unterfüttert werden.
  • Änderung virtuelle Bildschirmgröße:
    Änderungen der virtuellen Bildschirmgröße für das Gnome-X-Display kann man über den Punkt “Anwendungen” in der linken Gnome-Leiste, die Anwendung “Einstellungen” >> Monitore” sehr bequem vornehmen. Die grafische Interaktion über Spice läuft auf meinem System sehr flüssig. Da haben die Entwickler hinter Spice in den letzten 2 Jahren wirklich großartige Arbeit geleistet.
  • SSH-Zugang vom Host:
    Ist einem Spice (entgegen meiner eigenen Erfahrung) zu träge, so kann man natürlich auch über “ssh -X” auf der virtuellen Maschine arbeiten. Wenn man das tut, sollte man sich vorab ernsthaft Gedanken über die Isolierung des KVM-Gastes während Penetration-Experimenten in seinen virtuellen Netzen machen. Ich nutze für den Zugang zum Kali-Gast meist ein von anderen virtuellen Bridges separates Host-Only-Netzwerk, dessen HOST-Interface von evtl. Routing auf dem Host per Paketfilter (netfilter mit iptables/ebtables) explizit ausgeschlossen ist. Stattet man das Kali-Gastsystem mit mehreren virtuellen NICs aus, sollte dort aus Sicherheitsgründen während Penetrationstest-Übungen in virtuellen Netzen kein
    Routing aktiviert sein.
  • “Gnome Control Center”-Zugang?

    Für Gnome-Ungewohnte: Viele System- und Desktop-Einstellungen erreicht man über das sog. “Gnome Control Center”, was man von der Kommandozeile eines Terminals mittels

    mykali~: # gnome-control-center &

    starten kann.
    Der Aufruf funktioniert allerdings nur lokal innerhalb des Spice-Displays. Er funktioniert nicht über eine SSH-Shell vom Host aus. Es wird ein X-Window-Fehler angezeigt – und zwar erstaunlicherweise aus dem glx-Bereich – offenbar wird am Display ein glx-fähiger Renderer erkannt. Ähnliche Fehler gab es übrigens unter Debian und Ubuntu schon früher bei VNC- und X2go-Verbindungen. Man musste damals GL-X und OpenGL-Fähigkeiten des Remote Displays explizit abschalten. Offenbar liegt nun ein ähnliches Problem vor.
    Es funktioniert leider auch nicht nach einem

    export LIBGL_ALWAYS_INDIRECT=y

    auf dem Kali Gast.
    Keine Ahnung. Schlichter Anwendungs-Bug? Irgendwelche Inkompatibilitäten zwischen dem MESA/libGL-Bibliotheken unter Debian und dem 3D-Nvidia-Treiber Setup auf dem Opensuse-Host? [glxheads läuft – und nach einer Installation von VirtualGL auch glxspheres; glxinfo zeigt vernünftige Meldungen. Warum das “gnome-control-center” überhaupt libGL-Ahängigkeiten auflösen muss, entzieht sich meinem Verständnis. Genauer: Warum machen die Gnome-Entwickler ein so zentrales Ding vom Erkennen eines glx-fähigen Displays und spezifischen Reaktionen darauf abhängig?] Das Thema ist mir im Moment zu aufwändig und auch zu kniffelig; das Problem schränkt aber die eigentliche Arbeit mit Kali in der virtuellen Umgebung nicht wirklich ein.

    Übrigens: Für Änderungen der Netzwerk-Einstellungen – was ggf. häufiger benötigt wird – steht auf einer SSH-Konsole auch der Befehl

    nm-connection-editor

    zur Verfügung, der ein geeignetes grafisches Interface für “NetworkManager” öffnet.

  • apt-get-Konfiguration
    Lediglich die “apt-get”-Konfiguration ist nach der Installation evtl. anzupassen, je nachdem welche Optionen man bzgl. des Update-Verhaltens während der Installation gewählt hat oder wählen konnte. Letztlich sollte die Datei “/etc/apt/sources.list” folgende Einträge enthalten:

    mykali2:~# cat /etc/apt/sources.list
    deb http://http.kali.org/kali/ sana main contrib non-free
    deb-src http://http.kali.org/kali/ sana main contrib non-free
     
    deb http://security.kali.org/kali-security/ sana/updates main contrib non-free
    deb-src http://security.kali.org/kali-security/ sana/updates main contrib non-free

    Auf dieser Grundlage sollte man nach der Installation unbedingt die Sequenz

    mykali:~# apt-get clean
    mykali:~# apt-get update
    mykali:~# apt-get upgrade

    ausführen lassen. Wichtig für eine einwandfreies Starten von “armitage” als Metasploit-Frontend und auch für einen funktionierenden JtR.

  • Bei evtl. Problemen mit einem Armitage-Start:
    Armitage ist ein wichtiges teilgrafisches Frontend für eine Reihe von Tools, u.a. Metasploit. Es sollte neben der “msf-console” lauffähig sein. Dazu sind ein paar Voraussetzungen erforderlich. Wie im letzten Punkt beschrieben, sind zunächst Updates und Upgrades mittels apt-get durchzuführen. Vor dem “armitage”-Start muss zudem die Postgre-Datenbank laufen. Dazu:

    mykali:~# /etc/init.d/postgresql start
    [ ok ] Starting postgresql (via systemctl): postgresql.service.

    Achtung: Der
    Verbindungsaufbau zum XML-RPC-Dämon verzögert sich ggf. etwas, wenn “msfrpcd” und sein Connection Client im Zuge des armitage-Starts erst nachgeladen und selbst gestartet werden. Einer unmittelbaren Meldung über einen abgelehnten Verbindungsaufbau sollte man daher mit etwas Geduld begegnen. Armitage läuft bei mir auch über eine SSH-Shell auf dem Virtualisierungshost.

  • Virtuelle Netze:
    Eine Pen-Test-Übungsumgebung setzt auf dem Host virtuelle Netzwerke mit weiteren virtualisierten Target-Systemen voraus. “virt-manager” unterstützt einem beim Einrichten von virtuellen Netzwerken und deren Bridge-Konfigurationen auf dem Host sehr gut, so dass es hier kaum zu Problemen kommen sollte.
    Der Kali-Gast unter KVM ist danach mit mehreren Interfaces zu unterschiedlichen virtuellen Netzen – und/oder zum (ggf. spezifisch routenden) Host – auszustatten. Ggf. sind sogar virtualisierte Bridges/Switches auf dem Host und deren Verhalten bei Angriffen von einem virtualisierten Gast aus Hauptgegenstand der Untersuchung. In jedem Fall sollte man sich sehr genau überlegen, mit welchen virtualisierten Netzen man den Host ausstattet und wie der Kali-Gast mit diesen Netzen in Kontakt tritt. Für eine Einarbeitung in virtuelle Netze kann man etwa den Literatur-Hinweisen unter
    https://linux-blog.anracom.com/2015/10/19/virtualisierte-netze-mit-kvmqemulibvirt-hinweise-und-links-zur-systematischen-einarbeitung-2/
    folgen.
    Auf dem Kali-Gastsystem selbst bietet das Netzwerk-Symbol rechts auf der obigen Bedienleiste des Gnome-Desktops schnellen Zugang zu Netzwerk-Einstellungen. Alternativ über das “Gnome Control Center”: Unter “Anwendungen” suche man “Einstellungen >> Netzwerk”. Die Möglichkeit, “Profile” für das jeweilige NIC einzurichten, ist absolut nützlich – vor allem wegen des Anlegens von evtl erforderlichen Routen auf dem Gastsystem. Dass auch bei kleineren Änderungen möglicherweise gleich ein komplettes neues Profil angelegt wird, ist etwa gewöhnungsbedürftig. Zudem klappt das Umschalten zwischen validen Profilen in der virtualisierten Umgebung nicht immer ganz problemfrei. Zur Not muss man die Netzwerkverbindung über die angebotenen Schalter stoppen und neu starten. Überflüssige Profile sollte man tunlichst löschen. Einmal laufende Verbindungen für die verschiedenen NICS zu unterschiedlichen virtuellen Netzen und ihren Bridges werden zuverlässig reproduziert.
  • Internet-Zugang:

    Natürlich benötigt das virtuelle Gastsystem für Paketinstallationen Internet-Zugang. Auch hier stellt sich wieder die Frage der Isolation des Systems. Man hat hier mehrere Möglichkeiten in ansteigender Reihenfolge der Isolation:

    direktes Bridging einer virtuellen Gast-Nic auf eine physikalisches Device des Hosts, virtuelle Bridge mit virtuellem Host-Interface und Routing am Host, virtuelle Bridge mit virtuellem Host-Interface und NAT-Konfiguration am Host.

    Die letzte, ggf. aber auch die vorletzte Variante erfordern entsprechende Netfilter-ebtables/iptables-Regeln am Host zur besseren Kontrolle. Was immer man wählt:

    Die entscheidende Punkt ist, ob und dass man das System während Penetrationstests in seiner virtuellen Umgebung vom Kontakt mit der Umwelt abklemmt und dafür die entsprechenden virtuellen Interfaces des Hosts abschaltet – oder ob man bei bestimmten Tests parallel auf das Internet zugreifen muss/will. Letzteres sehe ich für Übungsszenarien im virtuellen Labor eher als Problem. Ich erledige Internet-Recherchen etc. im Zweifel eher über den Host selbst.

Fazit:
Insgesamt bin ich mit dem Einsatz von Kali unter KVM auf einem Opensuse-13.2-Host sehr zufrieden. Die KVM-Umgebung
bietet hinreichend Flexibilität, um jede Art von virtuellem Netz aufzusetzen und bei Bedarf auch ad hoc und zügig zu ändern. Das ist für ein Penetration-Test-Labor optimal. Das Kali 2.0-System ist gut aufgeräumt und bekanntermaßen mit vielen nützlichen Tools ausgestattet, die für die verschiedenen Phasen und Aufgabenbereiche von Pen-Tests vorsortiert sind. Der Debian-Unterbau von Kali 2.0 läuft unter KVM mit Spice und virtio-Treibern wirklich flüssig. Es macht richtig Spaß!

Interessanterweise muss ich als alter KDE-Nutzer sogar zugeben, dass ich dem schnörkelfreien Gnome-Desktop von Kali durchaus etwas abgewinnen kann. Man arbeitet ja meist eh’ auf der Kommando-Zeile …