Fragen? Antworten! Siehe auch: Alternativlos
Die Begründung, wieso chroot(2) nur als root geht, ist ja immer, dass man damit aus einem chroot-Jail wieder ausbrechen kann. Aber nur wenn man dafür einen offenen Deskriptor auf außerhalb des Jails hat, und das könnte chroot(8) ja verhindern.
Überseh ich was? Mir fällt gerade kein guter Grund ein, wieso es kein chroot(8) gibt, das auch für normale User geht.
Update: Jemand hat eine gute Idee: Man kann per Unix Domain Socket im chroot einen Deskriptor von außerhalb des chroot-Jails empfangen und so ausbrechen.
Stimmt. Die Idee ist sogar so gut, dass sie auch ohne chroot funktioniert. Der Ausbruch ist schon nach einem fchdir geschehen, da muss man gar nicht nochmal chroot aufrufen für. Das ist also kein Gegenargument, finde ich.
Update: Ein Leser meint, dass FreeBSD kürzlich ein unprivilegiertes chroot eingeführt hat, allerdings muss man das als Admin erst freischalten, und es geht auch nur chroot -n, welches ein NO_NEW_PRIVS-Flag setzt, was dann zukünftig setuid verbietet. Der Hintergrund ist, dass man sonst einen Hardlink auf ein setuid-Binary machen könnte, z.B. su, und dann aber in dem chroot-Jeil an /etc haben könnte mit "passenden" Dateien, um sich dann im chroot-Jail root zu besorgen. Da wäre der Angriff also nicht der Ausbruch aus dem chroot sondern das Nuzten von chroot zur Privilegienausweitung im Wirtssystem. Das finde ich eine smarte Lösung.
Update: Stellt sich raus: Ubuntu hat ein "schroot"-Kommando. Das kannte ich noch nicht. Interessant.
Update: Man kommt aus einem chroot auch ohne Handle von außen raus, wenn man selber chroot machen darf, weil das nicht rekursiv sondern überschreibend ist. Du machst erst open(".",O_DIRECTORY), hebst das Handle auf, dann mkdir("foo") und chroot("foo") und dann fchdir auf das Handle vom Anfang. Das chroot hat das ursprüngliche überschrieben und das Handle ist jetzt außerhalb des chroot und kann sich frei bewegen.
Update: fchdir verbieten reicht übrigens nicht. openat reicht als Hebel.
Aber stellt sich raus: Da ist noch Luft nach unten. Man kann Single Sign On an die Cloud outsourcen. Dann kann die Firma in der Cloud für jeden deiner Dienste und jeden deiner User inklusive Admins gültige Login-Credentials ausstellen.
What could possibly go wrong?
Es gibt eigentlich nur zwei Möglichkeiten, dachte ich mir, als ich das hörte. Entweder das wird von einem Geheimdienst betrieben, oder alle Geheimdienste haben sich da reingehackt. Das ist ja als wenn du mit einem Bullseye auf dem Rücken rumrennst. So einem krassen Potential zur Berechtigungserlangung kann kein Geheimdienst widerstehen.
Ich sehe sowas bei Kunden eher selten, aber ich habe es schon gesehen. Cyberark z.B. ist mir schon begegnet. Ein israelischer Anbieter. Ich maß dem nie groß Bedeutung zu, bis ich mal an deren Hq in Israel vorbeikam. Hier ist ein Foto von dem Gebäude. Wisst ihr, wer da noch sitzt? Cellebrite. Ja, die mit den Smartphone-Exploits. Da verstand ich, dass wir es hier mit Full Spectrum Identity Services zu tun haben.
Ich erwähne das nicht, um mich über die Leute lustig zu machen, die ihre Login-Software an irgendeinen Cloud-Anbieter outsourcen. Nein. Die haben genug zu leiden.
Ich erwähne das, weil Lapsus (russische Ransomware-Gang) offenbar seit Monaten bei Okta drinnen sitzt. Okta bietet Single-Sign-On-Cloud-Outsourcing an.
Auf er einen Seite ist das natürlich apokalyptisch. Auf der anderen Seite ändert es nichts. Denn die Aufgabe von Login ist, dass sich niemand aus der Cloud einfach bei dir einloggen kann. Wenn du dein Login in die Cloud schiebst, hast du per Definition dein schlimmstes Bedrohungsszenario immanentisiert.
Und jetzt haben wir den Salat. Beziehungsweise den Emmerich-Film. Und ich bin der Jeff Goldblum-Charakter, der die ganze Zeit gewarnt hat.
Mein persönliches Karriere-Highlight in dem Kontext war ja, als ein Kunde von mir wollte, dass ich so einem Provider einen Voice-Print gebe. Ich sollte da anrufen und lauter Phoneme auf Band sprechen. Und dann, so die Erklärung, wenn ich mal mein Passwort resetten muss, dann kann der Computer erkennen, dass ich es bin. Ich habe dankend abgelehnt. Das ist ja eine Sache, ob der Kunde mein Passwort einem ausländischen Geheimdienst in der Cloud gibt, aber meine biometrischen Daten behalte ich lieber für mich, vielen Dank. Der Kunde konnte das gar nicht verstehen. Wir anderen Mitarbeiter bei dem Kunden machen das auch alle und noch nie gab es Ärger!
Vielleicht aus aktuellem Anlass bei der Gelegenheit an meine anderen Kunden: Keine Sorge. Selbstverständlich kriegt jeder Kunde sein eigenes zufällig generiertes Passwort mit ausreichend Entropie. Wenn ein Kunde mein Passwort in die Cloud schiebt, kriegt die Cloud keinen Zugriff auf meine Accounts bei anderen Kunden.
Irgendjemand muss ja hier ein paar Standards haben. :-)
Update: BTW: Glaubt mal gar nicht, ihr condescending Unix neckbeards, dass ihr nicht betroffen seid von dieser Art Irrsinn. Ein Kumpel schildert mir gerade, wie ihn der neue Ubuntu-Installer nach seinem Github-Usernamen fragte, damit er da SSH-Keys runterladen kann. Und über diesen Clownflare-Klassiker von 2019 lachen wir heute noch.
Update: Bei Microsoft scheint Lapsus auch eingedrungen zu sein.
Update: Möglicherweise via Okta? Der Okta-Krater sieht jedenfalls vergleichsweise groß aus.
Update: Hat hier jemand seinen Quellcode bei Gitlab liegen?
Das bekam ein verdatterter Azure-Kunde als Nachricht auf Linkedin. Von einem Vertriebler bei Ubuntu.
Das krasse bei solchen Geschichten ist, dass ich live vor mir sehen kann, wie alle auf dem Weg dieser Entscheidung dachten, sie täten hier gerade etwas Gutes.
Oder als Ubuntu Werbung einblendete? Der Himmel fiel uns auf den Kopf!
Oder als Mozilla auf ihre Neues-Tab-Seite Werbung gepackt hat? Ein Aufschrei!
Seid ihr eigentlich auch so froh, das Apple die Guten sind? Nicht auszudenken, wenn die die Bösen wären! Meine Güte, all die Daten, die ihr denen gegeben habt!
Dem würde ich generell widersprechen wollen. Doch, ist es. Das ist genau die Nummer Eins Gefahr, die von der steigenden Komplexität ausgeht. Gerade bei vlc, wenn man das mal selber baut und startet, und mal die Shared Libraries zählt, die das Ding reinlutscht, dann ist völlig klar, dass das Risiko enorm zugenommen hat, bis hin zur offensichtlichen Nicht-Beherrschbarkeit. Klar, dafür hängt da auch die Funktionalität von ab. Will ich nicht bestreiten. Aber die Laxheit, mit der Leute fremde Libraries reinladen, und dann so tun, als sei das nicht ihr Problem, wenn die räudig sind, die ärgert mich schon lange.
Auf der andere Seite ist das Problem in libebml zu dem Zeitpunkt seit über einem Jahr bekannt und upstream gefixt gewesen, aber die Knödel von Ubuntu haben es verpeilt, den Fix auszuliefern. Insofern bin ich dann doch auf der Seite von VLC in dieser Sache, denn das Sicherheitsloch war in Ubuntu, nicht VLC.
Die Geschichte ging aber noch weiter. Die VLC-Leute berichten, dass der Fuzzy, der die Lücke gefunden hat, direkt ein CVE beantragt und bekommen hat, ohne dass jemand auf dem Weg es für nötig oder höflich gefunden hätte, bei VLC mal nachzufragen. Nicht nur das: Der CERT-Bund, immerhin eine Regierungsorganisation Deutschlands, hat ein Advisory veröffentlicht, auch ohne bei VLC mal nachzufragen.
Da wird die Sache jetzt ein bisschen weniger klar. Denn VLC betreibt einen offenen Bugtracker, aber möchte gerne Security-Sachen per Mail vorab gemeldet kriegen, damit die mit Priorität bearbeitet werden können. Das will ich mal der Klarheit halber umformulieren: VLC hat einen Bugtracker, den sie als sedimentäre Datenhalde betreiben, und wo sie längst die Kontrolle über die Flut an Bugs verloren haben, daher haben sie eine Parallelgesellschaft in Form von einem Security-Bug-Mailverteiler geschaffen. Das, meine lieben VLC-Leute, habe ihr euch vollumfänglich selbst zuzuschreiben. Euer Bugtracker ist öffentlich, und das ist gut so. Dort hatte der Bug-Finder einen Bug aufgemacht. Den habt ihr mit den anderen Bugs in der ewigen Buglavine verpennt. Als Reporter ist es völlig OK, VLC nicht "Bescheid" zu sagen, wenn es einen offenen Bugtracker gibt. Denn dafür gibt es den. Und dafür ist der offen. Damit man sich dort über Bugs informieren kann. Dass ihr jetzt von der Presse verlangt, dass sie die Kosten für euer verkacktes Bugtracking trägt, ist absurd. DAS habt ihr euch echt selbst zuzuschreiben.
Und jetzt hört auf zu heulen, fixt eure Bugs, und haltet die andere Wange hin. Mit eurem Fake-News-Geschreie macht ihr die Sache nur noch schlechter.
Das ist ungefähr so viel wert, wie ihr gedacht habt. Gar nichts. (Jedenfalls bei Edge, behauptet dieser fiese Hacker mit Windows-VM unter Ubuntu)
Ich habe hier einen Kunden-Laptop, auf dem ich mal ein clang-tidy laufen lassen wollte. Also erstmal WSL mit ubuntu geholt. apt-get install clang-tidy gab mit 6.0. Aktuelles Release ist 8.0, ich arbeite sonst mit dem HEAD, das meldet sich als 9.0. Ja, nee, Ubuntu.
OK, dann update ich halt mal das Ubuntu von LTS auf unstable. Dachte ich mir. In meinem jugendlichen Leichtsinn. Erstens will deren CLI-Distro-Upgrade-Tool erst auf Devel upgraden, wenn man vorher auf die aktuelle Stable geupgraded hat. Und das Stable will er erst upgraden, wenn man vorher updated. Ich musste mir also drei komplette Distros ziehen für ein Upgrade. Danke, Ubuntu.
Aber das war nicht, weshalb ich das hier schreibe. Die Upgrades brauchen EWIG. Ich vermute, dass das an der schwachbrüstigen Hardware auf dem Kundenlaptop liegt, und daran, dass die Bitlocker anhaben, und dass da zwei fucking Schlangenöle parall laufen und sich gegenseitig behindern.
Da fiel es mir wie Schuppen von den Augen.
Was wenn WSL2 bloß dazu da ist, das Schlangenöl bei Filesystemzugriffen aus dem kritischen Pfad zu optimieren?
Diese Updates laufen jetzt hier seit über vier Stunden. Und die Pakete kamen mit 100 MBit reingeflutscht, daran lag es nicht.
Update: Dev-Ubuntu kommt mit gcc 8.3 und clang 7. WTF Ubuntu?! Was muss man denn bei euch nehmen, wenn man aktuelle Versionen haben will? Ubuntu Futur?
New hotness: AVG-Werbung in Wien :-) (Danke, Daniel)
Update: Oh und jetzt kann man auch noch mit Visual Studio Linux-Binaries bauen!
Die Tipps, die ich umzusetzen versucht habe, waren: Zeilenlänge begrenzen, größerer Zeilenabstand, schöne Schriftart.
Nun ist eine gute Schriftgröße von mehreren Fakten abhängig, unter anderem der Breite des Browserfensters und der Bildschirmauflösung. Und ich habe mir ja letztes Jahr einen 4k-Monitor gekauft, also nahm ich mir vor, das gleich mal zu unterstützen.
Aktuelle Browser können im CSS Angaben relativ zur Viewport-Größe machen, und das habe ich benutzt. Man will links und rechts einen Rahmen haben (auf dem Desktop zumindest, auf Mobiltelefonen ist das natürlich Scheiße; eine gute Lösung dafür habe ich noch nicht).
Bleibt noch die Frage, welche Schriftart man nimmt. Hier gibt es so viele, dass ich gerade überlege, die Schriftart per Cookie separat einstellbar zu machen. Beim Durchprobieren fiel mir auf, dass mich die Serifen-Schriften alle viel weniger überzeugten als Serifenlose. Vom Schriftbild her finde ich FF Dax recht ansprechend, aber die ist kommerziell, sehr teuer, und kommerzielle Webfonts haben im allgemeinen völlig inakzeptable Lizenzbedingungen. Man muss dann die Schriftarten von einem fremden Server einbinden, und dessen Betreiber können dann meine Leser überwachen. Das finde ich völlig inakzeptabel. Außerdem zahlt man pro Seitenaufruf, das geht natürlich auch nicht. Aber das Abhörargument tötet die Option für mich schon, bevor ich über Preise nachdenke.
Die nächste Schriftart, die ich in Erwägung zog, ist Orgon Sans, die zumindest auf den Beispielen perfekt aussieht, und für die es eine Webfont-Option zum Runterladen und selber hosten gibt, die auch kein Limit auf die Zugriffe hat. Aber als ich mir die Testversion installiert und probiert habe, gab es einige Rendering-Probleme, insbesondere war sah kleine "z" nicht gut aus. Ich habe dem Hersteller mal eine Mail geschrieben, mal gucken was er sagt.
Am Ende fiel mir dann aber auf, dass Ubuntu auch eine Schriftart entwickeln lassen hat, und die sieht zwar nicht genau so aber doch ähnlich aus. Die kann man sich bei Ubuntu runterladen, und die verwende ich im Moment. Ich hoste sie aber noch nicht selber, die müsstet ihr euch also selber installieren, wenn ihr typo.css mal testen wollt :-)
Auch noch im Rennen ist Clear Sans Light, die sieht auch sehr schön aus und ist frei. Kann man mit typo2.css ausprobieren.
Update: Und wer mal mit Serifen probieren will: typo3.css hat Source Serif Pro (u.a. von hier downloadbar).
Das ist dann wohl eine Copyright-Verletzung.
Nein, wirklich! Die Linux Distros könnten da rumzicken. Hat wohl bisher noch keine gemacht, aber nunja. Wer dachte, hey, freie Software ist freie Software, und gerade die GPL sollte doch dafür sorgen, dass von der Front kein Stress kommt, … Die Free Software Foundation hat da zwei Jahre rumverhandelt. Unglaublich.
Hier ist ein Ubuntu-Bug dazu, und der ist ganz instruktiv.
Wenn man den Darstellungen dort glauben darf, dann hat Samsung in ihrer Firmware angekündigt TRIM mit NCQ zu können, kann es aber nur ohne NCQ. Linux guckt sich an, was die Firmware ansagt, und macht das dann halt, und dann failed die SSD. Der Fix ist jetzt, die Samsung-Geräte in die schwarze Liste der Geräte aufzunehmen, bei denen der Hersteller zu blöde ist, die tatsächlichen Capabilities zu announcen.
Glücklicherweise kann man immer noch sowohl TRIM als auch NCQ machen, nur halt nicht in Kombination. (Danke, Thomas)
Unfortunately, because of the large number of sites which incorrectly handled TLS v1.2 negotiation, we had to disable TLS v1.2 on the client.
Dass diese Debilianisten und ihre Abkömmlinge das aber auch nicht lernen, die Finger von OpenSSL-Patches zu lassen!
Update: Die Sudo-Sprallos veröffentlichen ernsthaft keine PGP-Signaturen für ihre Releases?!? Au weia.
Update: Oh und wo wir gerade bei peinlichen Bugs waren: Ubuntu fixt einen Buffer Overflow in cfingerd. Wo kommt der Bug her? Aus einem Ubuntu-Patch für cfingerd. Erinnert ein bisschen an das OpenSSL-Dingens damals.
Update: Ich höre gerade, dass OS X auch zu den Kinderunixen zählt, wo man ohne Superuserrechte die Systemzeit ändern kann. Und da steht "der User" auch im sudoers-File.
Es gehe keineswegs darum Werbung im Desktop unterzubringen, wie manche nahelegen würden.Aber nein, mein Herr, natürlich nicht, mein Herr! Wer käme denn auch auf sowas! (Danke, Frank)
Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though.
Den Fehler haben sie am 17. September 2006 eingebaut. Juchee für die Sicherheit!Update: falls das jemandem nicht klar ist: Ubuntu == Debian. Auch alle Ubuntu-User sind betroffen.
Ich persönlich habe auch nur die Minderzahl der Vorträge gesehen, aber kann bisher folgende Vorträge empfehlen:
static inline void* avahi_new_internal(unsigned n, size_t k) {Also mal abgesehen davon, daß man sowas mit if abfängt und nicht mit assert, weil man sonst ein Sicherheitsproblem hat, wenn jemand mit -DNDEBUG kompiliert… was ist denn, wenn das jemand mit k == 0 aufruft? Also so richtig doll überzeugen tut mich ja das Ubuntu Security Team nicht, muss ich sagen.
assert(n < INT_MAX/k);
return avahi_malloc(n*k);
}
With Ubuntu Christian Edition, you don't need to surf the web. You can walk on it.Ubuntu Christian Edition doesn't allow to put a network interface into promiscous mode.