systemd 246: Spaß mit DHCPv6

[Friedemann Stoyan]

Kürzlich habe ich auf den systemd 246 upgedated. Der darin enthaltene
systemd-networkd weist folgendes Verhalten auf:

Bei jedem empfangenen IPv6 Router Advertisement (RA), in dem das
"OtherConfig"-Bit gesetzt ist, wird jedesmal der IPv6 DHCP-Client
gestartet, auch wenn das explizit nicht so gewollt ist:

[Network]
DHCP=ipv4

Das ist sogar im Manual dokumentiert. Doof ist nur, das der DHCP
Client auch eine IPv6 Non-temporary Address anfordern möchte. Das kann
natürlich schief gehen, wenn z.B. der DHCP Server keinen Adressbereich
konfiguriert hat. Dann hagelt es bei _jedem_ RA Fehlermeldungen im
Journal:

Aug 07 08:12:10 systemd-networkd[423]: wlp4s0: DHCPv6 error: No message of desired type

Wieso wird bei OtherConfig eine Adresse angefordert? Wenn ich das
möchte, muss ich das Managed-Bit im RA setzten. Da hat wohl einer den
RFC nicht richtig gelesen oder verstanden.

Da hilft nur ein Stillegen des DHCPv6 Clients:

[IPv6AcceptRA]
DHCPv6Client=false

Falls jemand auch diesen Effekt haben sollte…

mfg Friedemann

[Marc Haber]

Friedemann Stoyan <use...@ip6-mail.de> wrote:
>Kürzlich habe ich auf den systemd 246 upgedated. Der darin enthaltene
>systemd-networkd weist folgendes Verhalten auf:
>
>Bei jedem empfangenen IPv6 Router Advertisement (RA), in dem das
>"OtherConfig"-Bit gesetzt ist, wird jedesmal der IPv6 DHCP-Client
>gestartet, auch wenn das explizit nicht so gewollt ist:

Schön. Machst Du bitte einen Bugreport bei github? Der Entwickler, der
sich um systemd-networkd kümmert, liest echt ungerne Standards, lässt
sich die Dinge aber gerne erklären und macht dann auch was.

Grße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Tim Ritberg]

Am 08.08.20 um 13:53 schrieb Marc Haber:

> Friedemann Stoyan <use...@ip6-mail.de> wrote:
>> Kürzlich habe ich auf den systemd 246 upgedated. Der darin enthaltene
>> systemd-networkd weist folgendes Verhalten auf:
>>
>> Bei jedem empfangenen IPv6 Router Advertisement (RA), in dem das
>> "OtherConfig"-Bit gesetzt ist, wird jedesmal der IPv6 DHCP-Client
>> gestartet, auch wenn das explizit nicht so gewollt ist:
>
> Schön. Machst Du bitte einen Bugreport bei github? Der Entwickler, der
> sich um systemd-networkd kümmert, liest echt ungerne Standards, lässt
> sich die Dinge aber gerne erklären und macht dann auch was.
>

Pöttering? :-D

Systemd ist echt AMB, ich hoffe, IBM zieht dem bald den Stecker.

Tim

[Marc Haber]

Tim Ritberg <t...@server.invalid> wrote:
>Am 08.08.20 um 13:53 schrieb Marc Haber:
>> Friedemann Stoyan <use...@ip6-mail.de> wrote:
>>> Kürzlich habe ich auf den systemd 246 upgedated. Der darin enthaltene
>>> systemd-networkd weist folgendes Verhalten auf:
>>>
>>> Bei jedem empfangenen IPv6 Router Advertisement (RA), in dem das
>>> "OtherConfig"-Bit gesetzt ist, wird jedesmal der IPv6 DHCP-Client
>>> gestartet, auch wenn das explizit nicht so gewollt ist:
>>
>> Schön. Machst Du bitte einen Bugreport bei github? Der Entwickler, der
>> sich um systemd-networkd kümmert, liest echt ungerne Standards, lässt
>> sich die Dinge aber gerne erklären und macht dann auch was.
>>
>Pöttering? :-D

Nein, das macht er zum Glück nicht selbst.

>Systemd ist echt AMB, ich hoffe, IBM zieht dem bald den Stecker.

Dazu ist systemd schon zu weit, er macht nahezu alles besser als alles
was wir zuvor hatten.

Grüße

[Gerrit Heitsch]

On 8/8/20 3:56 PM, Marc Haber wrote:
> Tim Ritberg <t...@server.invalid> wrote:
>> Am 08.08.20 um 13:53 schrieb Marc Haber:
>>> Friedemann Stoyan <use...@ip6-mail.de> wrote:
>>>> Kürzlich habe ich auf den systemd 246 upgedated. Der darin enthaltene
>>>> systemd-networkd weist folgendes Verhalten auf:
>>>>
>>>> Bei jedem empfangenen IPv6 Router Advertisement (RA), in dem das
>>>> "OtherConfig"-Bit gesetzt ist, wird jedesmal der IPv6 DHCP-Client
>>>> gestartet, auch wenn das explizit nicht so gewollt ist:
>>>
>>> Schön. Machst Du bitte einen Bugreport bei github? Der Entwickler, der
>>> sich um systemd-networkd kümmert, liest echt ungerne Standards, lässt
>>> sich die Dinge aber gerne erklären und macht dann auch was.
>>>
>> Pöttering? :-D
>
> Nein, das macht er zum Glück nicht selbst.
>
>> Systemd ist echt AMB, ich hoffe, IBM zieht dem bald den Stecker.
>
> Dazu ist systemd schon zu weit, er macht nahezu alles besser als alles
> was wir zuvor hatten.

Er macht einiges aber auch ziemlich schlecht.

Ich bevorzuge z.B. immer noch die crontab statt einer Sammlung von timer
files.

Gerrit

[Alexander Schreiber]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Friedemann Stoyan <use...@ip6-mail.de> wrote:
>>Kürzlich habe ich auf den systemd 246 upgedated. Der darin enthaltene
>>systemd-networkd weist folgendes Verhalten auf:
>>
>>Bei jedem empfangenen IPv6 Router Advertisement (RA), in dem das
>>"OtherConfig"-Bit gesetzt ist, wird jedesmal der IPv6 DHCP-Client
>>gestartet, auch wenn das explizit nicht so gewollt ist:
>
> Schön. Machst Du bitte einen Bugreport bei github? Der Entwickler, der
> sich um systemd-networkd kümmert, liest echt ungerne Standards, lässt
> sich die Dinge aber gerne erklären und macht dann auch was.

Dann sollte dieser Entwickler vielleicht direkt einen Erklärbären
einstellen. So zum Standards vorlesen und so ... *seufz*

Aber immerhin nicht beratungsresistent, das ist schon viel wert.

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

[Arno Welzel]

Gerrit Heitsch:

> On 8/8/20 3:56 PM, Marc Haber wrote:

[...]

>> Dazu ist systemd schon zu weit, er macht nahezu alles besser als alles
>> was wir zuvor hatten.
>
> Er macht einiges aber auch ziemlich schlecht.
>
> Ich bevorzuge z.B. immer noch die crontab statt einer Sammlung von timer
> files.

Welches System hat denn nur "die crontab"? Das ist doch eher eine
Sammlung aus /etc/cron.hourly, /etc/cron.daily, /etc/cron.monthly und
zusätzlich noch für jeden User potentiell eine eigene crontab.


--
Arno Welzel
https://arnowelzel.de

[Gerrit Heitsch]

Natürlich ist das per User.. und mit 'crontab -e' so schön einfach zu
editieren. Wobei man aufpassen muss. 'crontab -' und 'crontab -r'
löschen dir die crontab ohne nachzufragen. Backups mit 'crontab -l >
cron_backup' sind anzuraten.

Und bitte nicht cron und anacron verwechseln. Was du beschreibst sieht
eher nach anacron aus.

Gerrit

[Marc Haber]

Gerrit Heitsch <ger...@laosinh.s.bawue.de> wrote:
>Ich bevorzuge z.B. immer noch die crontab statt einer Sammlung von timer
>files.

Daran hindert Dich auch keiner. Ich bin es echt langsam leid dass jede
Diskussion über die Verwendung von systemd unweigerlich in derselben
Grundsatzdiskussion landet.

[Tim Ritberg]

Am 08.08.20 um 22:11 schrieb Marc Haber:

> Gerrit Heitsch <ger...@laosinh.s.bawue.de> wrote:
>> Ich bevorzuge z.B. immer noch die crontab statt einer Sammlung von timer
>> files.
>
> Daran hindert Dich auch keiner. Ich bin es echt langsam leid dass jede
> Diskussion über die Verwendung von systemd unweigerlich in derselben
> Grundsatzdiskussion landet.
>

Es ist ja auch ein grundsätzliches Problem. Und man wird gezwungen. Des
ändert sich vielleicht, wenn es einen erfolgreichen Herausforderer gibt.


Tim

[Kay Martinen]

Am 08.08.20 um 23:00 schrieb Tim Ritberg:

> Am 08.08.20 um 22:11 schrieb Marc Haber:

>> Diskussion über die Verwendung von systemd unweigerlich in derselben
>> Grundsatzdiskussion landet.

Einer; auch von dir IMHO gern mal zitierten; Usenet-Tradition nach:

Du mußt es ja weder lesen noch kommentieren - oder gar verteidigen. :-)

> Es ist ja auch ein grundsätzliches Problem. Und man wird gezwungen. Des
> ändert sich vielleicht, wenn es einen erfolgreichen Herausforderer gibt.

Wer könnte denn das sein? Ein Microsoftd? :-)=)

SCNR


Kay

--
Posted via leafnode

[Arno Welzel]

Gerrit Heitsch:

Ja, anacron ist auch im Spiel, was die Sache mit cron nicht einfacher
macht, wann man einfach nur wissen will, welche zeitgesteuerten Prozesse
systemweit und unabhängig vom User als nächstes zur Ausführung anstehen.

[Arno Welzel]

Tim Ritberg:

Wieso wird man gezwungen? Existiert cron bei aktuellen Distributionen
nicht mehr?

[Tim Ritberg]

Am 09.08.20 um 00:53 schrieb Arno Welzel:

> Wieso wird man gezwungen? Existiert cron bei aktuellen Distributionen
> nicht mehr?

Ich meinte das allgemein. Aber vielleicht kommt ein Maintainer auf die
Idee, eine Task-Steuerung würde reichen.

Tim

[Gerrit Heitsch]

Das ist bei systemd eher noch schwerer weil man da die ganze Sammlung
timer files durchsehen muss um sich ein Bild zu machen.

Gerrit

[Arno Welzel]

Gerrit Heitsch:

> On 8/9/20 12:51 AM, Arno Welzel wrote:

[...]

>> Ja, anacron ist auch im Spiel, was die Sache mit cron nicht einfacher
>> macht, wann man einfach nur wissen will, welche zeitgesteuerten Prozesse
>> systemweit und unabhängig vom User als nächstes zur Ausführung anstehen.
>
> Das ist bei systemd eher noch schwerer weil man da die ganze Sammlung
> timer files durchsehen muss um sich ein Bild zu machen.

Nein, wieso?

systemctl list-timers

[Gerrit Heitsch]

Kommt nicht an 'crontab -l' ran.

In einen normalen, 80 Zeichen breiten Terminal wird die Ausgabs nicht
umgebrochen sondern abgeschnitten. Schonmal Mist.

Dann listet er, auch wenn ich normaler User bin, Timer auf die dem
System, also root gehören. Auch das ist Mist, einen normalen User geht
das nichts an.

Ohne --all bekommst du inaktive nicht zu sehen.

Dann kommt noch dazu, daß ich der Output von 'crontab -l' eine
verwendbare contrab ist. Ich kann sie wieder einlesen. Gut für Backups
wenn mehrere Leute an den Einträgen rumfummeln.

Ne du, das läuft unter 'verschlimmbessert'.

Gerrit

[Arno Welzel]

Gerrit Heitsch:

> On 8/9/20 11:11 PM, Arno Welzel wrote:
>> Gerrit Heitsch:
>>
>>> On 8/9/20 12:51 AM, Arno Welzel wrote:
>> [...]
>>>> Ja, anacron ist auch im Spiel, was die Sache mit cron nicht einfacher
>>>> macht, wann man einfach nur wissen will, welche zeitgesteuerten Prozesse
>>>> systemweit und unabhängig vom User als nächstes zur Ausführung anstehen.
>>>
>>> Das ist bei systemd eher noch schwerer weil man da die ganze Sammlung
>>> timer files durchsehen muss um sich ein Bild zu machen.
>>
>> Nein, wieso?
>>
>> systemctl list-timers
>
> Kommt nicht an 'crontab -l' ran.

Das zeigt hier schonmal nicht an, was in /etc/crontab steht und auch
nicht, was für andere User geplant ist, sondern nur für den User, der
crontab -l aufruft.

> In einen normalen, 80 Zeichen breiten Terminal wird die Ausgabs nicht
> umgebrochen sondern abgeschnitten. Schonmal Mist.

Deswegen kann man mit den Cursortasten scrollen, wie bei "less" üblich.

Wenn Du nur plain Text willst, egal ob das umgebrochen werden muss oder
nicht:

systemctl list-timers --no-pager

> Dann listet er, auch wenn ich normaler User bin, Timer auf die dem
> System, also root gehören. Auch das ist Mist, einen normalen User geht
> das nichts an.

Wieso soll der normale User nicht wissen dürfen, welche Kommandos
demnächst ausgeführt werden? Er darf ja auch allerlei Dateien lesen, die
nur root schreiben darf, auch /etc/crontab.

> Ohne --all bekommst du inaktive nicht zu sehen.

Dann schreibt man das halt dazu. Wo ist das Problem?

> Dann kommt noch dazu, daß ich der Output von 'crontab -l' eine
> verwendbare contrab ist. Ich kann sie wieder einlesen. Gut für Backups
> wenn mehrere Leute an den Einträgen rumfummeln.
>
> Ne du, das läuft unter 'verschlimmbessert'.

Ja, wenn man nur crontab will, will man nur crontab. Da ist *alles*
schlechter, egal welche technischen Verbesserungen das bieten könnte.

[Gerrit Heitsch]

On 8/10/20 12:09 PM, Arno Welzel wrote:
> Gerrit Heitsch:
>
>> On 8/9/20 11:11 PM, Arno Welzel wrote:
>>> Gerrit Heitsch:
>>>
>>>> On 8/9/20 12:51 AM, Arno Welzel wrote:
>>> [...]
>>>>> Ja, anacron ist auch im Spiel, was die Sache mit cron nicht einfacher
>>>>> macht, wann man einfach nur wissen will, welche zeitgesteuerten Prozesse
>>>>> systemweit und unabhängig vom User als nächstes zur Ausführung anstehen.
>>>>
>>>> Das ist bei systemd eher noch schwerer weil man da die ganze Sammlung
>>>> timer files durchsehen muss um sich ein Bild zu machen.
>>>
>>> Nein, wieso?
>>>
>>> systemctl list-timers
>>
>> Kommt nicht an 'crontab -l' ran.
>
> Das zeigt hier schonmal nicht an, was in /etc/crontab steht und auch
> nicht, was für andere User geplant ist, sondern nur für den User, der
> crontab -l aufruft.

Das ist auch korrekt so. Es geht einen normalen User nichts an was
andere User in ihrer crontab stehen haben.

>> In einen normalen, 80 Zeichen breiten Terminal wird die Ausgabs nicht
>> umgebrochen sondern abgeschnitten. Schonmal Mist.
>
> Deswegen kann man mit den Cursortasten scrollen, wie bei "less" üblich.

Man kann das bei 'less' tun, aber man muss nicht. Default ist Umbruch.
Kleiner, aber wichtiger Unterschied in der Benutzung.

> Wenn Du nur plain Text willst, egal ob das umgebrochen werden muss oder
> nicht:
>
> systemctl list-timers --no-pager

Das sollte der Default sein, wer einen Pager will kann ihn benutzen.

>> Dann listet er, auch wenn ich normaler User bin, Timer auf die dem
>> System, also root gehören. Auch das ist Mist, einen normalen User geht
>> das nichts an.
>
> Wieso soll der normale User nicht wissen dürfen, welche Kommandos
> demnächst ausgeführt werden? Er darf ja auch allerlei Dateien lesen, die
> nur root schreiben darf, auch /etc/crontab.

Geht ihn nichts an, ein normaler User darf viele Dinge nicht tun und
auch einige Dateien nicht lesen die root schreibt.

>> Ohne --all bekommst du inaktive nicht zu sehen.
>
> Dann schreibt man das halt dazu. Wo ist das Problem?

Das es schön wäre, wenn das der Default wäre?

>> Dann kommt noch dazu, daß ich der Output von 'crontab -l' eine
>> verwendbare contrab ist. Ich kann sie wieder einlesen. Gut für Backups
>> wenn mehrere Leute an den Einträgen rumfummeln.
>>
>> Ne du, das läuft unter 'verschlimmbessert'.
>
> Ja, wenn man nur crontab will, will man nur crontab. Da ist *alles*
> schlechter, egal welche technischen Verbesserungen das bieten könnte.

Nein, man könnte z.B., nur so angedacht... Die Ausgabe von systemctl
list-timers kompletter und wieder importierbar machen. So daß ich in der
Ausgabe wirklich ALLE Informationen über einen timer bekomme. Aktuell
kenne ich den Namen des Timers, habe aber keine Idee wozu der gut ist.
Meine crontabs haben Kommentare wenn es aus dem Aufruf nicht direkt
hervorgeht.

Paul Vixie hat bei der Programmierung von 'crond' und den
Supportprogrammen schon darüber nachgedacht wie das aussehen muss.

In manchen Details mögen die Timer besser sein, aber in der Gesamtheit
ist cron die bessere Lösung.


Ich hab auch eine Weile gebraucht bis ich systemd davon abhalten konnte
in meiner /etc/resolv.conf rumzuspielen. Auf einem System mit statischer
IP hat auch diese Datei statisch zu sein und die IP meines Nameservers
zu enthalten, nicht eine 127.x.y.z-Adresse.

Gerrit

[Arno Welzel]

Gerrit Heitsch:

> On 8/10/20 12:09 PM, Arno Welzel wrote:
>> Gerrit Heitsch:

[...]

>>> Kommt nicht an 'crontab -l' ran.
>>
>> Das zeigt hier schonmal nicht an, was in /etc/crontab steht und auch
>> nicht, was für andere User geplant ist, sondern nur für den User, der
>> crontab -l aufruft.
>
> Das ist auch korrekt so. Es geht einen normalen User nichts an was
> andere User in ihrer crontab stehen haben.

Auch root sieht nicht, was andere User in ihrer crontab stehen haben.
Der muss das für jeden User separat machen.

Abgesehen davon dürfte das Szenario, dass an einem Linux-System wirklich
mehrere echte Menschen mit ihrem eigenen Login real arbeiten, eher
selten vorkommen. Auf Servern will man in der Regel keine echten Nutzer
direkt zugreifen lassen und schon gar keine eigene Einträge in der
crontab anlegen lassen und bei Desktop-Systemen arbeitet in der Regel
nur eine Person mit dem Gerät.

>>> In einen normalen, 80 Zeichen breiten Terminal wird die Ausgabs nicht
>>> umgebrochen sondern abgeschnitten. Schonmal Mist.
>>
>> Deswegen kann man mit den Cursortasten scrollen, wie bei "less" üblich.
>
> Man kann das bei 'less' tun, aber man muss nicht. Default ist Umbruch.
> Kleiner, aber wichtiger Unterschied in der Benutzung.

Ich finde less angenehmer als Umbruch. Ist wohl Ansichtsache.

>> Wenn Du nur plain Text willst, egal ob das umgebrochen werden muss oder
>> nicht:
>>
>> systemctl list-timers --no-pager
>
> Das sollte der Default sein, wer einen Pager will kann ihn benutzen.

Man kann auch SYSTEMD_PAGER passend setzen. Siehe auch
<https://www.man7.org/linux/man-pages/man1/systemctl.1.html>

>>> Dann listet er, auch wenn ich normaler User bin, Timer auf die dem
>>> System, also root gehören. Auch das ist Mist, einen normalen User geht
>>> das nichts an.
>>
>> Wieso soll der normale User nicht wissen dürfen, welche Kommandos
>> demnächst ausgeführt werden? Er darf ja auch allerlei Dateien lesen, die
>> nur root schreiben darf, auch /etc/crontab.
>
> Geht ihn nichts an, ein normaler User darf viele Dinge nicht tun und
> auch einige Dateien nicht lesen die root schreibt.

Ja, einige Dateien, nicht alle. Welches konkrete Sicherheitsrisiko
besteht deiner Ansicht nach, wenn jemand sieht, was in einer crontab
steht? Passwörter o.Ä. sollte man da ohnehin nicht reinschreiben.

[Frank Schletz]

On Tue, 11 Aug 2020 02:03:39 +0200, Arno Welzel wrote:

> Gerrit Heitsch:
>
>> On 8/10/20 12:09 PM, Arno Welzel wrote:
>>> Gerrit Heitsch:
> [...]
>>>> Kommt nicht an 'crontab -l' ran.
>>>
>>> Das zeigt hier schonmal nicht an, was in /etc/crontab steht und auch
>>> nicht, was für andere User geplant ist, sondern nur für den User, der
>>> crontab -l aufruft.
>>
>> Das ist auch korrekt so. Es geht einen normalen User nichts an was
>> andere User in ihrer crontab stehen haben.
>
> Auch root sieht nicht, was andere User in ihrer crontab stehen haben.
> Der muss das für jeden User separat machen.
>
> Abgesehen davon dürfte das Szenario, dass an einem Linux-System wirklich
> mehrere echte Menschen mit ihrem eigenen Login real arbeiten, eher
> selten vorkommen. Auf Servern will man in der Regel keine echten Nutzer
> direkt zugreifen lassen und schon gar keine eigene Einträge in der
> crontab anlegen lassen und bei Desktop-Systemen arbeitet in der Regel
> nur eine Person mit dem Gerät.
>

<snip>

<delurk>

man technische User
man sudo
man Usergruppen nach Aufgabengebieten mit verschiedenen sudo-Einschränkungen

Kurz: Es gibt mehr als "echte Menschen" und "root"
Und ja: Auf Servern und auf "Desktop-Systemen"

Kann auch sein, das ich Deine Ausdrucksweise nicht verstehe

Frank

[Gerrit Heitsch]

On 8/11/20 2:03 AM, Arno Welzel wrote:
> Gerrit Heitsch:
>
>> On 8/10/20 12:09 PM, Arno Welzel wrote:
>>> Gerrit Heitsch:
> [...]
>>>> Kommt nicht an 'crontab -l' ran.
>>>
>>> Das zeigt hier schonmal nicht an, was in /etc/crontab steht und auch
>>> nicht, was für andere User geplant ist, sondern nur für den User, der
>>> crontab -l aufruft.
>>
>> Das ist auch korrekt so. Es geht einen normalen User nichts an was
>> andere User in ihrer crontab stehen haben.
>
> Auch root sieht nicht, was andere User in ihrer crontab stehen haben.
> Der muss das für jeden User separat machen.

Er kann User aber davon abhalten überhaupt eigene crontabs anlegen zu
können. Was der default ist, man muss die cron-funktion für jeden User
freigeben.

>>>> In einen normalen, 80 Zeichen breiten Terminal wird die Ausgabs nicht
>>>> umgebrochen sondern abgeschnitten. Schonmal Mist.
>>>
>>> Deswegen kann man mit den Cursortasten scrollen, wie bei "less" üblich.
>>
>> Man kann das bei 'less' tun, aber man muss nicht. Default ist Umbruch.
>> Kleiner, aber wichtiger Unterschied in der Benutzung.
>
> Ich finde less angenehmer als Umbruch. Ist wohl Ansichtsache.

Less bricht by default um, wenn du dann Cursor-rechts benutzt wird
umgeschaltet.

> Ja, einige Dateien, nicht alle. Welches konkrete Sicherheitsrisiko
> besteht deiner Ansicht nach, wenn jemand sieht, was in einer crontab
> steht? Passwörter o.Ä. sollte man da ohnehin nicht reinschreiben.

Nein, aber sich dann die dazugehörigen Scripte anzusehen kann erhellend
sein. Nicht jeder denkt wirklich an Sicherheit beim Erstellen derselben.

Gerrit

[Sven Hartge]

Arno Welzel <use...@arnowelzel.de> wrote:

> Ja, einige Dateien, nicht alle. Welches konkrete Sicherheitsrisiko
> besteht deiner Ansicht nach, wenn jemand sieht, was in einer crontab
> steht? Passwörter o.Ä. sollte man da ohnehin nicht reinschreiben.

Man muss davon ausgehen, dass *jegliche* Information interessant ist und
an andere Stelle zu einem Angriffsvektor werden kann.

S!

--
Sigmentation fault. Core dumped.

[Gerrit Heitsch]

On 8/11/20 8:57 AM, Sven Hartge wrote:
> Arno Welzel <use...@arnowelzel.de> wrote:
>
>> Ja, einige Dateien, nicht alle. Welches konkrete Sicherheitsrisiko
>> besteht deiner Ansicht nach, wenn jemand sieht, was in einer crontab
>> steht? Passwörter o.Ä. sollte man da ohnehin nicht reinschreiben.
>
> Man muss davon ausgehen, dass *jegliche* Information interessant ist und
> an andere Stelle zu einem Angriffsvektor werden kann.

Ja, z.B. ein Script welches ein weiteres Script generiert und dann
ausführt. Passiert das an der falschen Stelle und mit festem Namen kann
ein Angreifer mit etwas Aufwand dort eigenen Code ausführen lassen.

Deshalb enthält z.B. alles was an temporärem von meinen Scripten
generiert wird immer '$$' irgendwo im Namen.

Gerrit

[Sven Hartge]

Da der Default-PID-Raum nur 32000 Einträge lang ist, ist zusätzlich auch
von aussen beobachtbar ist, ist das nicht wirklich sicher und trivial
angreifbar. (Ja, MAX_PID ist konfigurierbar, macht nur oftmals niemand.)

Besser is es für temporäre Dateien oder Verzeichnisse grundsätzlich mit
`mktemp` bzw. `mktemp -d` zu arbeiten.

[Gerrit Heitsch]

On 8/11/20 9:29 AM, Sven Hartge wrote:
> Gerrit Heitsch <ger...@laosinh.s.bawue.de> wrote:
>> On 8/11/20 8:57 AM, Sven Hartge wrote:
>>> Arno Welzel <use...@arnowelzel.de> wrote:
>
>>>> Ja, einige Dateien, nicht alle. Welches konkrete Sicherheitsrisiko
>>>> besteht deiner Ansicht nach, wenn jemand sieht, was in einer crontab
>>>> steht? Passwörter o.Ä. sollte man da ohnehin nicht reinschreiben.
>>>
>>> Man muss davon ausgehen, dass *jegliche* Information interessant ist
>>> und an andere Stelle zu einem Angriffsvektor werden kann.
>
>> Ja, z.B. ein Script welches ein weiteres Script generiert und dann
>> ausführt. Passiert das an der falschen Stelle und mit festem Namen
>> kann ein Angreifer mit etwas Aufwand dort eigenen Code ausführen
>> lassen.
>
>> Deshalb enthält z.B. alles was an temporärem von meinen Scripten
>> generiert wird immer '$$' irgendwo im Namen.
>
> Da der Default-PID-Raum nur 32000 Einträge lang ist, ist zusätzlich auch
> von aussen beobachtbar ist, ist das nicht wirklich sicher und trivial
> angreifbar. (Ja, MAX_PID ist konfigurierbar, macht nur oftmals niemand.)

Es ist ein zusätzliches Hindernis, mehr nicht. Deshalb sollte das
fragliche Script erst gar nicht lesbar sein und auch die crontab nicht
wenn es nicht die eigene ist.

Gerrit

[Arno Welzel]

Frank Schletz:

> On Tue, 11 Aug 2020 02:03:39 +0200, Arno Welzel wrote:
>
>> Gerrit Heitsch:
>>
>>> On 8/10/20 12:09 PM, Arno Welzel wrote:
>>>> Gerrit Heitsch:
>> [...]
>>>>> Kommt nicht an 'crontab -l' ran.
>>>>
>>>> Das zeigt hier schonmal nicht an, was in /etc/crontab steht und auch
>>>> nicht, was für andere User geplant ist, sondern nur für den User, der
>>>> crontab -l aufruft.
>>>
>>> Das ist auch korrekt so. Es geht einen normalen User nichts an was
>>> andere User in ihrer crontab stehen haben.
>>
>> Auch root sieht nicht, was andere User in ihrer crontab stehen haben.
>> Der muss das für jeden User separat machen.
>>
>> Abgesehen davon dürfte das Szenario, dass an einem Linux-System wirklich
>> mehrere echte Menschen mit ihrem eigenen Login real arbeiten, eher
>> selten vorkommen. Auf Servern will man in der Regel keine echten Nutzer
>> direkt zugreifen lassen und schon gar keine eigene Einträge in der
>> crontab anlegen lassen und bei Desktop-Systemen arbeitet in der Regel
>> nur eine Person mit dem Gerät.
>>
> <snip>
>
> <delurk>
>
> man technische User
> man sudo
> man Usergruppen nach Aufgabengebieten mit verschiedenen sudo-Einschränkungen

Von denen sprach ich aber nicht.

> Kurz: Es gibt mehr als "echte Menschen" und "root"
> Und ja: Auf Servern und auf "Desktop-Systemen"
>
> Kann auch sein, das ich Deine Ausdrucksweise nicht verstehe

Du verstehst meine Intention nicht. Ob technische User sehen können,
wann der Start bestimmter Prozesse geplant ist, sehe ich nicht als
Sicherheitsproblem. Ich lerne aber gerne dazu.

[Arno Welzel]

Gerrit Heitsch:

> On 8/11/20 2:03 AM, Arno Welzel wrote:

[...]

>> Ja, einige Dateien, nicht alle. Welches konkrete Sicherheitsrisiko
>> besteht deiner Ansicht nach, wenn jemand sieht, was in einer crontab
>> steht? Passwörter o.Ä. sollte man da ohnehin nicht reinschreiben.
>
> Nein, aber sich dann die dazugehörigen Scripte anzusehen kann erhellend
> sein. Nicht jeder denkt wirklich an Sicherheit beim Erstellen derselben.

Dann dürfen die Scripte selbst nicht für User lesbar sein, die dort
nicht hineinsehen dürfen. Security by obscurity war noch nie eine gute Idee.

[Tim Ritberg]

Am 11.08.20 um 09:29 schrieb Sven Hartge:

> Da der Default-PID-Raum nur 32000 Einträge lang ist, ist zusätzlich auch
> von aussen beobachtbar ist, ist das nicht wirklich sicher und trivial
> angreifbar. (Ja, MAX_PID ist konfigurierbar, macht nur oftmals niemand.)

Stimmt nicht für Ubuntu 20.04.

Tim

[Gerrit Heitsch]

Dazu müsste der User erst einmal wissen so sie sind und wie sie heissen.
Die crontab, könnte er sie lesen, würde es ihm sagen.

Ob du hingegen daran denkst die Permissions deiner Scripte immer korrekt
zu setzen ist die andere Frage.

Entgegen der reinen Lehre ist 'Security' kein alles oder nichts.

Gerrit

[Frank Schletz]

Technische User haben keine (remote)Login rechte
Der Menschliche User meldet sich am System an
Er wechselt per sudo su zu dem technischen User seines Einsatzgebietes
Als dieser kann er die Cron der anderen sehen
Ergo => Der User kann die Cron sehen.
Oder existierten bei Dir technische User als eigene Entitäten unabhängig
von Admins/Usern?

Frank

[Arno Welzel]

Sven Hartge:

> Arno Welzel <use...@arnowelzel.de> wrote:
>
>> Ja, einige Dateien, nicht alle. Welches konkrete Sicherheitsrisiko
>> besteht deiner Ansicht nach, wenn jemand sieht, was in einer crontab
>> steht? Passwörter o.Ä. sollte man da ohnehin nicht reinschreiben.
>
> Man muss davon ausgehen, dass *jegliche* Information interessant ist und
> an andere Stelle zu einem Angriffsvektor werden kann.

Dann ist Linux per se unsicher, da *lesend* sehr viel zugänglich ist,
obwohl das nicht zwingend notwendig ist.

[Arno Welzel]

Gerrit Heitsch:

> On 8/11/20 8:57 AM, Sven Hartge wrote:
>> Arno Welzel <use...@arnowelzel.de> wrote:
>>
>>> Ja, einige Dateien, nicht alle. Welches konkrete Sicherheitsrisiko
>>> besteht deiner Ansicht nach, wenn jemand sieht, was in einer crontab
>>> steht? Passwörter o.Ä. sollte man da ohnehin nicht reinschreiben.
>>
>> Man muss davon ausgehen, dass *jegliche* Information interessant ist und
>> an andere Stelle zu einem Angriffsvektor werden kann.
>
> Ja, z.B. ein Script welches ein weiteres Script generiert und dann

[...]

Ist per se unsicher.

[Arno Welzel]

Frank Schletz:

> On Tue, 11 Aug 2020 10:28:32 +0200, Arno Welzel wrote:
>
>> Frank Schletz:

[...]

>>> Kann auch sein, das ich Deine Ausdrucksweise nicht verstehe
>>
>> Du verstehst meine Intention nicht. Ob technische User sehen können,
>> wann der Start bestimmter Prozesse geplant ist, sehe ich nicht als
>> Sicherheitsproblem. Ich lerne aber gerne dazu.
>
> Technische User haben keine (remote)Login rechte
> Der Menschliche User meldet sich am System an
> Er wechselt per sudo su zu dem technischen User seines Einsatzgebietes

Wieso darf der menschlicher User sudo ausführen, wenn das System gegen
unerwünschte Zugriffe geschützt sein soll? Wenn man sowas erlaubt, ist
die Diskussion darüber, ob crontab nur Benutzerspezifische Daten
anzeigt, hinfällig.

> Als dieser kann er die Cron der anderen sehen
> Ergo => Der User kann die Cron sehen.

Ja, weil das System generell unsicher konfiguriert ist, wenn menschliche
User ohne administrative Verantwortlichkeiten sudo ausführen dürfen.

[Arno Welzel]

Gerrit Heitsch:

> On 8/11/20 10:30 AM, Arno Welzel wrote:
>> Gerrit Heitsch:
>>
>>> On 8/11/20 2:03 AM, Arno Welzel wrote:
>> [...]
>>>> Ja, einige Dateien, nicht alle. Welches konkrete Sicherheitsrisiko
>>>> besteht deiner Ansicht nach, wenn jemand sieht, was in einer crontab
>>>> steht? Passwörter o.Ä. sollte man da ohnehin nicht reinschreiben.
>>>
>>> Nein, aber sich dann die dazugehörigen Scripte anzusehen kann erhellend
>>> sein. Nicht jeder denkt wirklich an Sicherheit beim Erstellen derselben.
>>
>> Dann dürfen die Scripte selbst nicht für User lesbar sein, die dort
>> nicht hineinsehen dürfen. Security by obscurity war noch nie eine gute Idee.
>
> Dazu müsste der User erst einmal wissen so sie sind und wie sie heissen.

Das kann er auch ohne crontab herausfinden. Der Aufwand ist höher, aber
ein Dateisystem nach potentiell "interessanten" Inhalt zu durchsuchen,
ist keine Raketenwissenschaft.

[...]

> Entgegen der reinen Lehre ist 'Security' kein alles oder nichts.

Man sollte dennoch nicht damit argumentieren, dass irgendwas technisch
"sicher" ist, nur weil man es nicht sieht.

[Tim Ritberg]

Am 11.08.20 um 13:05 schrieb Arno Welzel:

>
> Dann ist Linux per se unsicher, da *lesend* sehr viel zugänglich ist,
> obwohl das nicht zwingend notwendig ist.
>

Es geht. Ich hab mal einen Server DSGVO-konform gemacht.
User kommen an Homes anderer eh nicht ran. Bleibt also nur noch /proc/,
last und finger.

Proc kann man einschränken, für last habe ich einen Wrapper geschrieben
und finger deinstalliert.

Tim

[Sven Hartge]

Das ist richtig. Weswegen z.B. das Einsperren von Web-Scripten in
chroots oder Container keine schlechte Idee ist.

Oder die Nutzung der diversen Private*- und Protect*-Parametern bei
systemd für Daemonen um die Angriffsfläche zu reduzieren.

Mit letzteren kann ich z.B. für einen Prozess ein eigenes /tmp und
/var/tmp erzeugen, so dass z.B. Symlink-Angriffe ins Leere laufen.

Oder mit ProtectHome=true kann ich /home und /root für einen Prozess
leer und unzugreifbar machen, so dass ein Informationsleck in der
Schwere reduziert wird.