Wieder einmal habe ich mich dafür entschieden, /tmp noexec zu mounten.
Und wieder habe ich vergessen, das es dann u.a. mit apt zu Problemen führt:
apt-listchanges: Mailing root: apt-listchanges: news for rootgemeinschaft.de Preconfiguring packages ... Can't exec "/tmp/ca-certificates.config.126761": Permission denied at /usr/share/perl/5.14/IPC/Open3.pm line 186. open2: exec of /tmp/ca-certificates.config.126761 configure 20120623 failed at /usr/share/perl5/Debconf/ConfModule.pm line 59 (Reading database ... 50732 files and directories currently installed.) Preparing to replace ca-certificates 20120623 (using .../ca-certificates_20130119_all.deb) ... Unpacking replacement ca-certificates ... Processing triggers for man-db ... Setting up ca-certificates (20130119) ... Processing triggers for ca-certificates ... Updating certificates in /etc/ssl/certs... 7 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d....done.
Leider ist es nämlich so, dass apt post install scripts in /tmp ausführen möchte. Man muss deshalb dem Package System mitteilen, das es bitte einen anderen Pfad benutzen möchte. Das mache ich so:
In /apt/apt.conf.d/ ein File 50extracttemplates mit folgendem Inhalt
APT
{
ExtractTemplates
{
TempDir "/var/local/tmp";
};
};
Natürlich muss /var/local/tmp existieren und könnte auch üblicher auch /var/tmp lauten, ist Geschmackssache. Äbrigens ist noexec alleine nicht optimal, erst durch gleichzeitiges nosuid hat man auch die üblichen Tricks der Angreiferscripts ausgehebelt. Die Zeile in der /etc/fstab sollte also so aussehen:
/tmp ext4 noexec,nosuid 0 2
Steve Kemp von debian-administration.org macht das anders, und zwar so, wie man es auch zu Fuß machen würde, mit vor dem apt-get ausführen /tmp mit exec mounten, danach dann wieder zurück zu noxec.
Add the following to the file /etc/apt/apt.conf:
DPkg::Pre-Invoke{"mount -o remount,exec /tmp";};
DPkg::Post-Invoke {"mount -o remount /tmp";};
Wie so oft gibt es mehrere Möglichkeiten. Für welche man sich entscheidet ist letztlich egal, die Lösung in der apt.conf ist vielleicht die am kompatibelste ... Näheres dazu bei www.debian-administration.org/article/Making_/tmp_non-executable und bei wrightsolutions.wordpress.com/2010/01/11/securing-tmp-and-noexec-apt-considerations/
"das" und "dass", kennst du den Unterschied?
Danke für den überaus kreativen Hinweis auf den Tippfehler.
Kein Tippfehler, sondern mehrfache Unwissenheit. Ich bin der Meinung, dass jemand, der seine Gedanken einer großen Öffentlichkeit zugänglich macht, nicht das Handwerkliche bzw. die sprachlichen Grundlagen vernachlässigen sollte. Entschuldigung, aber mich regt sowas auf.
Mich regen nicht zum Thema gehörende Kommentare viel mehr auf.
Wenn ich in Foren stöbere, dann sehe ich des Öfteren viel ärgerliche syntaktische und semantische Fehler. Sprache verändert sich, da kannst auch du als Lehrer nichts dagegen tun
Ist die Variante von "Steve Kemp" nicht etwas unsicher? Gut es ist unwarscheinlich, das ein Hack genau zum zeitpunkt eines Updates geschieht. Aber es ist dennoch eine vermeidbarer fehler oder?
Nee, wieso? Gerade bei der Lösung bleibt doch /tmp immer noexec. Was die Frag ist, ob es auch ausreicht, oder ob es noch andere Stellen gibt, wo das Packagesystem etwas in /tmp ausführen möchte
Was soll eigentlich noexec bringen?
echo 'echo "ich bin ein boeses script"' > /tmp/test.sh ;chmod +x /tmp/test.sh; bash /tmp/test.sh
ich bin ein boeses script
Das ist einfach ein Baustein, noexec allein, auch mit nosuid zusammen sind kein Allheilmittel. Bedenke, wenn ein Angreifer die bash ausführen kann ist's eh zu spät.