So oder so ähnlich titeln einige bekannte Internetzeitungen. Solche Titel stoßen mir immer etwas sauer auf. Zitiert werden oft Aussagen namhafter Anti-Virussoftware-Hersteller, ohne aber etwas genauer darauf einzugehen.

Wann kommt die Flut?

Genau hier möchte ich gleich mal einhaken. Die Flut kommt nicht “von selbst” aufs Smartphone. Nein! Es ist immer noch so, dass es eine Userinteraktion benötigt, um sich vermeintlich böse Software auf das Smartphone zu laden.

Natürlich kommt diese böse App aus dem Android-Market. Die “neuesten Schädlinge” dürften offenbar darauf abzielen, Werbung einzublenden und die Browser Startseite zu ändern. Klinkgt nicht so schlimm, ist wohl eher als Adware einzustufen und kann -wenn man den Artikeln glauben schenkt, einfach über die Deinstallation vom Smartphone entfernt werden.

Android – ein offenes System! Klar, dass es unsicher ist?!

Für den nächsten “sauren Aufstoßer” sorgen Statements die Android deshalb als unsicher bezeichnen, weil es ja ein offenes System ist. Meiner Meinung nach ist das ganz klar ein riesengroßer Blödsinn!

Nur weil es Opensource ist, ist es nicht unsicher. Ganz im Gegenteil! Fehler werden hier viel schneller von der Community gefunden, wie bei Anbietern von “closed source” Software. Was allerdings vor allem auf den Android-Smartphone-Sektor zutrifft ist, dass bekannt gewordene Sicherheitslücken wohl nicht so schnell gepatcht werden, da die Freigabe dieser Patches nicht nur Google und den Herstellern diverser Smartphones obliegt, sondern vor allem den jeweiligen Netzbetreibern.

Die größte Sicherheitslücke

Ohne Frage der Smartphone-User selbst. Mir ist kein Fall bekannt, in dem sich ein Schädling von selbst (over the air?) im Smartphone festsetzt. Es ist immer so, dass der Anwender -ohne viel zu denken und zu lesen- zig Apps aufs Smartphone zieht und sich das Problem selbst “einschleppt”.

Klar ist auch, dass ein gerootetes Smartphone einem höheren Risiko unterliegt, durch Fehleinschätzung und Leichtsinn des Anwenders, Schaden durch Malware zu erleiden. Schließlich hat man ja durch die Rootrechte umfassenden, ja Komplettzugriff, auf das System.

Verwendet doch einfach zuerst eure Hirn-Applikation

Das Angebot an Apps ist unüberschaubar. Deshalb gilt: Die erste Bastion der Verteidigung ist euer Hirn.

• Bewertungen im Market lesen.
• Beachten, wie viele User die App bereits installiert haben.
• Besonderes Augenmerk auf die Berechtigungen legen, die eine App sich einräumt. Wird hier unvollziehbares gefordert (z.b. wenn ein Game Zugriff auf das Telefonbuch haben will und vielleicht sogar noch Nummern wählen will…) auf die App verzichten.
• Wenn man will, kann man sich auch noch eine Antivirensoftware installieren.

Vor einigen Wochen habe ich versucht, meinen Blog bei ubuntuusers.de eintragen zu lassen.  Da ich einige Zeit lang keine Antwort auf meine Anfrage bekommen habe, erlaubte ich mir im Forum direkt nachzufragen.

Offenbar meldete sich ein etwas “angesäuerter” User, der mir mitteilte, dass es seitens des UU-Teams wohl eine sehr hohe Messlatte für Blogs, die in den Planeten aufgenommen werden wollen, gibt.

Von einem der Moderatoren wurde mir schließlich mitgeteilt, ich sollte mich doch bitte im Oktober nochmals bewerben. Wenn ich die Qualität und die Quantität meiner Artikel aufrecht erhalte, siehts gut aus mit der Aufnahme meines Blog.

Gut! Also hab ich mich nun im Oktober nochmals beworben. Prompt erhielt ich die Rückmeldung, das man sich berate und ich bitte etwas Geduld haben muss.

Am 11. November bekam ich eine weitere Absage und die Bitte mich doch in einem halben Jahr wieder zu bewerben.

Ok, gut, liebe Ubuntuusers-Planeten-Mods, dann eben NICHT. Ich hatte ja bereits im Forum erwähnt, dass es mir grundlegend ziemlich egal ist, ob ich nun im UU-Planeten stehen darf oder nicht! Eines sei aber gesagt: Der Planet lebt von den Blogs der User, ohne Blogs kein Planet!

Da lob ich mir www.debianforum.de und planet.debianforum.de!

Ziemlich geschlossene Sache, der Opensource-Ubuntu-Planet…

Unlängst – so liest man zumindest in einer aktuellen österreichischen Onlinezeitung -hat Apple wohl eine Bonner Kaffeehausbesitzerin verklagt. Warum? Weil die Dame als Logo einen Apfel mit einem Kindskopf als Logo-Marke verwendet und diese hat eintragen lassen.

Nun frage ich mich – bitte verzeiht wenn ich falsch liege – was hat ein Kaffeehaus mit der Computermarke Apple zutun?

Gibt es irgend eine Bedrohung für Apple, die von diesem Kaffehaus aus geht? Gewinnverlust? Könnte dieses Kaffeehaus an Apples Ruhm etwas ändern? Wäre gar der Titel des gewinnträchtigsten Unternehmens in naher Zukunft, durch einen Riesenkaffeeumsatz des Kaffeehauses bedroht?

Abseits dieser Klage geht Apple auch gegen einen Nudelhersteller vor, der ebenso ein apfelähnliches Logo verwendet welches aber, meiner Meinung nach, eher an das LG Logo erinnert.

Alles in allem finde ich diese Rundumschläge geradezu lächerlich! Wo drückt hier der Schuh?

Nimmt man die Klageaktion gegen Samsung her, könnte man doch glatt denken, dass Apple zunehmend Respekt vor dem Mitbewerb bekommt…

Der Vollständigkeit halber poste ich hier mal meine Email die ich vor einiger Zeit an Uefi.org geschrieben habe. Ich nehme nicht an, dass ich da drauf noch ne Antwort bekomme .

Gesendet 26.09.2011 12:16:10
An: admin@uefi.org
Betreff: Booting only from signed Operating Systems

Dear Sir!
Dear Madam!

I hope you can tell my something about the new “feature” in Uefi V2.3.1, which only boots signed OS.

Is it true, that only operating systems -which are allowed (signed)- can be booted / alter the bootsector?
What about Linuxdistributions like Debian, Ubuntu…? Will they be “kicked” out, because they are not signed?
Who decides which OS will be signed and “is allowed” to boot?

Yours faithfully

Vor kurzem hab ich mein doch schon älteres Mainboard gegen ein aktuelles Gigabyte Mainboard ausgetauscht. Das neue Board unterstützt Hybrid EFI, hat jedoch noch ein Award Bios, kann aber bereits von Festplatten > 2 TB booten.

Verbindungsprobleme

Egal, ob mit Linux Mint 11, Debian Testing, Linux Mint Debian Edition oder Sabayon, irgendwie verhielt sich die Netzwerkkarte der Marke Realtek RTL8111E chip (10/100/1000 Mbit) mit den – von den Distributionen zur Verfügung gestellten Treibern – komisch.

Unter Sabayon wurde die Netzverbindung zwar hergestellt, sie war jedoch gleich nach dem Systemstart in Gnome nicht verfügbar. Dies äusserte sich zum Beispiel so, dass der Firefox immer erst nach einem Reload der aktuellen Startseite etwas anzeigte. (Sonst gabs ein Server nicht gefunden).

Unter Debian Testing, Linux Mint 11 und auch Linux Mint Debian Edition, war die NIC anfangs “da” und man konnte auch eine Verbindung herstellen. Kurz danach jedoch, ging die Verbindung in die Knie und funktionierte nur noch – wenn überhaupt – sporadisch.

Lösung des Problemes

• Man sucht die Website von Realtek auf und ladet die Datei LINUX driver for kernel 2.6.x and 2.4.x (Support x86 and x64)herunter.
• Diese entpackt man dann in ein Verzeichnis
• Dann stellt man sicher, dass man die Kernel Sources zum momentan verwendeten Kernel (uname -a bzw. uname  -r gibt Aufschluß über den installierten Kernel) installiert hat. Die Kernel Sources haben in apt, synaptic etc. in meinem Fall z.B. den Namen linux-headers-2.6.38-8. Bei euch kann das natürlich – abhängig vom verwendeten Kernel – abweichen!
• Danach öffnet man eine Konsole als root, oder greift auf sudo zurück und wechselt in das Verzeichnis, in das man die heruntergeladene Datei entpackt hat. Dort sollte es dann die Dateien autorun.sh,  log.txt,  Makefile,  README und den Ordner  src geben
• Die Installation startet man (als root!) durch Eingabe von ./autorun.sh

Bei mir hat das Installationsscript problemlos funktioniert und das neue Modul (den Nic-Treiber) installiert.

Eine Recherche im Internet bringt übrigens zu Tage, dass es offenbar schon länger Probleme mit dieser NIC bzw. dem Standardmodul gibt…

In Zusammenhang mit einem vorhergehenden Artikel, gibt es nun neuen (Zünd?-)stoff in Sachen “Uefi”.

Angeblich scheint es wirklich so zu sein, dass es nicht signierten OS einfach nicht erlaubt werden soll, den Bootsector zu ändern bzw. zu booten. Ganz klar ist die Situation jedenfalls sicher noch nicht.

Auch wenn ich davon ausgehe, dass die Sache im Moment nur hochgespielt wird und es am Ende hoffentlich dem User überlassen wird, ob er diese Sicherheitsoption aktiviert oder nicht, bleibt ein fader Beigeschmack.

Sagt und MS wirklich schon, was wir auf den PC installieren dürfen und was nicht? Viel Wirbel um nichts, oder doch der Anfang vom Ende der freien Betriebssystemwahl…

Interessanter Artikel zu diesem Thema: http://mjg59.dreamwidth.org/5850.html, welcher folgende Fakten? in den Raum stellt:

• Windows 8 certification requires that hardware ship with UEFI secure boot enabled.
• Windows 8 certification does not require that the user be able to disable UEFI secure boot, and we’ve already been informed by hardware vendors that some hardware will not have this option.
• Windows 8 certification does not require that the system ship with any keys other than Microsoft’s.
• A system that ships with UEFI secure boot enabled and only includes Microsoft’s signing keys will only securely boot Microsoft operating systems.

Ich habe Uefi.org mal eine Email geschrieben. Bin gespannt ob etwas retour kommt…

Glauben kann ich das im Moment noch nicht wirklich. Wie jedoch zu lesen ist, kann in den noch nicht sehr verbreiteten neuen Biosvarianten (UEFI) offenbar eine Funktion aktiviert werden, die den Start von nicht signierten Bootloadern verhindert.

Geht man nun davon aus, dass nur MS Windows einen solchen signierten Bootloader zur Verfügung stellt, kann man annehmen, dass Linux hier ausgesperrt wird.

Was mir allerdings nicht ganz klar ist: Wenn diese Option im UEFI Bios erst aktiviert werden muss, warum lässt man selbige nicht einfach abgedreht? Dann hätte man mit dieser Funktion auch im Zusammenhang mit dem Linux Bootloader (z.B. Grub) keine Probleme.

Im Artikel von HEISE lautet es ganz klar: “Ist Secure Boot aktiv, lässt sich also auch kein Linux starten, sofern es nicht die nötigen Signaturen mitbringt und vom Besitzer oder Administrator des jeweiligen Computers explizit für das Gerät erlaubt wurde.”

Was also, wenn man Secureboot inaktiv lässt?

Bezogen auf meinen Artikel zur Konfiguration des VSFTP unter Debian Squeeze habe ich jetzt ein sehr! simples Shellscript geschrieben, welches die Schritte, die im Howto aufgeführt sind, automatisch durchführt.

Voraussetzung: Bestehende und funktionierende Internetverbindung, vorhandenes Verzeichnis /var/www, Debian Squeeze!

Wichtig – zuerst lesen!

Solltet ihr bereits einen vsftp installiert haben, sichert euch eure Konfiguration zusätzlich weg, bevor ihr das Script startet (auch wenn das Script die Konfigurationsdateien sichert)!

Als Basisverzeichnis für die FTP-User wird /var/www angenommen. Der User test hat das Homeverzeichnis /var/www/test und kann per FTP Client nur in diesem Verzeichnis “arbeiten”.

Das Script sichert eventuell vorhandene Konfigurationsdateien von VSFTP. Genauer gesagt werden folgende Files gesichert:

• /etc/pam.d/vsftpd -> /etc/pam.d/vsftpd.bak
• /etc/vsftpd.conf -> /etc/vsftpd.conf.bak
• /etc/vsftpd.usr_list -> /etc/vsftpd.usr_list.bak

Die Konfigurationsdateien werden von meinem Webspace heruntergeladen.
Betroffen:

• /etc/pam.d/vsftpd
• /etc/vsftpd.conf
• /etc/vsftpd.usr_list

Bestätigen muss man nur das Kennwort für den User test. Die Abfrage kommt während dem Installationsvorgang.

Herunterladen des Scripts

Download der Datei in ein Verzeichnis des Linuxserver. Hat man keinen Webbrowser parat, kann die Datei auch von der Kommandozeile aus heruntergeladen werden.

• Wechsel in das lokale Verzeichnis, in das die Datei heruntergeladen werden soll
• wget http://www.pc-howto.com/files/vsftpinstaller
• RETURN

Danach muss die Datei ausführbar gemacht werden. Dies bewerkstelligt man durch den Befehl:

• chmod +x vsftpinstaller
• RETURN

Ausführen kann man die Datei dann als ROOT mit dem Befehl ./vsftpinstaller

ACHTUNG: Ich habe dieses Script auf einer Debian Squeeze Installation getestet, auf der Apache, MySql und Php installiert sind.

Es handelte sich hierbei allerdings um keine Produktivumgebung! Das Script fährt “ohne Rücksicht auf Verluste” von Anfang bis Ende durch, also bitte vorher testen, anpassen… usw.

Ich übernehme keinerlei Verantwortung für eventuell auftretende Schäden und Probleme!

http://www.sabayon.org/

Auf zu neuen Gefilden ^^. Bin ich sonst eigentlich immer debianlastig unterwegs, habe ich mir heute Sabayon Linux heruntergeladen. Diese Distribution basiert auf Gentoo Linux. Ja genau, dieses System, auf dem man eigentlich alles selber machen (kompilieren) muss und es eine Zeit lange dauert, bis man alles unter Dach und Fach hat. Wenn man es aber geschafft hat belohnt Gentoo mit Geschwindigkeit, da Programme auf das eigene System abgestimmt bzw. optimiert sind. Denn es wird ja – wie erwähnt – alles kompiliert.

Vorweg zur Paketverwaltung

Wie verhält sich das bei Sabayon? Nun, soweit ich bis jetzt “gelernt” habe, ist es so, dass bei Sabayon ein eigens erstelltes Pythonprogramm mit dem Namen “Sulfur” die Paketverwaltung übernimmt (gleichzusetzen mit aptitude unter Debian).

Als CLI Programm kann man auch equo verwenden (gleichzusetzen mit apt-get von Debian).

Will man den “Gentoo-Style” auch unter Sabayon einsetzen, steht einem auch die Verwendung des Befehls “emerge” offen. Hiervon bin ich im Moment aber noch weit entfernt!

Mein Dank geht übrigens bereits an dieser Stelle an die Jungs und Mädls? im IRC Channel von Sabayon! Nett und hilfsbereit!

Installation

Die Installation kann ich als unspektakulär einfach bezeichnen. Man wird bei Sabayon sehr schön “an die Hand” genommen. Es gibt einen Installer mit GUI, der die üblichen Schritte mit dem “Installationswilligen” durchgeht. Freilich ists nicht schlecht, wenn man schon mal was von Devices, Mountpoints und Swapspeicher gehört hat und damit etwas anfangen kann

Als Installationsmedium kam bei mir eine ca. 1.3 GB große DVD zum Einsatz, wobei -ganz vergessen- ich habe die Gnomeedition heruntergeladen. KDE sagt mir nicht ganz so zu, was nicht heißen soll, dass ich KDE schlecht finde!

Der Installer von Sabayon muss mit folgender Hardware zurecht kommen:

• 1x SSD OCZ Vertex2 30GB
• 8GB DDR3 Speicher
• AMD PhenomII X3 @ 2.8 Ghz
• Nvidia Gforce GTS 250
• Soundblaster Audigy SE
• MSI 770 C45 Mainboard

Erster Start nach der Installation

Es startet und läuft. Etwas klein empfinde ich die Standardschrift, die ich größer Stelle. So, aber was nun? Weiß ich mittlerweile “blind” mit apt umzugehen, fühle ich mich etwas verloren…

Was “muss” man nach der Installation machen? Nun, das Image, welches ich auf die DVD gebrannt habe ist zwar das aktuellste, jedoch wird es sicherlich neue Pakete geben. Also Updaten! Ja… nur wie? (ich wußte hier noch nicht, welche Programme für was zuständig sind!)

Moment! Neben der Uhrzeit gibt es ein Symbol, welches sehr stark an das Windows “Es sind Updates verfügbar” Systemtray-Icon erinnert. Also Rechtsklick darauf und aha, es gibt ein “Auf Updates prüfen”, was ich gleich mal anklicke.

Hier fällt mir das erste mal auf, dass es lange dauert, bis Daten über die Leitung kommen. Ups! Es gibt 890 Updates! Ja ja, bleeding edge…

Unten ladet der Button “Paketmanager laden” direkt darauf ein, darauf zu klicken.

Schließlich bekomme ich die Updates aufgelistet bzw. muss zuvor noch Lizenzvereinbarungen aktzeptieren (5 an der Zahl). Welche es genau waren, hab ich mir nicht durchgelesen.

Also starte ich den Updatevorgang… und bemerke abermals, dass die Internetverbindung bzw. die verwendeten Mirrors zu langsam sind, um die ca. 1.2 GB an Updates entsprechend zügig aus dem Netz zu laden. (Bei knapp 30kb/sec dauert mir das zu lange).

Nicht verzagen, IRC Channel fragen .

Durch den Befehl

• equo repo mirrorsort sabayon-weekly

wird die Liste der Mirrors neu sortiert. Schnellste zuerst. Jetzt “fetzts” und die Daten kommen entsprechend zügig bei mir an.

Sicher ist, ich hab noch viel zu lernen, Sabayon macht aber sehr viel Spaß

Eine angepasste Version meines VSFTP Howto für Squeeze ist online. Hauptsächlich handelte es sich hierbei um eine Anpassung bei der Benutzerauthentifizierung. Der Eintrag von /bin/false in /etc/shells ist nicht mehr nötig, da dies nun über /etc/pam.d/vsftpd erledigt wird.

Hier gehts zum Howto (nicht wundern, der Link hat noch “Lenny” im URL, es ist aber ein Howto für Squeeze (sollte natürlich auch für Lenny klappen).