Fork bombs και άλλα τέρατα

[nske]

Έπιασα να κοιτάζω 1-1 τις built-in εντολές του bash και τα interfaces στο procfs και είναι λίγο περισσότερα από ό,τι περίμενα. Θα το σκεφτώ αύριο φρέσκος.

 

Σύμφωνα με αυτά που είπε ο NullScan πάντως, ίσως θα μπορούσαμε να περιορίσουμε τα processes με την ulimit σε σημείο να μείνει μόνο ένα process της fork bomb, να το προσδιορίσουμε με κάποιο σταθερό κριτίριο που δε μπορώ να σκεφτώ, και να το φάμε.

 

btw, η exec του bash δε ξέρω πόσο "άμεση" είναι (αν δεν προσέξουμε θα μπορούσαμε και να χάσουμε το μοναδικό μας shell, όχι; )

[NullScan]

Ίσως τελικά η λύση να είναι συνδιασμός. echo * στο /proc και από εκεί να δείς ποιό είναι το πρώτο PID από μια τεράστια λίστα στην οποία όμως τα PIDs θα είναι συνεχόμενα. Το πρώτο από αυτή την ακολουθία θα είναι το process που θα πρέπει να σκοτωθεί. Το πώς θα σκοτωθεί δεν μπορώ να καταλάβω. Το exec killall -u <username> θεωρώ οτι θα δουλέψει αλλά θα σε κάνει logout. Το username μπορεί να βρεθεί μέσω procfs. Η kill μπορεί να έχει argc>0 αλλά αν περιοριστεί με τη ulimit ο αριθμός των fork τότε ίσως να γίνει δουλειά.

Αύριο είναι μιά άλλη μέρα.

[gtroza]

σκονάκι ;

http://uwsg.iu.edu/hypermail/linux/kernel/0307.1/0372.html

.

[apoikos]

@Nullscan: Το exec είναι one-shot. Θα αντικαταστήσει το shell σου με ό,τι process του πεις, οπότε αφού τελειώσει το process, θα έχεις χάσει το shell. Επιπλέον, η fork-bomb ήταν το τελευταίο πράγμα που έτρεξε πριν πάρεις το shell λογικά (δε νομίζω ότι πρόλαβε να τρέξει κάτι άλλο), οπότε το PID της είναι στη μεταβλητή $! (last backgrounded PID) και το PID του shell είναι στη $$. Είσαι σε καλό δρόμο όμως με το echo * στο /proc. Είπαμε όμως ότι τη bomb την έσκασε ως root, οπότε αν είναι να κάνουμε killall -u root, ας πατήσουμε καλύτερα το κουμπάκι εκείνο δίπλα από το power (κάτι το οποίο ρεαλιστικά είναι πιο γρήγορο) ;-). Τώρα πρέπει κάπως να «αδρανοποιήσεις» τα processes του fork-bomb, ώστε να τα σκοτώσεις μετά ένα-ένα.

 

Κατά τ' άλλα θα αφαιρέσω 2 μονάδες από τον gtroza γιατί δεν κρατάει τα σκονάκια του για τον εαυτό του

 

Α, και η ulimit δεν ισχύει αναδρομικά (δε θα μπορούσε άλλωστε γιατί θα έπρεπε να σκοτώσει processes χωρίς κάποιο κριτήριο).

 

(Δεν πάμε να τετραγωνίσουμε τον κύκλο, μάθημα κάνουμε από το οποίο θα βγουν 2-3 ενδιαφέροντα συμπεράσματα)

[gtroza]

γιατί κύριε ;

είναι αδικία !

 

εγώ τα βρήκα στο γραφείο σας και είπα να σας τα δώσω μη τα πάρουν τα κακά παιδια

 

κύριε

μπήκε για λίγο ένα παιδί απο άλλη τάξη και μας πείραζε !

 

 

καλημέρα σε όλους

και καλά αποτελέσματα !

.

[firewalker]

Μπορούμε να έχουμε πει στο σύστημα μας να μην επιτρέπει για τον κάθε χρήστη να τρέξει πάνω από 300 processes για παράδειγμα. Έτσι οι πόροι του συστήματος μας δεν πάνε σαν αμνοί στην σφαγή. Έτσι δεν είναι;

[gtroza]

απότι κατάλαβα (άν και άσχετος)

μάλλον ναί

 

θα το επιβεβαιώσει και ο κύριος

 

αλλά το θέμα είναι παγίδα

η εκφώνηση δεν προσδιορίζει καταστάσεις

.

http://64.233.183.104/search?q=cache:m-akQ22AC84J:www.cs.utah.edu/classes/cs4400-regehr/slides/17-1up.pdf+killing+forkbomb+in+linux&hl=en&ct=clnk&cd=45&client=mozilla

χρήσιμο για γενική ενημέρωση

.

[apoikos]

Μπορούμε να έχουμε πει στο σύστημα μας να μην επιτρέπει για τον κάθε χρήστη να τρέξει πάνω από 300 processes για παράδειγμα. Έτσι οι πόροι του συστήματος μας δεν πάνε σαν αμνοί στην σφαγή. Έτσι δεν είναι;

 

Ναι, με τη ulimit:

>
apoikos@xalki:~ $ ulimit -a
-t: cpu time (seconds)         unlimited
-f: file size (blocks)         unlimited
-d: data seg size (kbytes)     unlimited
-s: stack size (kbytes)        8192
-c: core file size (blocks)    0
-m: resident set size (kbytes) unlimited
-u: processes                  16383
-n: file descriptors           1024
-l: locked-in-memory size (kb) 32
-v: address space (kb)         unlimited
-x: file locks                 unlimited
-i: pending signals            16383
-q: bytes in POSIX msg queues  819200
-e: max nice                   0
-r: max rt priority            0

 

Όμως τα όρια αυτά ισχύουν ανά shell (ή ανά login αν τα βάλεις με το pam_limits). Γενικά υπάρχουν και άλλοι τρόποι, αλλά αν έχεις κάποιο mission-critical μηχάνημα, μια καλή λύση είναι να κάνεις service segregation, χρησιμοποιώντας κάποιο virtualization (π.χ. Xen ή OpenVZ), ώστε να υπάρχει πλήρης επιβολή ορίων σε όλα τα επίπεδα.

 

>
apoikos@apollon:~/tmp $ cat fork.c
#include <unistd.h>

int main() {
while (1) 
	fork();
return 0;
}
apoikos@apollon:~/tmp $ gcc -o fork fork.c 
apoikos@apollon:~/tmp $ ulimit -u 120
apoikos@apollon:~/tmp $ ./fork &
[1] 4200
apoikos@apollon:~/tmp $ ls
zsh: fork failed: resource temporarily unavailable

Αυτό συμβαίνει με τα όρια ;-)

[NullScan]

Θα συνεχίσω να δοκιμάζω!

>echo "" > /proc/<PID>/exe

Το PID το βρίσκω όπως είπα και παραπάνω.

Ενδέχεται να υπάρχει και άλλο file στο procfs που να βοηθάει αλλά δεν προλαβαίνω τώρα να το ψάξω.

[apoikos]

Χμ, το exe είναι symbolic link στο original executable. Δε θα καταφέρεις κάτι γιατί η fork() κάνει fork το process από τη μνήμη, οπότε δε θα διαβάσει κάτι. Αν κουραστείτε πείτε να το πάρει το ποτάμι ;-)

[firewalker]

Από την στιγμή που τρέχει το bomb, προλαβαίνετε να κάνετε κάτι; Σε εμένα από την στιγμή που θα πατηθεί το Enter, άντε bye-bye... Δεν κάνει τίποτε.

 

P4 @ 2,4 GHz 768 RAM

[DIMITRISG]

Την μπόμπα μπορει να την βάλει καποιος άλλος στο συστημά μου ή μονο εγω; ενα πρόγραμμα πχ. Θα ειναι κατι εσκεμενο ή μπορει να ειναικαι λάθος του προγράμματος;

 

Δηλαδη πως μπορω να προστατευτω ειναι η ερωτηση μου

[parsifal]

http://en.wikipedia.org/wiki/Magic_SysRq_key

[apoikos]

@parsifal: Καλό, αλλά εδώ μιλάμε για έναν τρόπο να σκοτώσεις μόνο τα processes της βόμβας και τίποτα άλλο ;-) It's shell magic we're talking about...

[NullScan]

Ε, τότε στο smaps ή στο maps.

Δεν μπορεί, θα το βρώ στο τέλος.