Boycott systemd

[KernelPanic]

Αν και τα είχαμε πει και στις πρώτες σελίδες περι attack surface που θα έφερνε αυτο το κατασκέυασμα που θέλει να ενσωματώσει τα πάντα....

CVE-2017-9445
https://www.theregister.co.uk/2017/0..._by_dns_query/

[apoikos]

Αν και τα είχαμε πει και στις πρώτες σελίδες περι attack surface που θα έφερνε αυτο το κατασκέυασμα που θέλει να ενσωματώσει τα πάντα....

Το ότι λέγεται systemd-κάτι δε σημαίνει ότι εν γένει έχει κάποια πιο στενή σχέση με το base system απ' ότι αν λεγόταν π.χ. dnsmasq ή unbound, ούτε ότι επεκτείνει το attack surface. Εν προκειμένω ο resolved:

• Δεν τρέχει καν by default
• Όταν τρέχει, τρέχει σαν dedicated χρήστης
• ... με ProtectSystem=Full
• ... με bounded capabilities
• ... με PrivateTmp=yes και PrivateDevices=yes
• ... με system call filters

Θεωρώ ότι τα παραπάνω από μόνα τους είναι από τα πιο strict (security-wise) defaults που έχω δει και κάνουν κατά πολύ limit το attack surface σε σχέση με οποιονδήποτε άλλο caching resolver επιλέξει να τρέξει κανείς out of the box.

[edit]
Παρεμπιπτόντως, το άρθρο του register είναι το λιγότερο ανακριβές, έως παραπλανητικό:

Systemd, the Linux world's favorite init monolith, can be potentially crashed or hijacked by malicious DNS servers.

Απ' τη στιγμή που μιλάμε για διαφορετικά processes, ο όρος monolith πάει περίπατο. Η δε παραπάνω πρόταση δε θα μπορούσε να απέχει περισσότερο από την πραγματικότητα.

[imitheos]

Το ότι λέγεται systemd-κάτι δε σημαίνει ότι εν γένει έχει κάποια πιο στενή σχέση με το base system απ' ότι αν λεγόταν π.χ. dnsmasq ή unbound, ούτε ότι επεκτείνει το attack surface. Εν προκειμένω ο resolved:

Απ' τη στιγμή που μιλάμε για διαφορετικά processes, ο όρος monolith πάει περίπατο. Η δε παραπάνω πρόταση δε θα μπορούσε να απέχει περισσότερο από την πραγματικότητα.

Ποιος σου λέει ότι όταν κρασάρει ο resolved, λόγω κάποιας dbus μαλακίας δεν θα κρασάρει και ο systemd :P Πλάκα κάνω, έχεις δίκιο ότι δεν είναι τόσο σοβαρό θέμα αλλά τα media πάντα τα φουσκώνουν για περισσότερα κλικ.

Όπως είπαμε και σε προηγούμενα μηνύματα, το πρόβλημα δεν είναι ότι ο systemd έχει bugs. Εννοείται πως το software (και το hardware αλλά δεν μας αφορά στο παρόν νήμα) θα έχει πάντα bugs. Ο ντόρος που γίνεται κάθε φορά που βγαίνει κάποιο bug στον systemd και η αρνητική κριτική που του γίνεται όμως δεν είναι αδικαιολόγητη. Λάνσαραν τον systemd σαν το καλύτερο πράγμα μετά τον τροχό που διορθώνει όλα τα κακά του sysvinit και κοροίδευαν και αφόριζαν όποιον δεν πήγαινε με τα νερά τους (πχ όποιον ήθελε να έχει ξεχωριστό /usr χωρίς initramfs) και επίσης έκαναν τα πάντα για να μπει στις διανομές πάρα πολύ νωρίς. Αυτός είναι ο λόγος που του γίνεται τόσο αρνητική κριτική.

Αν έμπαινε σταδιακά και δοκιμάζονταν στην αρχή μόνο από προχωρημένους χρήστες, η ανάπτυξή του θα ήταν μεν πιο αργή, αλλά θα γινόταν πιο σωστή δουλειά και κανείς δεν θα έκραζε όταν έβγαινε κάποιο bug.

Ένα άλλο μεγάλο πρόβλημα που υπάρχει, όπως έχει αποδειχθεί πολλάκις, είναι ότι δεν έχει καθόλου code review. Όποιος θέλει κάνει commit ό,τι θέλει. Το είδαμε και τις προάλλες. Υπήρχε critical bug, προτάθηκε fix (το οποίο μάλιστα άργησε να γίνει commit επειδή είχε λάθος indenting) και έγινε commit χωρίς να κάτσει κανείς να κοιτάξει αν είναι σωστό. Ο ίδιος ο άνθρωπος που το πρότεινε, έγραψε μετά από λίγες μέρες ότι είναι λάθος μέθοδος αυτό που έγραψε και πρότεινε μια καλύτερη εκδοχή.

[KernelPanic]

Όπως είπαμε και σε προηγούμενα μηνύματα, το πρόβλημα δεν είναι ότι ο systemd έχει bugs. Εννοείται πως το software (και το hardware αλλά δεν μας αφορά στο παρόν νήμα) θα έχει πάντα bugs. Ο ντόρος που γίνεται κάθε φορά που βγαίνει κάποιο bug στον systemd και η αρνητική κριτική που του γίνεται όμως δεν είναι αδικαιολόγητη. Λάνσαραν τον systemd σαν το καλύτερο πράγμα μετά τον τροχό που διορθώνει όλα τα κακά του sysvinit και κοροίδευαν και αφόριζαν όποιον δεν πήγαινε με τα νερά τους (πχ όποιον ήθελε να έχει ξεχωριστό /usr χωρίς initramfs) και επίσης έκαναν τα πάντα για να μπει στις διανομές πάρα πολύ νωρίς. Αυτός είναι ο λόγος που του γίνεται τόσο αρνητική κριτική.

Αν έμπαινε σταδιακά και δοκιμάζονταν στην αρχή μόνο από προχωρημένους χρήστες, η ανάπτυξή του θα ήταν μεν πιο αργή, αλλά θα γινόταν πιο σωστή δουλειά και κανείς δεν θα έκραζε όταν έβγαινε κάποιο bug.

Ένα άλλο μεγάλο πρόβλημα που υπάρχει, όπως έχει αποδειχθεί πολλάκις, είναι ότι δεν έχει καθόλου code review. Όποιος θέλει κάνει commit ό,τι θέλει. Το είδαμε και τις προάλλες.

'Ετσι ακριβως και να μην αναφερθώ και στον τρόπο που αντιμετωπίζουν τα bug reports κυρίως ο Lennart...

Ένα άλλο μεγάλο πρόβλημα που υπάρχει, όπως έχει αποδειχθεί πολλάκις, είναι ότι δεν έχει καθόλου code review. Όποιος θέλει κάνει commit ό,τι θέλει. Το είδαμε και τις προάλλες.

Ναι γιατι ακολουθούν το YOLO Driven Development manifesto ή το ADD (Asshole Driven Development) αν προτιμάτε

@apoikos Κάτι τέτοιες πρακτικές δεν και ειναι ότι καλύτερο για την ασφάλεια δεν συμφωνείς (ρητορική ειναι η ερώτηση για να κραταμε το νημα up )?

[mrsaccess]

Αν και δεν μου κάνει πια εντύπωση...

Αν χρησιμοποιήσεις ένα λάθος username ή ένα σωστό username που όμως ξεκινά με αριθμό, ο systemd... ξεκινά την εφαρμογή σαν root.
https://github.com/systemd/systemd/issues/6237

Για άλλη μια φορά ο γνωστός m....aintainer το έκλεισε ως not bug και expected behaviour, ορίζοντας μάλιστα πως το username είναι λάθος (δεν είναι) και είναι λογικό να κάνεις drop σε... root αν δεν βρεις το username.

Εδώ βλέπουμε και το inconsistency. Οι ίδιοι άνθρωποι που κάνουν default το να μην ξεκινά το λειτουργικό αν λείπει ένας σκληρός (δηλαδή δεν έχουν τρέξει ποτέ server για να γνωρίσουν πόσο ηλίθιο είναι αυτό και τι προβλήματα προκαλεί), απλά και ευτυχισμένα επιτρέπουν να κάνουν τα service units fail και μάλιστα τα επιβραβεύουν με root status.

[imitheos]

Αν και δεν μου κάνει πια εντύπωση...

Αν χρησιμοποιήσεις ένα λάθος username ή ένα σωστό username που όμως ξεκινά με αριθμό, ο systemd... ξεκινά την εφαρμογή σαν root.
https://github.com/systemd/systemd/issues/6237

Για άλλη μια φορά ο γνωστός m....aintainer το έκλεισε ως not bug και expected behaviour, ορίζοντας μάλιστα πως το username είναι λάθος (δεν είναι) και είναι λογικό να κάνεις drop σε... root αν δεν βρεις το username.

Εδώ βλέπουμε και το inconsistency. Οι ίδιοι άνθρωποι που κάνουν default το να μην ξεκινά το λειτουργικό αν λείπει ένας σκληρός (δηλαδή δεν έχουν τρέξει ποτέ server για να γνωρίσουν πόσο ηλίθιο είναι αυτό και τι προβλήματα προκαλεί), απλά και ευτυχισμένα επιτρέπουν να κάνουν τα service units fail και μάλιστα τα επιβραβεύουν με root status.

Γαμώτο πρέπει να γραφτώ να παρακολουθώ τις issues του systemd. Είναι καλύτερο read και από comics. Κάθε εβδομάδα και νέο επεισόδιο.

Τώρα θα γίνει ένα commit το οποίο θα φτιάχνει το συγκεκριμένο αλλά θα σε αφήνει να μπεις χωρίς κωδικό αν έχεις username "mellon" (κατά το "speak friend and enter" του άρχοντα των δαχτυλιδιών).

Από το λίγο που διάβασα, όταν βάλεις username που δεν υπάρχει, αγνοεί το rule. Το πρόβλημα έγκειται μόνο όταν ξεκινά με αριθμό και εκείνο μόνο με το 0 (δοκίμασε ένας με username 7day και δεν έπαιξε σαν uid 7). Αυτό βέβαια δεν μειώνει την σοβαρότητα του προβλήματος απλά το αναφέρω εγκυκλοπαιδικά.

[mobinmob]

Τώρα θα γίνει ένα commit το οποίο θα φτιάχνει το συγκεκριμένο αλλά θα σε αφήνει να μπεις χωρίς κωδικό αν έχεις username "mellon" (κατά το "speak friend and enter" του άρχοντα των δαχτυλιδιών).

Το πρόβλημα είναι οι απαντήσεις από τους υπευθύνους
Πόσο δύσκολο είναι, αν δεν θέλεις να έχεις κάποια usernames να αρνείσαι την εκτέλεση του unit στέλνοντας ένα σχετικό μήνυμα στο log;

[imitheos]

Το πρόβλημα είναι οι απαντήσεις από τους υπευθύνους
Πόσο δύσκολο είναι, αν δεν θέλεις να έχεις κάποια usernames να αρνείσαι την εκτέλεση του unit στέλνοντας ένα σχετικό μήνυμα στο log;

Μα δεν είναι bug αλλά λειτουργεί όπως πρέπει. Εσύ έκανες το λάθος να βάλεις κακό username Μερικοί άνθρωποι δεν μπορούν να δεχτούν ότι έκαναν λάθος. Με όσα επιχειρήματα και να αποδείξεις το λάθος τους, θα στο γυρίσουν σε κάτι άλλο που είναι η αιτία. Δεν υπάρχει περίπτωση να φταίει ο Lennart αλλά πάντα θα φταίει κάποιος άλλος.

Επίσης το systemd έχει το ίδιο πρόβλημα με την microsoft και τα windows. Έχουν αναλάβει να υλοποιήσουν το σύμπαν (κα μάλιστα να είναι έτοιμο αύριο) με συνέπεια να μην προλαβαίνουν και να κάνουν τσαπατσούλικη δουλειά. Εκτός αυτού, το σύμπαν αποτελείται από ένα κάρο ξεχωριστά αντικείμενα έκαστο από τα οποία απαιτεί μεγάλη εξειδίκευση.

Η ομάδα που φτιάχνει τα sendmail / postfix / κτλ φτιάχνει μόνο MTAs και είναι ειδικοί σε αυτό. Η ομάδα που φτιάχνει το BIND ασχολείται μόνο με DNS και πάει λέγοντας. Ομάδες, λοιπόν, αποτελούμενες από ειδικούς και παρόλα αυτά κάνουν λάθη και συνέχεια βγαίνουν bugs και CVEs. Αφενός κάποια πρωτόκολλα είναι πολύπλοκα, αφετέρου πάρα πολλά προγράμματα συνεργάζονται με πάρα πολλά άλλα οπότε μπορεί εύκολα να γίνει λάθος και ούτε ειδικοί δεν ξεφεύγουν.

Πως λοιπόν εσύ πας να γράψεις resolved, bootd, IPCd, initd, κτλ και έχεις το θράσος να νομίζεις ότι τα γράφεις σωστά. Δεν θέλω να είμαι καταστροφολόγος αλλά περιμένω να βγουν τρελά security bugs στο μέλλον.

[mobinmob]

Μα δεν είναι bug αλλά λειτουργεί όπως πρέπει. Εσύ έκανες το λάθος να βάλεις κακό username

Προφανώς
Θα έπρεπε να χρησιμοποιήσω το υπερσύγχρονο systemd-sysusers αντί των "legacy" useradd/adduser και να ακολουθήσω την man page του sysusers.d που σαφέστατα αναφέρει τον περιορισμό στα usernames.

[mrsaccess]

Είναι χειρότερο γιατί το username που ξεκινά με αριθμό, δεν χρειάζεται να υπάρχει. Ο systemd πρώτα ελέγχει αν το username είναι valid string ως προς τον ορισμό του... systemd για τα valid username και αν δεν περάσει το τεστ, κάνει fallback στο default (root). Αν το θεωρήσει ως valid, τότε μόνο ελέγχει αν ο χρήστης υπάρχει.

Είναι ένα λάθος που θα μπορούσαμε να είχαμε κάνει οι περισσότεροι, μόνο που οι περισσότεροι δεν γράφουμε system software...

[imitheos]

Προφανώς
Θα έπρεπε να χρησιμοποιήσω το υπερσύγχρονο systemd-sysusers αντί των "legacy" useradd/adduser και να ακολουθήσω την man page του sysusers.d που σαφέστατα αναφέρει τον περιορισμό στα usernames.

grrr Μη μου το θυμίζεις αυτό. Το χρησιμοποιεί το suse και με νευριάζει. Εγκαθιστάς suse και βλέπεις τα passwd / group να έχουν μέσα 5 καταχωρήσεις το καθένα. Σχεδιαστικά ίσως είναι πιο δόκιμο να λειτουργεί έτσι και να εισάγονται σε ένα σύστημα χρήστες / ομάδες μόνο όταν πας να εγκαταστήσεις προγράμματα που τα χρειάζονται αλλά τόσο πρόβλημα είναι πια η παλιά κλασική λειτουργία με τα γεμάτα passwd / group ?

Επίσης ένα άλλο σπαστικό είναι (σε αυτό βέβαια πρέπει να φταίει το suse και όχι ο systemd) ότι δεν ορίζονται σε όλες τις περιπτώσεις χειροκίνητα uid / gid οπότε μπορεί σε 10 διαφορετικές εγκαταστάσεις του ίδιου λειτουργικού να έχεις 10 διαφορετικά uid για τον ίδιο system χρήστη ανάλογα με το ποια σειρά θα επιλέξεις να εγκαταστήσεις τα προγράμματα. (Και στο gentoo το αντιμετώπισα αυτό αλλά εκεί φυσικά δεν είχε σχέση με τον systemd αλλά με το γράψιμο του ebuild)

[karakou]

"Εμετός ο λεναρτουλης, να φύγει απο το λινουξ μας, που το sysvinit εκανε ενα πράγμα αλλα σωστά".
Lol, οχι εντάξει αλλά ήθελα να το πω. Σίγουρα υπάρχει κατακερματισμος με τοσα daemons κ μερικά μοιαζουν αχρειαστα, οποτε απενεργοποιουμε αφοβα ανάλογα τη κρίση μας.

[KernelPanic]

Για άλλη μια φορά ο γνωστός m....aintainer το έκλεισε ως not bug και expected behaviour,

https://twitter.com/sadoperator/stat...45422423404544

[ESP1982]

https://twitter.com/sadoperator/stat...45422423404544

EPIC.

[imitheos]

Από εδώ. Το OpenBSD trollάρει τον Lennart.

Subject: systemd compat for doas
From: Ted Unangst

If the username starts with a digit, but isn't a number, treat it like root.

Index: doas.c
===================================================================
RCS file: /cvs/src/usr.bin/doas/doas.c,v
retrieving revision 1.72
diff -u -p -r1.72 doas.c
--- doas.c	27 May 2017 09:51:07 -0000	1.72
+++ doas.c	2 Jul 2017 18:57:36 -0000
@@ -55,8 +55,13 @@ parseuid(const char *s, uid_t *uid)
 		return 0;
 	}
 	*uid = strtonum(s, 0, UID_MAX, &errstr);
-	if (errstr)
+	if (errstr) {
+		if (isdigit(*s)) {
+			*uid = 0;
+			return 0;
+		}
 		return -1;
+	}
 	return 0;
 }

Σημείωση: Αν και πιστεύω ότι είναι γνωστό, το doas είναι υποδομή για να τρέχεις εφαρμογές σαν άλλος χρήστης, εναλλακτικό δηλαδή του sudo.