4.17. Limitazioni e controllo del File System
Avere un buon criterio di assegnazione delle quote è importante, poiché evita che gli utenti riempiano gli hard disk.
Si possono avere due differenti sistemi di quote: la quota d'utente e la quota di gruppo. Come si intuisce, la quota per utente limita la quantità di spazio di cui un utente può disporre e la quota di gruppo fa la stessa cosa ma con i gruppi. Ricordatevene quando decidete la dimensione delle quote.
Nell'impostare un sistema di quote, bisogna tenere conto di alcuni punti importanti:
Fare in modo che le quote siano abbastanza piccole, in modo che gli utenti non divorino lo spazio del disco fisso.
Fare in modo che siano abbastanza grandi, in modo che gli utenti non abbiano a lagnarsene e che la loro quota-email impedisca loro di accettare posta per un lungo periodo.
Usare il sistema delle quote su tutte le aree scrivibili dagli utenti, su /home come su /tmp.
Ogni partizione o cartella a cui gli utenti abbiano pieno accesso in scrittura dovrebbe essere organizzata in quote. Il calcolo e l'assegnazione di una quota su cui si possa lavorare, combina utilizzabilità e sicurezza.
Supponiamo che vogliate usare il sistema delle quote: prima di tutto, dovrete controllare che il supporto per le quote sia abilitato nel kernel, se non lo fosse andrebbe ricompilato; dopo di che, controllate che il pacchetto quota sia installato, altrimenti dovrete procedere all'installazione del pacchetto.
Enabling quota for the respective file systems is as easy as modifying the
defaults setting to
defaults,usrquota in your
/etc/fstab file. If you need group quota, substitute
usrquota to
grpquota. You can also use them both. Then create empty quota.user and quota.group files in the roots of the file systems you want to use quotas on (e.g.
touch
/home/quota.user /home/quota.group
for a
/home file system).
Restart
quota by doing
/etc/init.d/quota stop;/etc/init.d/quota
start
. Now quota should be running, and quota sizes can be set.
Editing quotas for a specific user can be done by
edquota -u <user>
. Group quotas can be modified with
edquota -g <group>
. Then set the soft and hard quota and/or inode quotas as needed.
Per maggiori informazioni sulle quote, leggete le relative pagine man ed il quota mini-HOWTO (/usr/share/doc/HOWTO/en-html/mini/Quota.html - mini guida su quota). Potreste anche voler dare un'occhiata a pam_limits.so.
4.17.2. The ext2 filesystem specific attributes (chattr/lsattr)
Oltre ai soliti permessi di tipo Unix, i filesystem ext2 ed ext3 offrono un insieme di attributi specifici per dare un maggiore controllo sui file del sistema. A differenza dei permessi di base, questi non vengono mostrati con il comando ls -l o modificati mediante chmod; per amministrarli, occorrono altre due utilità: lsattr e chattr (nel pacchetto e2fsprogs). Notate che ciò significa che tali attributi non verranno salvati con la copia di sicurezza del sistema; così, qualora se ne modifichi uno qualsiasi, sarebbe meglio salvare in uno script i successivi comandi chattr, così da poterli reimpostare in un secondo momento, all'atto di un eventuale ripristino.
Fra tutti gli attributi disponibili, i due più importanti, nell'aumentare la sicurezza vengono richiamati dalle lettere 'i' ed 'a' e possono essere impostati o rimossi dal superutente:
L'attributo 'i' ('immutabile'): un file con questo attributo non può essere modificato, né cancellato, né rinominato e nemmeno il superutente può creare collegamenti ad esso.
L'attributo 'a' ('append'): questo attributo ha lo stesso effetto del precedente, salvo che consente di aprire il file per aggiungervi nuovi contenuti, pur senza poter modificare quello già esistente (append mode); è molto utile per i file di log collocati nella cartella /var/log/, anche se dovreste considerare che, talvolta, questi vengono spostati, per via degli script di rotazione dei log.
Si possono impostare questi attributi anche alle cartelle; in tal caso nessuno può modificarne i contenuti, rinominando o rimuovendo dei file. Applicato ad una cartella, l'attributo append permette la sola creazione di file.
It is easy to see how the 'a' attribute improves security, by giving to programs that are not running as the superuser the ability to add data to a file without modifying its previous content. On the other hand, the 'i' attribute seems less interesting: after all, the superuser can already use the basic Unix permissions to restrict access to a file, and an intruder that would get access to the superuser account could always use the chattr program to remove the attribute. Such an intruder may first be confused when noticing not being able to remove a file, but you should not assume blindness - after all, the intruder got into your system! Some manuals (including a previous version of this document) suggest to simply remove the chattr and lsattr programs from the system to increase security, but this kind of strategy, also known as "security by obscurity", is to be absolutely avoided, since it provides a false sense of security.
A secure way to solve this problem is to use the capabilities of the Linux kernel, as described in
Sezione 10.4.2.1, «Difesa preventiva». The capability of interest here is called
CAP_LINUX_IMMUTABLE: if you remove it from the capabilities bounding set (using for example the command
lcap CAP_LINUX_IMMUTABLE) it won't be possible to change any 'a' or 'i' attribute on your system anymore, even by the superuser ! A complete strategy could be as follows:
Impostare gli attributi 'a' ed 'i' sui file desiderati.
Impostare l'attributo 'i' su tale script e su altri file di avvio, o anche sullo stesso binario lcap.
Eseguire manualmente detto comando (o riavviare il sistema, per assicurarsi che tutto funzioni a dovere).
Now that the capability has been removed from the system, an intruder cannot change any attribute on the protected files, and thus cannot change or remove the files. If the machine is forced to reboot (which is the only way to restore the capabilities bounding set), it will easily be detected, and the capability will be removed again as soon as the system restarts anyway. The only way to change a protected file would be to boot the system in single-user mode or using another bootdisk, two operations that require physical access to the machine !
4.17.3. Controllare l'integrità del file system
Siete sicuri che /bin/login sul disco fisso è ancora il binario installato qualche mese fa? Cosa accadrebbe se fosse una versione modificata, che registra le password inserite in un file nascosto o le spedisce in chiaro per tutta Internet?
Il solo modo per avere qualche forma di protezione è controllare i file ogni ora/giorno/mese (preferibile quotidianamente) confrontando gli md5sum attuali di un file con quelli vecchi. Due file non possono avere lo stesso md5sum (l'MD5 digest è 128 bits, quindi le possibilità che due diversi file abbiano lo stesso md5sum sono approssimativamente una su 3.4e3803), perciò è il metodo più sicuro, a meno che qualcuno non abbia modificato l'algoritmo che crea l'md5sum sulla macchina; il che comunque è piuttosto complicato ed improbabile. Bisogna considerare la verifica di questi binari molto importante, poiché è un modo semplice per riconoscere le modifiche ai binari.
Strumenti comunemente utilizzati a questo scopo sono
sxid,
aide (Advanced Intrusion Detection Environment),
tripwire,
integrit e
samhain. Installare
debsums può aiutare a controllare l'integrità del file system, comparando l'md5sum di ogni file con quello usato nell'archivio dei pacchetti Debian. Ma attenzione, questi file possono facilmente essere modificati da un intruso malintenzionato ed inoltre non tutti i pacchetti offrono un elenco md5sum di tutti i file che forniscono. Per ulteriori informazioni leggete
Sezione 10.2, «Effettuate periodicamente dei controlli sull'integrità del sistema» e
Sezione 4.19, «Una fotografia del sistema».
You might want to use locate to index the whole filesystem, if so, consider the implications of that. The Debian findutils package contains locate which runs as user nobody, and so it only indexes files which are visible to everybody. However, if you change it's behaviour you will make all file locations visible to all users. If you want to index all the filesystem (not the bits that the user nobody can see) you can replace locate with the package slocate. slocate is labeled as a security enhanced version of GNU locate, but it actually provides additional file-locating functionality. When using slocate, the user only sees the actually accessible files and you can exclude any files or directories on the system. The slocate package runs its update process with higher privledges than locate, and indexes every file. Users are then able to quickly search for every file which they are able to see. slocate doesn't let them see new files; it filters the output based on your UID.
Potreste voler usare bsign o elfsign. elfsign fornisce un'utility che aggiunge una firma elettronica a un binario ELF ed una seconda utility per verificare questa firma. L'attuale implementazione usa PKI (Public Key Infrastructure) per firmare il cheksum del binario. I benefici di questa pratica sono quelli di permettere di verificare se un binario è stato modificato e chi lo ha creato. bsign usa GPG, elfsign usa certificati PKI (X.509) (OpenSSL).
4.17.4. Impostare il controllo di setuid
Il pacchetto Debian
checksecurity fornisce un processo
cron che viene eseguito giornalmente attraverso
/etc/cron.daily/checksecurity. Questo processo
cron farà partire lo script
/usr/sbin/checksecurity che memorizzerà le informazioni riguardo questi cambiamenti.
The default behavior does not send this information to the superuser but, instead keeps daily copies of the changes in /var/log/setuid.changes. You should set the MAILTO variable (in /etc/checksecurity.conf) to 'root' to have this information mailed to the superuser. See checksecurity(8) manual page for more configuration info.
