subdomain. Πως βρέθηκε στο fstab;

Tue May 16 16:03:43 EEST 2006

Alexandros Kosiaris wrote:
> Panagiotis Atmatzidis wrote:
>> Alexandros Kosiaris wrote:
>>> Panagiotis Atmatzidis wrote:
>>>> Alexandros Kosiaris wrote:
>>>>> Christos Ricudis wrote:
>>>>>> Fanis Dokianakis wrote:
>>>>>>> On Tue, May 09, 2006 at 08:42:41PM +0300, Gerassimos Toumazatos
>>>>>>> wrote:
>>>>>>>  
>>>>>>>> Γειά σας,
>>>>>>>> Ξαφνικά στο fstab βρέθηκε η εξής εγγραφή:
>>>>>>>> none                 /subdomain       subdomainfs noauto         0 0
>>>>>>>>
>>>>>>>> Τι μπορεί να έκανα και να δημιουργήθηκε αυτή η εγγραφή;
>>>>>>>> Να την διαγράψω;
>>>>>>>> Ευχαριστώ.
>>>>>>>>
>>>>>>>>     
>>>>>>> mporeis na thn diagrapseis eleythera ean den thes na treheis to
>>>>>>> security framework ths Novell/Suse to AppArmor.
>>>>>>>
>>>>>>> http://en.opensuse.org/Apparmor   
>>>>>> To opoio etsi pws to blepw den mou fainetai ka8olou asxhmo. Einai
>>>>>> aplo, olo to description tou montelou kai oi odhgies xrhshs xwrane se
>>>>>> dyo selides, to learning mode pou exei einai poly boh8htiko, kai se
>>>>>> syndiasmo me kapoio compartmentation subsystem nomizw oti mporei na
>>>>>> kalypsei arketes anagkes. 8a m'arese h idea enos mikrou,
>>>>>> service-oriented linux distribution poy egka8ista to ka8e service sto
>>>>>> diko tou compartment kai kanei apply ena default security policy me
>>>>>> to apparmor. De nomizw na anteksei se formal security analysis, alla
>>>>>> gia tis anagkes tou mesou paranoikou einai mallon arketo.
>>>>>>
>>>>>>
>>>>>>
>>>>> Είναι ουσιαστικά μία προσπάθεια για ξαναγράψιμο του SELinux με ποιο
>>>>> φιλικό προς τον χρήστη τρόπο. Αυτό το πετυχαίνει όπως διαπίστωσες και
>>>>> μόνος σου. Το κατα πόσο πετυχαίνει το ίδιο καλά αποτελέσματα σε
>>>>> ασφάλεια
>>>>> με το SELinux μένει να το δούμε. Πάντως εάν υλοποιεί καλά το Mandatory
>>>>> Access Control που είναι και η ιδέα πίσω και από τα 2 συστήματα θα
>>>>> αντέξει σε formal security analysis. Τώρα πως ακριβώς είναι ο μέσος
>>>>> παρανοϊκός  πολύ θα ήθελα να μάθω... Την ιδέα πάντως που προτείνεις
>>>>> έχοντας την ήδη δοκιμάσει τόσο με SELinux όσο και SEBSD έχω μόνο να πω
>>>>> ότι είναι ιδιαίτερα κουραστική τόσο στην αρχή-αρχή(learning curve γαρ)
>>>>> αλλά και σε κάθε στήσιμο νέου μηχανήματος (εκτός εάν πάρεις τελείως
>>>>> έτοιμα απο κάπου τα policies-φαντάζομαι θα δουλεύει αν και δεν το
>>>>> δοκίμασα ποτέ). Τελος πάντων, το σύστημα έχει ξεκινήσει ένα γερό πόλεμο
>>>>> καθότι οι του SELinux λένε σε παράφραση "αντι να τον παίζετε,δεν
>>>>> έρχεστε
>>>>> από εδώ να κάνουμε όλοι μαζί το δικό μας πιο user-friendly" και οι του
>>>>> apparmor λένε "δεν πάτε να δείτε εαν ερχόμαστε" με τους
>>>>> gr-security,rbac
>>>>>  να λένε και αυτοί τα δικά τους κτλ κτλ κτλ... Εχει πλάκα :-)
>>>> Μα η μόνη διαφορά που έχει το SELinux από το grsecurity είναι
>>>> pre-written  policies. Τίποτε άλλο.. μάλιστα το learning mode το οποίο
>>>> έχει πολλά μεινονεκτήματα είναι μια πρωσπάθεια να καλύψει αυτό το .. gap
>>>> :-)
>>>> Αν για rbac εννοείς το rsbac είναι κάτι πολύ πιο ελαστικό από το
>>>> grsecurity  και πολύ πιο user driver από το SELinux το οποίο στην ουσία,
>>>> σε αφήνει να γράψεις policies έχει πολύ καλό documentation αλλά αυτό που
>>>> δίνει παραπάνω από τα άλλα είναι τα standard policies που παρέχει.
>>>> Το ότι είναι της NSA δεν νομίζω ότι είναι θετικό πάντως..
>>>> cheers
>>> Οχι ακριβώς. Το grsecurity μετά το αρχικό και απλά ισχυροποιημένο custom
>>> περιβάλλον απέκτησε θεωρητικό υπόβαθρο χρησιμοποιώντας το RBAC(role
>>> based access control)  ώς μοντέλο. Το ίδιο ακριβώς χρησιμοποιεί το και
>>> RSBAC(που όντως σε αυτό αναφερόμουν,ευχαριστώ για την διευκρίνηση) απλά
>>> ξεκίνησε από εκεί και δεν το υιοθέτησε αργότερα. Το SELinux χρησιμοποεί
>>> το MAC (mandatory access control) που χωρίς να μπω σε λεπτομέρειες γιατί
>>> θα βγούμε off-topic είναι μια απλοποίηση του RBAC(χωρίς αυτό προφανώς να
>>> είναι απόλυτα σωστό). Αυτά ως θεωρητικό υπόβαθρο για της διαφορές.
>> Πραγματικά δεν θέλω να παίξω με τις λέξεις, αλλά επειδή βλέπω ότι
>> υπάρχει μια κατάσταση ημιμάθειας σε αυτά τα 3 διαφορετικά μοντέλα
>> ασφαλείας.. αλλά και τα 3 χρησιμοποιούν το MAC (Mandatory Access
>> Control) για να επιβάλλουν το system policy που ορίζει ο admin (κι όχι ο
>> root ;-P )
> 
> Δεν χρησιμοποιούν και τα 3 το MAC. Το SELinux είναι καθαρά μία υλοποίηση
> του MAC και βασικά τίποτε παραπάνω, ενώ το RSBAC το έχει υλοποιημένο ως
> module και το χρησιμοποιεί όντως για το access control κομμάτι(ευχαριστώ
> για την διόρθωση εδώ) ενώ το grsecurity χρησιμοποιεί καθαρά το
> RBAC(superset του LBAC===MAC)[1] ως access control model.

Εντάξει, το link που έδωσες ήταν αρκετά ενημερωτικό, δεν γνώριζα και 
τόσα περί RBAC :-)

> Ολα τα παρακάτω ήταν copy paste ως λύσεις που προσθέτει το grsecurity
> και που δεν είναι βασισμένες σε θεωρητικό μοντέλο του RBAC ή του MAC
> αλλά βασίζονται (τουλάχιστον σε αυτή την υλοποίηση) σε διαφορετικά
> πράγματα. Ηταν περισσότερο για να δείξω ότι το access control model δεν
> έχει απαραίτητα σχέση με κάποια hardening policies. Καλώς πάντως απαντάς
> πλήρως γιατι μερικά η αλήθεια είναι τα αγνοούσα.
 >
>> Το PAX είναι κάτι διαφορετικό και μπορεί να μπει "κάτω" και από τα 3
>> μοντέλα, διοτί δρα σε άλλο επίπεδο.
>>
> 
>>> Σε πρακτικό επίπεδο το grsecurity παρέχει customly τα:
>>> # Change root (chroot) hardening
>> Γίνετε και σε RSBAC
>>
>>> # /tmp race prevention
>> Γίνετε και σε RSBAC με symlink redir.
>>
>>> # Extensive auditing
>> ???????????? + X (όπου X τίνει στο τίνει το +ΟΟ ) ..
>> Τι σημαίνει extensive auditing? Extensive auditing είναι αυτό που κάνουν
>> οι openbsd developers στον κώδικα πριν μπει στο stable tree... αλλά σε
>> αυτό το contest δεν καταλαβείνω τι εννοείς.
>>
>>> # Prevention of entire classes of exploits related to address space bugs
>>> (from the PaX project)
>> Άσχετο με το προεπιλεγόμενο μοντέλο, δρα σε άλλο επίπεδο... παίζει παντού..
>>
>>> # Additional randomness in the TCP/IP stack
>> Γίνετε με random pid patch σε RSBAC
>>
>>> # A restriction that allows a user to only view his/her processes
>> Αυτό παίζει στο RSBAC με kernel boot παράμετρο.
>>
>>> # Every security alert or audit contains the IP address of the person
>>> that caused the event
>> Γίνετε και σε RSBAC :-D
>>
>> Επίσης, στο RSBAC έχει real in-kernel user management, on-access virus
>> scanning[1] κι άλλα πολλά[2] σε σχέση με το grsecurity.
>> Το βασικότερο όμως, είναι ότι το grsecurity έχει γραφτεί στην ουσία για
>> "per host configuration & policy" και είναι πλήρως ανελαστικό σε σχέση
>> με το RSBAC. Το SELinux έχει pre-written policies που δεν ταιριάζουν
>> ποτέ "ακριβώς" ενώ το να γράψεις το δικό σου δεν είναι κι ότι πιο
>> εύκολο.. Το learning mode που έχει το grsecurity (δεν ξέρω αν υπάρχει
>> κάτι αντίστοιχο και σε SELinux) είναι καλό μεν.. αλλά *κάθε* φορά
>> δημιουργεί προβλήματα. Οι χρήστες δεν μπορούν να διαβάσουν ούτε τα email
>> τους, αν δεν το κάνουν ακριβώς με τον ίδιο τρόπο κατά το learning mode,
>> π.χ. locally ενώ πριν τα διάβαζαν από pop3/imap. Είναι γνωστά αυτά τα
>> *προβληματάκια*.
>>
> 
> Καταπληκτική σύνοψη των διαφορών σε πρακτικό επίπεδο αν και το
> grsecurity τείνει να αλλάξει(προσπαθεί δλδ ο άνθρωπος).

Μιλάμε για τον spender έτσι? :-P το άτομο είναι απλά άπαιχτο..

>> Το RSBAC αποτελεί ένα ολοκληρωμένο μοντέλο ασφαλείας για τον πυρήνα κι
>> όχι απλώς ένα σύμπλεγμα διαφόρων πολιτικών ασφαλείας (security measures)
>> όπως τα άλλα δύο.
> 
> Επέτρεψε μου να διαφωνήσω. Το RSBAC είναι μία ολοκληρωμένη υλοποίηση
> διαφόρων μοντέλων ασφαλείας, το SELinux είναι καθαρά μία υλοποίηση ενός
> μοντέλου ασφαλείας πρόσβασης ενώ το grsecurity όντως ένα σύμπλεγμα.

Τώρα πάλι μου φαίνεται ότι παίζουμε τις λέξεις.. whatever :P .. εσύ για 
grsecyrity εννοείς και το PAX ίσως. Για εμένα είναι διαφορετικά πράγματα.

>>> που το SELinux δεν τα κάνει γιατί απλά δεν τα προβλέπει το μοντέλο του.
>>> Διαφέρουν λοιπόν παραπάνω από μερικά απλά pre-written policies(που απο
>>> προσωπική πείρα μπορούν και να σε κάνουν να τρελαθείς κάποιες φορές).
>> Για το SELinux δεν γνωρίζω.. αλλά είμαι 90% σίγουρος ότι υπάρχουν αυτές
>> οι δυνατότητες κι εκεί. Δεν θα χρησιμοποιούσα λογισμικό γραμμένο από την
>> NSA.
> 
> ΔΕν βλέπω το λόγο. Είναι open-source λογισμικό. Και ο ίδιος ο
> διάβολος(είναι όντως χειρότερο;) που λέει ο λόγος να το έγραφε δεν θα με
> ένοιαζε ιδιαίτερα αφού το community μπορεί να δει και να ελέγξει κάθε
> γραμμή κώδικα και να αποφασίσει εάν όντως κάτι βρομάει.

Ναι, δεν αντιλέγω. Όπως είπα και σε προηγούμενο post είναι καθαρά 
προσωπική επιλογή, δεν έχω τίποτε αρνητικό να πώ για το SELinux ως 
πρόγραμμα.

> 
>> Στην ουσία ΔΕΝ βλέπω διαφορές (από αυτά που διαβάζω για το SELnx) από το
>> Grsecurity αν βγάλουμε τα pre-written policies που υπάρχουν σε SELinux
>> τα οποία είναι κάτι σαν grsecurity for dummies.
> 
> Μα λίγο πιο πάνω είναι οι διαφορές. Το grsecurity είναι πιο ολοκληρωμένο
>  ως μοντέλο(λιγότερο ελαστικό στην τωρινή υλοποίηση ίσως, αλλά με
> περισσότερες δυνατότητες).

Και που η διαφορά από grsecurity&pax? Με το SELinux & Exec-Sheild???
Οι διαφορές τους είναι σε καθαρά τεχνικό επίπεδο. Θεωρητικά 
δημιουργήθηκαν για τον ίδιο λόγο.
Αν κάνω κάπου λάθος feel free to correct me.

> 
>>> Οσο για το RSBAC κατά την ταπεινή μου γνώμη είναι το καλύτερο από όλα
>>> τόσο από υπόβαθρο όσο και από χρηστικότητα παρόλο που είναι λιγάκι το
>>> εργαλείο του παρανοικού.
>> Σε αυτό συμφωνούμε, τώρα βγαίνει 1.2.6 stable :^)
> Θα σε απογοητεύσω δυστυχώς. To SELinux κυβερνά το τοπίο μου αυτό τον καιρό.

Δυστυχώς :-(

>>
>>
>> [1] http://www.rsbac.org/documentation/different_models/daz
>> [2] http://gentoo-wiki.com/Access_Control_Comparison_Table
> 
> [1] http://en.wikipedia.org/wiki/Role_based_access_control
> 