HardenedBSD ist ein sehr gutes Projekt. Es ist stets nah dran an FreeBSD und erweitert es um sinnvolle Sicherheitsfunktionen/Mitigations/gehärtete_Voreinstellungen. Bei erhöhten Sicherheitsbedarf lässt es sich so sehr gut anstelle von FreeBSD einsetzen. Nicht zu vergessen das auch FreeBSD direkt davon profitiert, da durchaus einige Sachen nach FreeBSD zurück wandern.
In erster Linie daß es ein modifiziertes FreeBSD ist. D.h. es bringt den riesigen Ports-Tree mit, der bei OpenBSD doch erheblich kleiner ausfällt. HardenedBSD nimmt auch hier Härtungen vor, jedoch muß man im Zweifel schauen, welche Ports von den nicht-generischen Härtungen betroffen sind.
Außerdem hat es alle Treiber, die FreeBSD 12 auch hat. Da gibt es teilweise auch erhebliche Unterschiede zu Open. Der Benutzer hat die Möglichkeit, eine von drei verschiedenen Firewalls (IPFW, Pf, IPF) einzusetzen, während OpenBSD nur eine hat (Pf - allerdings in einer in vielen Dingen wesentlich moderneren Version). Usw., usf.
Was die Sicherheitsfeatures angeht, bietet das Projekt selbst einen Vergleich: https://hardenedbsd.org/content/easy-feature-comparison
Von blablabla233 am Fr, 21. Dezember 2018 um 11:00 #
Das mit dem PF von FreeBSD zu OpenBSD ist so eine Sache, zwar ist der PF von OpenBSD etwas weiter, jedoch ist er nicht SMP-faehig wie der PF von FreeBSD. Du hast noch ZFS vergessen
1. Hat HardenedBSD denn auch vorkompilierte Pakete wie FreeBSD seit pkgng? Oder gibt es nur modifizierte Ports? Wie viele davon laufen ohne weiteres Zutun?
2. Die Firewalls aus FreeBSD sind schön und gut. IPF wirkt wie ein totes Pferd. pf genießt unter FreeBSD zwar SMP-Unterstützung, im Gegensatz zu OpenBSD. Technologisch gesehen, finde ich NPF (NetBSD) und nftables/netfilter (Linux) interessanter und zukunftsfähiger, da i.A. performanter.
3. Warum werden die Sicherheitsfeatures eigentlich nicht direkt in FreeBSD eingebaut? Sind sie nicht fertig? Zu große Performance-Einbußen? Wer sträubt sich bei FreeBSD gegen eine Implementierung? Werden ausgewählte Features migriert?
4. Ich wusste gar nicht, dass das grsecurity/PaX-Team um Brad Spengler, welche CFI in Form von RAP entwickelt haben, ihr Zeug inzwischen patentieren und eine GPL3-lizensierte Toolchain voraussetzen. Zitat:
RAP would be a great addition to HardenedBSD; however, it requires a GPLv3 toolchain and is patented. - Quelle: hier
Ich weiß nicht, wie ich das finden soll. Machen die das, damit Kees Cook & Co Features aus grsecurity (oder abgeschwächte Versionen) nicht peu à peu nach linux-master portieren können?
Von blablabla233 am Sa, 22. Dezember 2018 um 11:21 #
1. Ja haben sie, installieren, nutzen...ohne zutun. 2. Kann sein, ich mag imo die PF von FreeBSD, wenn ich noch mehr Performance brauche ist eine CPU eh nicht die erste Wahl (und somit auch kein Allround OS) 3. Teile wurden übernommen, aber manche haben Performance Einbußen, andere sind kontrovers...na Du weisst wie das in OSS-Gruppen ist 4. Ja deshalb darf Nichtmal mehr AlpineLinux grsecurity mehr nutzen, Nichtmal als Abonnent darfst Du die Quellen an andere abgeben.
zu 2. Da ist natürlich 'was dran. zu 3. Hast du zufällig 1-2 Beispiele parat? Wär' total dufte. zu 4. Das ist zwar doof, aber irgendwie kann ich es grsecurity auch nicht wirklich übel nehmen. Scheinbar hatten sie zu viele undankbare Trittbrettfahrer und kein funktionierendes Geschäftsmodell. Trotzdem muss ich ihnen ihre Art des Umgangs mit der Community, Feindseligkeiten und Methoden übel nehmen...
Ich danke deiner Antworten wegen und wünsche frohe Festtage.
Hat HardenedBSD denn auch vorkompilierte Pakete wie FreeBSD seit pkgng? Oder gibt es nur modifizierte Ports?
Es gibt auch Pakete.
Die Firewalls aus FreeBSD sind schön und gut. IPF wirkt wie ein totes Pferd. pf genießt unter FreeBSD zwar SMP-Unterstützung, im Gegensatz zu OpenBSD. Technologisch gesehen, finde ich NPF (NetBSD) und nftables/netfilter (Linux) interessanter und zukunftsfähiger, da i.A. performanter.
Also wenn ich bei FreeBSD an Firewall (Paketfilter) denke, denke ich primär an ipfw. IPFilter ist nicht mehr so ganz auf Höhe der Technik (kann natürlich in bestimmten Szenarien trotzdem ausreichend sein) und ist eher aus Kompatiblitätsgründen noch vorhanden (IPFilter ist ja nicht FreeBSD-exklusiv). Also realistischerweise stellt sich unter FreeBSD eher die Frage ob pf oder ob ipfw.
Warum werden die Sicherheitsfeatures eigentlich nicht direkt in FreeBSD eingebaut? Sind sie nicht fertig? Zu große Performance-Einbußen? Wer sträubt sich bei FreeBSD gegen eine Implementierung? Werden ausgewählte Features migriert?
Zu letzterem kann man sagen: Ja. Es finden auch Dinge von HardenedBSD nach FreeBSD zurück.
Ansonsten spielen natürlich viele Dinge eine Rolle, warum es zwei verschiedene Systeme gibt. Manche Security-Features brechen z.B. die Kompatiblität. Dinge die unter FreeBSD laufen laufen unter HardenedBSD nicht so ohne Weiteres. Das betrifft auch solche Sachen wie Browser und nicht nur unbedingt exotisches Zeug. Manche Security-Maßnahmen sind auch umstritten ob ihrer Wirksamkeit. Insofern ist es schon sinnvoll da ein Fork zu haben, um ein breiteres Spektrum an Bedürfnissen befriedigen zu können. Wobei hierbei auch ein Vorteil ist, dass HardenedBSDFreeBSD folgt und keine echte Abspaltung ist wie seinerzeit OpenBSD.
Ich weiß nicht, wie ich das finden soll. Machen die das, damit Kees Cook & Co Features aus grsecurity (oder abgeschwächte Versionen) nicht peu à peu nach linux-master portieren können?
Die grsecurity-Leute sind eh recht angepisst. Ja auch weil Zeug es nicht in den offiziellen Kernel schafft. Dabei liegen die Gründe ähnlich wie bei FreeBSD vs. HardenedBSD. Manche Sachen wollen die Linuxer halt nicht im Kernel, weils dann Sachen kaputt oder zu kompliziert hat und/oder auch der Nutzen zweifelhaft ist. Das zweite (und sicherlich auch wichtigere) Ding ist halt, dass viele kommerzielle Firmen zwar gerne grsecurity verwenden aber nichts dazu beitragen und dann noch dreist mit hardened-with-grsecurity werben. Das ist das "Grundrauschen" was Du in der Thematik schon mal drin hast. Unter diesem Lichte betrachtet ist der Wechsel zur GPLv3 ja durchaus in gewisserweise konsequent.
zu 2. Du hast natürlich Recht. Allerdings sehe ich IPFilter als ein Relikt vergangener Dekaden an. Wie viele Nutzer hat das Zeug noch? Warum wird das nicht mal deprecated oder gleich entfernt? Wer wartet das noch? FreeBSD bietet im Gegensatz zu Linux doch eigentlich keine strikten Kompatibilitätsgarantien zwischen Major-Releases, oder?
zu 3. Ich denke, dass du Recht hast: Es braucht für solche Dinge einen Fork, der möglichst nah am Upstream bleibt. Leider wirken sich die Verbesserungen fast kaum auf die Masse der Nutzer aus.
Hast du zufällig Beispielfeatures parat, welche (nicht) zurück portiert werden/worden sind?
Theo de Raadt hat sich schon das ein oder andere Mal verärgert über ihm nicht nachvollziehbare Entscheidungen des FreeBSD-Projektes geäußert, welche mit geringem Aufwand große (Sicherheits-)Gewinne gebracht hätten. Ich finde leider gerade nicht mehr wo/wann das gewesen sei. Ich glaube mich zu erinnern, dass er Unverständnis kund getan hatte, wie getrandom, arc4random, OpenSSH, LibreSSL, Hardening-Vorkehrungen und anderer OpenBSD-Kram in FreeBSD (aber auch Linux, siehe getentropy) implementiert wurden, d.h. teils mit Inkompatibilitäten, stark abgeschwächt, abschlatbar, keine Entfernung alter Crypto wie RC4 und DES3 etc.pp. Er ging sogar soweit, zu sagen, dass es scheinbar eine Gewalt im Entwicklungsumfeld von FreeBSD zu existieren vermag, die solche Entscheidungen absichtlich torpediert oder behindert. Er spielt dabei auf die (ehemalige?) Nähe des Projektes zur NSA und anderen Sicherheitsbehörden an. GewisseEinschätzungen Poul-Henning Kamps reihen sich hier nahtlos ein. FreeBSD muss sich ja auch an Exportrestriktionen der USA für Crypto halten, während OpenBSD aus Kanada das nie musste.
zu 4. Deine Enschätzungen hierzu klingen plausibel, und decken sich im Wesentlichen mit meinen.
Ich danke deiner Antworten wegen und wünsche frohe Festtage.
Nicht zu vergessen das auch FreeBSD direkt davon profitiert, da durchaus einige Sachen nach FreeBSD zurück wandern.
Und warum werden diese Technologien nicht gleich direkt für FreeBSD entwickelt? Gibt's da andere Entwickler, die etwas dagegen haben? Das kann ich mir nicht so recht vorstellen. Den Linux Kernel kann man ja auch ziemlich gezielt mit diversen Features compilieren oder sie einfach weglassen.
Man könnte meinen, die Entwickler möchten sich durch die Abspaltung profilieren.
HardenedBSD ist ein sehr gutes Projekt. Es ist stets nah dran an FreeBSD und erweitert es um sinnvolle Sicherheitsfunktionen/Mitigations/gehärtete_Voreinstellungen.
Bei erhöhten Sicherheitsbedarf lässt es sich so sehr gut anstelle von FreeBSD einsetzen.
Nicht zu vergessen das auch FreeBSD direkt davon profitiert, da durchaus einige Sachen nach FreeBSD zurück wandern.
Was hebt HardenedBSD von OpenBSD ab?
In erster Linie daß es ein modifiziertes FreeBSD ist. D.h. es bringt den riesigen Ports-Tree mit, der bei OpenBSD doch erheblich kleiner ausfällt. HardenedBSD nimmt auch hier Härtungen vor, jedoch muß man im Zweifel schauen, welche Ports von den nicht-generischen Härtungen betroffen sind.
Außerdem hat es alle Treiber, die FreeBSD 12 auch hat. Da gibt es teilweise auch erhebliche Unterschiede zu Open. Der Benutzer hat die Möglichkeit, eine von drei verschiedenen Firewalls (IPFW, Pf, IPF) einzusetzen, während OpenBSD nur eine hat (Pf - allerdings in einer in vielen Dingen wesentlich moderneren Version). Usw., usf.
Was die Sicherheitsfeatures angeht, bietet das Projekt selbst einen Vergleich: https://hardenedbsd.org/content/easy-feature-comparison
Das mit dem PF von FreeBSD zu OpenBSD ist so eine Sache, zwar ist der PF von OpenBSD etwas weiter, jedoch ist er nicht SMP-faehig wie der PF von FreeBSD.
Du hast noch ZFS vergessen
Ein paar Fragen & Anmerkungen:
1. Hat HardenedBSD denn auch vorkompilierte Pakete wie FreeBSD seit pkgng? Oder gibt es nur modifizierte Ports?
Wie viele davon laufen ohne weiteres Zutun?
2. Die Firewalls aus FreeBSD sind schön und gut. IPF wirkt wie ein totes Pferd. pf genießt unter FreeBSD zwar SMP-Unterstützung, im Gegensatz zu OpenBSD.
Technologisch gesehen, finde ich NPF (NetBSD) und nftables/netfilter (Linux) interessanter und zukunftsfähiger, da i.A. performanter.
3. Warum werden die Sicherheitsfeatures eigentlich nicht direkt in FreeBSD eingebaut? Sind sie nicht fertig? Zu große Performance-Einbußen? Wer sträubt sich bei FreeBSD gegen eine Implementierung? Werden ausgewählte Features migriert?
4. Ich wusste gar nicht, dass das grsecurity/PaX-Team um Brad Spengler, welche CFI in Form von RAP entwickelt haben, ihr Zeug inzwischen patentieren und eine GPL3-lizensierte Toolchain voraussetzen. Zitat:
Ich weiß nicht, wie ich das finden soll. Machen die das, damit Kees Cook & Co Features aus grsecurity (oder abgeschwächte Versionen) nicht peu à peu nach linux-master portieren können?1. Ja haben sie, installieren, nutzen...ohne zutun.
2. Kann sein, ich mag imo die PF von FreeBSD, wenn ich noch mehr Performance brauche ist eine CPU eh nicht die erste Wahl (und somit auch kein Allround OS)
3. Teile wurden übernommen, aber manche haben Performance Einbußen, andere sind kontrovers...na Du weisst wie das in OSS-Gruppen ist
4. Ja deshalb darf Nichtmal mehr AlpineLinux grsecurity mehr nutzen, Nichtmal als Abonnent darfst Du die Quellen an andere abgeben.
zu 2. Da ist natürlich 'was dran.
zu 3. Hast du zufällig 1-2 Beispiele parat? Wär' total dufte.
zu 4. Das ist zwar doof, aber irgendwie kann ich es grsecurity auch nicht wirklich übel nehmen. Scheinbar hatten sie zu viele undankbare Trittbrettfahrer und kein funktionierendes Geschäftsmodell. Trotzdem muss ich ihnen ihre Art des Umgangs mit der Community, Feindseligkeiten und Methoden übel nehmen...
Ich danke deiner Antworten wegen und wünsche frohe Festtage.
IPFilter ist nicht mehr so ganz auf Höhe der Technik (kann natürlich in bestimmten Szenarien trotzdem ausreichend sein) und ist eher aus Kompatiblitätsgründen noch vorhanden (IPFilter ist ja nicht FreeBSD-exklusiv).
Also realistischerweise stellt sich unter FreeBSD eher die Frage ob pf oder ob ipfw.Zu letzterem kann man sagen: Ja. Es finden auch Dinge von HardenedBSD nach FreeBSD zurück.
Ansonsten spielen natürlich viele Dinge eine Rolle, warum es zwei verschiedene Systeme gibt. Manche Security-Features brechen z.B. die Kompatiblität. Dinge die unter FreeBSD laufen laufen unter HardenedBSD nicht so ohne Weiteres. Das betrifft auch solche Sachen wie Browser und nicht nur unbedingt exotisches Zeug.
Die grsecurity-Leute sind eh recht angepisst.Manche Security-Maßnahmen sind auch umstritten ob ihrer Wirksamkeit.
Insofern ist es schon sinnvoll da ein Fork zu haben, um ein breiteres Spektrum an Bedürfnissen befriedigen zu können. Wobei hierbei auch ein Vorteil ist, dass HardenedBSD FreeBSD folgt und keine echte Abspaltung ist wie seinerzeit OpenBSD.
Ja auch weil Zeug es nicht in den offiziellen Kernel schafft. Dabei liegen die Gründe ähnlich wie bei FreeBSD vs. HardenedBSD. Manche Sachen wollen die Linuxer halt nicht im Kernel, weils dann Sachen kaputt oder zu kompliziert hat und/oder auch der Nutzen zweifelhaft ist.
Das zweite (und sicherlich auch wichtigere) Ding ist halt, dass viele kommerzielle Firmen zwar gerne grsecurity verwenden aber nichts dazu beitragen und dann noch dreist mit hardened-with-grsecurity werben.
Das ist das "Grundrauschen" was Du in der Thematik schon mal drin hast. Unter diesem Lichte betrachtet ist der Wechsel zur GPLv3 ja durchaus in gewisserweise konsequent.
zu 1. Das ist prima. Hätte ich nicht vermutet.
zu 2. Du hast natürlich Recht. Allerdings sehe ich IPFilter als ein Relikt vergangener Dekaden an. Wie viele Nutzer hat das Zeug noch? Warum wird das nicht mal deprecated oder gleich entfernt? Wer wartet das noch? FreeBSD bietet im Gegensatz zu Linux doch eigentlich keine strikten Kompatibilitätsgarantien zwischen Major-Releases, oder?
zu 3. Ich denke, dass du Recht hast: Es braucht für solche Dinge einen Fork, der möglichst nah am Upstream bleibt. Leider wirken sich die Verbesserungen fast kaum auf die Masse der Nutzer aus.
Hast du zufällig Beispielfeatures parat, welche (nicht) zurück portiert werden/worden sind?
Theo de Raadt hat sich schon das ein oder andere Mal verärgert über ihm nicht nachvollziehbare Entscheidungen des FreeBSD-Projektes geäußert, welche mit geringem Aufwand große (Sicherheits-)Gewinne gebracht hätten. Ich finde leider gerade nicht mehr wo/wann das gewesen sei.
Ich glaube mich zu erinnern, dass er Unverständnis kund getan hatte, wie getrandom, arc4random, OpenSSH, LibreSSL, Hardening-Vorkehrungen und anderer OpenBSD-Kram in FreeBSD (aber auch Linux, siehe getentropy) implementiert wurden, d.h. teils mit Inkompatibilitäten, stark abgeschwächt, abschlatbar, keine Entfernung alter Crypto wie RC4 und DES3 etc.pp. Er ging sogar soweit, zu sagen, dass es scheinbar eine Gewalt im Entwicklungsumfeld von FreeBSD zu existieren vermag, die solche Entscheidungen absichtlich torpediert oder behindert. Er spielt dabei auf die (ehemalige?) Nähe des Projektes zur NSA und anderen Sicherheitsbehörden an.
Gewisse Einschätzungen Poul-Henning Kamps reihen sich hier nahtlos ein. FreeBSD muss sich ja auch an Exportrestriktionen der USA für Crypto halten, während OpenBSD aus Kanada das nie musste.
zu 4. Deine Enschätzungen hierzu klingen plausibel, und decken sich im Wesentlichen mit meinen.
Ich danke deiner Antworten wegen und wünsche frohe Festtage.
Und warum werden diese Technologien nicht gleich direkt für FreeBSD entwickelt? Gibt's da andere Entwickler, die etwas dagegen haben? Das kann ich mir nicht so recht vorstellen.
Den Linux Kernel kann man ja auch ziemlich gezielt mit diversen Features compilieren oder sie einfach weglassen.
Man könnte meinen, die Entwickler möchten sich durch die Abspaltung profilieren.
Warum wohl machen manche Menschen etwas das sie machen wollen ohne sich mit anderen abzustimmen? Weil sie es können!
Sonst hätten wir nur ein OS und fertig