"pkg audit" fürs Basissystem

Hallo,

mit meinem Dutzend Servern und mehr Jails ist es ja noch halbwegs
überschaubar..

.. und der FreeBSD Security Advisories gibt es nicht so viele, so daß ich
bis jetzt immer noch "halbwegs" mit manueller Suche nach Schwachstellen im
Basissystem auskomme.

Trotzdem, in etwa kam ich zu ähnlichen Ideen wie hier:

https://wiki.freebsd.org/201309DevSummit/Security

The other problem with VuXML -- should we add FreeBSD SAs to VuXML?
Nothing uses VuXML for the base system. FreBSD Update for uname components
will not update the kernel version so the version apparently doesn't
change Should we add /etc/freebsd_release ? (Previous suggestions lead to
huge bikeshed...)

Und von dann weiter.

So lange man was "für sich" macht - und so hatte ich - ohne die Quelle zu
kennen, angefangen - hat man den Vorteil, sich die Farbe des Radschuppens
selber aussuchen zu können.

Andererseits "erschlägt" man damit wahrscheinlich seine eigenen Probleme,
nicht die der anderen.

Ich habe also für mich selbst angefangen..

1. Ich benutze Subversion für /usr/src-Checkouts.

Daher kann ich svn info benutzen, in meinrm Fall, ich erzeuge bei jedem
Build ein Template für die Jails, da wird die svn info einfach in ein
/etc/src_svn_info geschrieben.

Könnte Teil von "make distribution" und mergemaster werden?

2. Ich habe kleine Skripts, kernelversion und baseversion, die SVN
revision numbers "ausspucken".

kernelversion nutzt den Output von "uname -t",

baseversion die /etc/src_svn_info-Datei.

3. Ich habe eine kleine Datei, in der ich die SA erfasse - allerdings
"gewichtet" nach meinen eigenen Kriterien (was benutze ich, wie offen sind
die betroffenen Systeme, Kontakt zur "Außenwelt" etc.)

# cat base_security.cfg
# Date SA part impact SVN rev
2014-01-14 FreeBSD-SA-14:02.ntpd user DoS 260641
2013-09-10 FreeBSD-SA-13:12.ifioctl kern serious 255443
2013-09-10 FreeBSD-SA-13:11.sendfile kern low 255443
apache22_enable
2013-07-26 FreeBSD-SA-13:07.bind user crash 253695
named_enable
2013-06-18 FreeBSD-SA-13:06.mmap kern low 251902
security.bsd.unprivileged_proc_debug
2013-04-02 FreeBSD-SA-13:04.bind user DoS 248808
named_enable
2013-04-02 FreeBSD-SA-13:03.openssl user low 248272
apache22_enable
2013-02-19 FreeBSD-SA-13:02.libc user low 246357

Das ist noch kein XML, aber das läßt sich machen. (Ich mag selten XML,
aber die Welt will es so;-)

"pkg audit" wichtet nicht, und unterscheidet auch nicht, ob das Paket
benutzt wird oder nicht - das kann also wegfallen (meine
named_enable-Variablen im Jail können getestet werden, aber das ist "works
for me").

4. Ich habe ein anderes Skript base-audit, welches die Konfig, baseversion
und kernelversion benutzt, um pro Host/Jail die SAs ausspuckt, die noch
nicht gepatcht sind.

Ich teste aber auch gegen die letzte Spalte (rc.conf oder
sysctl-Variablen - aber das ist eher "works for me", wie gesagt.

Im Prinzip ist das für mich brauchbar.

Für allgemeine Builds wäre dann noch folgendes zu bemerken:

5. "Can't rely on eg. SVN metadata in uname -a -- it won't always be
present."

SAs benutzen die Subversion revision - wie kann man die "allgemein" in ein
System einbauen? Wann ist die revision no nicht vorhanden?

Kann man dann die og. kernelversion und baseversion-Skripts modifizieren,
die Info von "anderswo" zu bekommen?

Worst case: "Keine Ahnung, wie dieses System gebaut wurde. Bitte checke
manuell http://www.freebsd.org/security/advisories.html"

Natürlich darf jeder mit FreeBSD machen, was er will (modizieren ohne
Ende, keine Build-Info offenlegen wollen) - dann muß er aber wohl selbst
dafür sorgen, wie er solche Probleme in den Griff kriegt? Zum Beispiel
seine eigene Suite solcher Skripte.Konfigs/SA bereitstellen?

6. Ich denke, man sollte beim Bauen neben der Subversion-Info auch die
src.conf und KERNELCONF abspeichern, um beim Test auf das Vorhandensein
von Modulen testen zu können.

options INCLUDE_CONFIG_FILE

Beim make buildkernel würde dabei helfen..

Wie gesagt, ich könnte mir vorstellen, daß diese Informationen (svn info,
src.conf, KERNELCONF) Teil von "make distribution" und "mergemaster"
werden.

Eventuell abgespeichert in ein Extra-Verzeichnis wie /etc/build.

Ich frage mal vorsichtig hier an, ob es sinnvoll ist, dies weiter zu
veröffentlichen, bevor die ganze "bikeshed"--Diskussion losgeht (und
möglicherweise hat der eine oder andere von Euch diese schon mal erlebt?)

Es grüßt
Peter

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 28 Feb 2014 - 01:30:19 CET