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

[Panagiotis Atmatzidis]

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 )
Το 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. Είναι γνωστά αυτά τα 
*προβληματάκια*.

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

> που το SELinux δεν τα κάνει γιατί απλά δεν τα προβλέπει το μοντέλο του.
> Διαφέρουν λοιπόν παραπάνω από μερικά απλά pre-written policies(που απο
> προσωπική πείρα μπορούν και να σε κάνουν να τρελαθείς κάποιες φορές).

Για το SELinux δεν γνωρίζω.. αλλά είμαι 90% σίγουρος ότι υπάρχουν αυτές 
οι δυνατότητες κι εκεί. Δεν θα χρησιμοποιούσα λογισμικό γραμμένο από την 
NSA.
Στην ουσία ΔΕΝ βλέπω διαφορές (από αυτά που διαβάζω για το SELnx) από το 
Grsecurity αν βγάλουμε τα pre-written policies που υπάρχουν σε SELinux 
τα οποία είναι κάτι σαν grsecurity for dummies.

> Οσο για το RSBAC κατά την ταπεινή μου γνώμη είναι το καλύτερο από όλα
> τόσο από υπόβαθρο όσο και από χρηστικότητα παρόλο που είναι λιγάκι το
> εργαλείο του παρανοικού.

Σε αυτό συμφωνούμε, τώρα βγαίνει 1.2.6 stable :^)



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