Warum ist ein automatische apt-get unsicher??

[kendo]

Auf:
Automatic update of packages using cron-apt -- Debian Admin

steht, das das, was ich gern machen würde (automatisches "apt-get update" via cron) unsicher ist - aber WARUM??

Weil jemand mir eine falsche sources.list unterjubelt und dann per meinem cron seine eigenen pakete einspielt? (Das kann mir doch auch manuell passieren...)

Und was, wenn ich an ungewöhnlicher stelle ein script platziere - welches ich dann via cron ansteuere, das erst eine hardcoded sources.list schreibt und dann den update startet. Ist das sicherer?

Warum ist ein automatisches update denn nun "NOT recommended"??

 

[Roger Wilco]

Viel einfacher: Ein Update der glibc ist defekt, weil der Maintainer geschlafen hat, und wird automatisch bei dir eingespielt, während du 4 Wochen im wohlverdienten Urlaub ohne Internetverbindung sitzt.
Sehr erstrebenswert, oder?

 

[Firewire2002]

Ein apt-get update" spielt keine Updates ein, sondern holt jediglich die Package List von den Servern.
Das Script von dem auf der verlinkten Page gesprochen wird simuliert das einspielen der Updates jediglich.
Daher geht eigentlich keine Gefahr von defekten Packages aus.

 

[Guin]

Oder es muss bei einem Update mal von der Standardantwort abgewichen werden (ab und an muss man sich ja mal fuer y oder n entscheiden), dann laeuft der entsprechende Dienst (und die, die davon abhaengen) auch nicht mehr.

Wenn dir jemand schon eine geaenderte source.list unterschieben kann, ist dein Server eh schon auf dem absteigenden Ast

[edit wegen Firewire2002]
ähm, ja natuerlich. aptitude update && aptitude -fy upgrade

 

[Firewire2002]

Für alle die zu Faul sind die Page oben zu besuchen:

#!/bin/bash
#
# Cron Script - run from /etc/crontab or /etc/cron.daily
#
# Runs “apt-get update” and prints the output of a simulated
# dist-upgrade if new packages are found.

if [[ `apt-get update 2>&1 | grep Get` ]]; then
	if [[ `apt-get –simulate dist-upgrade 2>&1 | grep Inst` ]]; then
		apt-get –simulate dist-upgrade
	fi
fi

Da steht weder was vom Parameter "-y" für yes, noch "-f" für force.
Im Gegenteil da steht sehr deutlich "--simulate".

 

[elias5000]

Also dieses Script würde ich als Admin der Repos auch nicht "recommended" finden.
Die Rechner einer Dist/Release fahren cron.daily üblicherweise um die exakt gleiche Uhrzeit ab - das ganze auch noch koordiniert per ntp!
Das ist im Prinzip ein ausgewachsener DDoS, wenn das alle machen.

Yum kennt BTW für sowas einen Parameter, der es für eine zufällige Zeit zwischen 0 und k Minuten warten lässt, bevor etwas passiert.
Das Script sollte also vor dem Abfahren von apt noch ein zufälliges sleep einlegen. Die Admins der Mirrors werden dankbar sein...

Edit: Die Sicherheitsproblematik hat man natürlich auch dann, wenn man manuell Pakete einspielt. Wenn diese nicht signiert sind, kann man beim manuellen Update auch nicht entscheiden, ob die korrekt sind. Und ein automatisches Update sollte unsignierte Pakete bzw. Pakete mit einer Signatur, die nicht mit einem als vertrauenswürdig eingestuften Key erzeugt wurden, gar nicht erst zulassen. (Ein manuelles Update auch nicht.)
Wenn man auf vertrauenswürdigen Signaturen besteht, würde ich die Sicherheitsproblematik als eher gering einschätzen.

 

[Huschi]

@Firewire2002:
Die Verwirrung gab es wohl, weil es tatsächlich ein Programm cron-apt gibt, welches sich von dem kleinen Script deutlich unterscheidet.
(Siehe Debian: automatische Updates per cron-apt - huschi.net )

Grundsätzlich sollte man Updates immer gezielt und mit Zeit (also nicht kurz vor Dienstschluss) einspielen. cron-apt ist in sofern sinnvoll, weil es (bei täglicher Ausführung) innerhalb 24h über aktualisierte Pakete informiert. Das von mir genannte cron-apt läd zusätzlich die Pakete bereits runter ohne Installation. So ist ein manuelles Upgrade schnell und einfach umzusetzen.

huschi.