nicht angemeldet
Hi!
Dieser Punkt ist klar - eine größere Änderung als einen Architektur-Wechsel kann man eh kaum vornehmen.
Ja? Ich hielt das immer für eine der kleineren Läßlichkeiten, da mitunter harte finanzielle Gründe entgegenstehen. Oder hast Du immer Gelegenheit Dein Programm mal eben auf der 64-Node-UltraSparc in Deinem Keller auszuprobieren? Ja, genau, die Kiste zwischen der vollausgebauten Octane und der 32er AS/400!
;-)
Nein, einen solchen habe auch ich leider nicht im Keller herumstehen, zumal ich mit dieser Architektur noch keinerlei Erfahrungen vorweisen kann. Aber vielleicht wird sich ja dies noch irgendwann ändern.
Eine kleine Frage nebenbei: Welche Vorteile bietet der Einsatz der Sparc-Architektur?
Viel schlimmer sind z.B. grundlose Updates, da kräuseln sich mir regelmäßig die Fußnägel.
Ja, solche möchte ich auch vermeiden, sodass einer der ersten Schritte erstmal die Anpassung der USE-Flags mit »-*« angepasst, ferner werden alle benötigten USE-Flags per Hand hinzugefügt. Außerdem wird die package.mask auch ziemlich groß werden ;-)
Mit diesen Kernelpatches meinst du wohl SELinux, GrSecurity und Konsorten?
Ja. Inklusive "Konsorten".
Bisher habe ich mich eigentlich nur mit GrSecurity beschäftigt und damit gute Erfahrungen gemacht, da mich dessen Schutzmaßnahmen soweit doch sehr überzeugen.
Auf welche spielst Du genau an?
--> Jeder Benutzer kann nur seine eigenen Prozesse sehen
--> Kein Zugriff auf dmesg
--> Logen von mount/umount
--> Zufällige Vergabe der Quellports (dazu ist auch ein Artikl im aktuellen Linux-Magazin)
--> Die ganzen RBAC-Features.
Das wären jetzt mal die wichigsten, die mir auf die schnelle in den Sinn kommen.
Grüße,
Fabian St.