Product SiteDocumentation Site

4.11. Fornire un accesso sicuro per gli utenti

4.11.1. Autenticazione degli utenti: PAM

PAM (Pluggable Authentication Modules) permette agli amministratori di sistema di scegliere come le applicazioni autenticano gli utenti. Notate che PAM non funziona se un'applicazione non è stata compilata con il supporto per PAM. Molte delle applicazioni fornite con Debian hanno questo supporto integrato (inoltre Debian non ha il supporto PAM per versioni precedenti alla 2.2). L'attuale configurazione predefinita per un qualsiasi servizio abilitato PAM è emulare l'autenticazione UNIX (leggete in /usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz per ulteriori informazioni su come i servizi PAM dovrebbero funzionare in Debian).
Ogni applicazione con supporto PAM ha un file di configurazione in /etc/pam.d/ che può essere usato per modificare il suo comportamento:
  • quale programma sottostante viene utilizzato per l'autenticazione.
  • quale programma sottostante viene utilizzato per le sessioni.
  • come si comportano i controlli delle password.
The following description is far from complete, for more information you might want to read the Linux-PAM Guides as a reference. This documentation is available in the system if you install the libpam-doc at /usr/share/doc/libpam-doc/html/.
PAM offers you the possibility to go through several authentication steps at once, without the user's knowledge. You could authenticate against a Berkeley database and against the normal passwd file, and the user only logs in if the authentication succeeds in both. You can restrict a lot with PAM, just as you can open your system doors very wide. So be careful. A typical configuration line has a control field as its second element. Generally it should be set to requisite, which returns a login failure if one module fails.

4.11.2. Password security in PAM

Review the /etc/pam.d/common-password, included by /etc/pam.d/passwd[16] This file is included by other files in /etc/pam.d/ to define the behaviour of password use in subsystems that grant access to services in the machine, like the console login (login), graphical login managers (such as gdm or lightdm), and remote login (such as sshd). This definition is
You have to make sure that the pam_unix.so module uses the "sha512" option to use encrypted passwords. This is the default in Debian Squeeze.
The line with the definition of the pam_unix module will look something like:
  password   [success=1 default=ignore]      pam_unix.so nullok obscure minlen=8 sha512 
This definition:
  • Enforces password encryption when storing passwords, using the SHA-512 hash function (option sha512),
  • Enables password complexity checks (option obscure) as defined in the pam_unix(8) manpage,
  • Imposes a minimum password length (option min) of 8.
You have to ensure that encrypted passwords are used in PAM applications, since this helps protect against dictionary cracks. Using encryption also makes it possible to use passwords longer than 8 characters.
Since this module is also used to define how passwords are changed (it is included by chpasswd) you can strengthen the password security in the system by installing libpam-cracklib and introducing this definition in the /etc/pam.d/common-password configuration file:
  # Be sure to install libpam-cracklib first or you will not be able to log in
  password   required     pam_cracklib.so retry=3 minlen=12 difok=3
  password   [success=1 default=ignore]      pam_unix.so obscure minlen=8 sha512 use_authok
So, what does this incantation do? The first line loads the cracklib PAM module, which provides password strength-checking, prompts for a new password with a minimum size [17] of 12 characters, and difference of at least 3 characters from the old password, and allows 3 retries. Cracklib depends on a wordlist package (such as wenglish, wspanish, wbritish, ...), so make sure you install one that is appropriate for your language or cracklib might not be useful to you at all.
The second line (using the pam_unix.so module) is the default configuration in Debian, as described above, save for the use_authok option. The use_authok option is required if pam_unix.so is stacked after pam_cracklib.so, and is used to hand over the password from the previous module. Otherwise, the user would be prompted for the password twice.
For more information about setting up Cracklib, read the pam_cracklib(8) manpage and the article Linux Password Security with pam_cracklib by Hal Pomeranz.
By enabling the cracklib PAM module you setup a policy that forces uses to use strong passwords.
Alternatively, you can setup and configure PAM modules to use double factor authentication such as: libpam-barada, libpam-google-authenticator, libpam-oath, libpam-otpw, libpam-poldi, libpam-usb or libpam-yubico. The configuration of these modules would make it possible to access the system using external authentication mechanisms such as smartcards, external USB keys, or One-Time-Passwords generated by external applications running, for example, in the user's mobile phone.
Please note that these restrictions apply to all users but not to the password changes done by the root user. The root user will be able to set up any password (any length or complexity) for personal use or others regardless of the restrictions defined here.

4.11.3. User access control in PAM

Per essere sicuri che l'utente root possa solo autenticarsi nel sistema da terminali locali, si dovrebbe aggiungere in /etc/pam.d/login la seguente riga:
  auth     requisite  pam_securetty.so
Then you should modify the list of terminals on which direct root login is allowed in /etc/securetty (as described in Sezione 4.7, «Circoscrivere l'accesso alla console»). Alternatively, you could enable the pam_access module and modify /etc/security/access.conf which allows for a more general and fine-tuned access control, but (unfortunately) lacks decent log messages (logging within PAM is not standardized and is particularly unrewarding problem to deal with). We'll return to access.conf a little later.

4.11.4. User limits in PAM

The following line should be enabled in /etc/pam.d/login to set up user resource limits.
  session  required   pam_limits.so
Questa riga riduce le risorse di sistema che gli utenti possono usare (vedete più avanti in Sezione 4.11.8, «Limitare l'uso delle risorse: il file limits.conf»). Per esempio, potreste ridurre il numero di login concorrenti (di un certo gruppo di utenti, o globalmente) ammessi, il numero di processi, la dimensione della memoria etc. etc.

4.11.5. Control of su in PAM

If you want to protect su, so that only some people can use it to become root on your system, you need to add a new group "wheel" to your system (that is the cleanest way, since no file has such a group permission yet). Add root and the other users that should be able to su to the root user to this group. Then add the following line to /etc/pam.d/su:
  auth        requisite   pam_wheel.so group=wheel debug
Questo garantisce che solo le persone del gruppo "wheel" possano usare su per diventare root. Gli altri utenti non saranno in grado di diventare root. Infatti otterranno un messaggio di errore se cercheranno di diventarlo.
If you want only certain users to authenticate at a PAM service, this is quite easy to achieve by using files where the users who are allowed to login (or not) are stored. Imagine you only want to allow users 'ref' to log in via ssh. So you put them into /etc/sshusers-allowed and write the following into /etc/pam.d/ssh:
  auth        required    pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail

4.11.6. Temporary directories in PAM

Since there have been a number of so called insecure tempfile vulnerabilities, thttpd is one example (see DSA-883-1), the libpam-tmpdir is a good package to install. All you have to do is add the following to /etc/pam.d/common-session:
 session    optional     pam_tmpdir.so
There has also been a discussion about adding this by default in Debian configuration, but it s. See http://lists.debian.org/debian-devel/2005/11/msg00297.html for more information.

4.11.7. Configuration for undefined PAM applications

Finally, but not least, create /etc/pam.d/other and enter the following lines:
  auth     required       pam_securetty.so
  auth     required       pam_unix_auth.so
  auth     required       pam_warn.so
  auth     required       pam_deny.so
  account  required       pam_unix_acct.so
  account  required       pam_warn.so
  account  required       pam_deny.so
  password required       pam_unix_passwd.so
  password required       pam_warn.so
  password required       pam_deny.so
  session  required       pam_unix_session.so
  session  required       pam_warn.so
  session  required       pam_deny.so
Queste righe forniranno una buona configurazione di base per tutte le applicazioni che supportano PAM (l'accesso viene negato in modo predefinito).

4.11.8. Limitare l'uso delle risorse: il file limits.conf

Questo file è molto importante in quanto permette di definire dei limiti nell'utilizzo delle risorse per gli utenti del sistema. Nelle vecchie versioni di Debian questo file si trovava in /etc/limits.conf, ma nelle nuove versioni (che utilizzano PAM) questo file è stato spostato in /etc/security/limits.conf.
Se non si pongono dei limiti all'utilizzo delle risorse del computer, qualsiasi utente che abbia accesso ad una shell sul sistema (o anche un intruso che abbia compromesso il sistema tramite un servizio o un demone) può usare tutta la CPU, la RAM, lo stack e le altre risorse a disposizione del sistema. Questo problema di esaurimento delle risorse può essere corretto usando PAM.
There is a way to add resource limits to some shells (for example, bash has ulimit, see bash(1)), but since not all of them provide the same limits and since the user can change shells (see chsh(1)) it is better to place the limits on the PAM modules as they will apply regardless of the shell used and will also apply to PAM modules that are not shell-oriented.
I limiti sull'utilizzo delle risorse vengono fatti rispettare dal kernel e si configurano tramite il file limits.conf. Inoltre, le configurazioni PAM dei vari servizi hanno la necessità di poter accedere alle corrette impostazioni PAM. Potete controllare quali servizi siano sotto controllo ed imporre dei limiti eseguendo il seguente comando:
$ find /etc/pam.d/ \! -name "*.dpkg*" | xargs -- grep limits |grep -v ":#"
Solitamente, login, ssh ed i gestori di sessioni grafiche (gdm, kdm o xdm) dovrebbero occuparsi di far rispettare i limiti sull'utilizzo delle risorse, ma questo compito potrebbe anche essere delegato ad altri file di configurazione di PAM, magari inseriti in cron, per prevenire che i demoni di sistema si approprino di tutte le risorse disponibili.
I particolari limiti imposti all'uso di risorse per il proprio sistema dipendono dalle risorse a disposizione del sistema stesso, questo è uno dei motivi per cui non vengono creati dei limiti nell'installazione predefinita di Debian.
Per esempio, nelle righe seguenti c'é un estratto di un file di configurazione che imposta, per ogni utente, un limite massimo di 100 processi in esecuzione contemporanea (per evitare che l'utilizzo indiscriminato di fork() blocchi il sistema), un limite massimo di occupazione di memoria per ogni processo di 10MB ed un limite massimo di 10 login contemporanei. Gli utenti nel gruppo adm hanno dei limiti più alti e se vogliono possono produrre dei file core (c'é solo un limite soft sui file core).
*              soft    core            0
*              hard    core            0
*              hard    rss             1000
*              hard    memlock         1000
*              hard    nproc           100
*              -       maxlogins       1
*              hard    data            102400
*              hard    fsize           2048
@adm           hard    core            100000
@adm           hard    rss             100000
@adm           soft    nproc           2000
@adm           hard    nproc           3000
@adm           hard    fsize           100000
@adm           -       maxlogins       10
I limiti che un utente normale (inclusi i demoni di sistema) avrebbe sono elencabili dal comando:
$ ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) 102400
file size             (blocks, -f) 2048
max locked memory     (kbytes, -l) 10000
max memory size       (kbytes, -m) 10000
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 100
virtual memory        (kbytes, -v) unlimited
E questi sono i limiti per un utente con poteri amministrativi:
$ ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) 102400
file size             (blocks, -f) 100000
max locked memory     (kbytes, -l) 100000
max memory size       (kbytes, -m) 100000
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 2000
virtual memory        (kbytes, -v) unlimited
Per ulteriori informazioni leggete:

4.11.9. User login actions: edit /etc/login.defs

The next step is to edit the basic configuration and action upon user login. Note that this file is not part of the PAM configuration, it's a configuration file honored by login and su programs, so it doesn't make sense tuning it for cases where neither of the two programs are at least indirectly called (the getty program which sits on the consoles and offers the initial login prompt does invoke login).
  FAILLOG_ENAB        yes
Se si abilita questa variabile, la fallita autenticazione verrà riportata nei log. Questo è fondamentale per tenere traccia di chiunque provi degli attacchi a forza bruta.
  LOG_UNKFAIL_ENAB    no
Nel caso venga impostata tale variabile a 'yes' il programma memorizzerà i nomi utenti non presenti sul sistema, nel caso in cui la procedura di login fallisca per tale ragione. È comunque consigliabile impostare tale opzione a 'no' (ovverosia lasciare il valore predefinito) in quanto è possibile che un utente, inavvertitamente, scriva la propria password al posto del suo nome utente al prompt di login. Se la variabile viene impostata a 'yes', la password dell'utente verrà registrata. Nel caso in cui la variabile sia impostata al valore 'yes', sarà importante assegnare appropriati permessi ai file di log che registrano quel tipo di informazioni (per esempio, potreste impostarli a 640 ed assegnarli ad un gruppo appropriato quale ad esempio quello degli amministratori).
  SYSLOG_SU_ENAB      yes
Questo abiliterà il logging dei tentativi di esecuzione del comando su in syslog. Questione molto importante su una macchina seria ma attenzione che può creare dei problemi con la privacy.
  SYSLOG_SG_ENAB      yes
The same as SYSLOG_SU_ENAB but applies to the sg program.
  ENCRYPT_METHOD  SHA512
As stated above, encrypted passwords greatly reduce the problem of dictionary attacks, since you can use longer passwords. This definition has to be consistent with the value defined in /etc/pam.d/common-password.

4.11.10. User login actions: edit /etc/pam.d/login

You can adjust the login configuration file to implement an stricter policy. For example, you can change the default configuration and increase the delay time between login prompts. The default configuration sets a 3 seconds delay:
auth       optional   pam_faildelay.so  delay=3000000
Increasing the delay value to a higher value to make it harder to use the terminal to log in using brute force. If a wrong password is typed in, the possible attacker (or normal user!) has to wait longer seconds to get a new login prompt, which is quite time consuming when you test passwords. For example, if you set delay=10000000, users will have to wait 10 seconds if they type a wrong password.
In this file you can also set the system to present a message to users before a user logs in. The default is disabled, as shown below:
# auth       required   pam_issue.so issue=/etc/issue
If required by your security policy, this file can be used to show a standard message indicating that access to the system is restricted and user acess is logged. This kind of disclaimer might be required in some environments and jurisdictions. To enable it, just include the relevant information in the /etc/issue[18] file and uncomment the line enabling the pam_issue.so module in /etc/pam.d/login. In this file you can also enable additional features which might be relevant to apply local security policies such as:
  • setting rules for which users can access at which times, by enabling the pam_time.so module and configuring /etc/security/time.conf accordingly (disabled by default),
  • setup login sessions to use user limits as defined in /etc/security/limits.conf (enabled by default),
  • present the user with the information of previous login information (enabled by default),
  • print a message (/etc/motd and /run/motd.dynamic) to users after login in (enabled by default),

4.11.11. Restrizioni ftp: modificare il file /etc/ftpusers

Il file /etc/ftpusers contiene l'elenco degli utenti che non sono autorizzati ad autenticarsi all'host usando il servizio ftp. Solo usando questo metodo potete autorizzare gli utenti ad accedere all'ftp (solitamente questo è sconsigliato poiché usa le password in chiaro). Se i demoni attivi supportano PAM, si può anche usare questo metodo per autorizzare o negare agli utenti l'accesso ai servizi.
FIXME (BUG): questo è un bug di Debian, la configurazione predefinita non include negli ftpusers tutti gli utenti amministratori (in base-passwd).
Un sistema utile per aggiungere al file /etc/ftpusers tutti gli account di sistema è eseguire
$ awk -F : '{if ($3<1000) print $1}' /etc/passwd > /etc/ftpusers

4.11.12. Utilizzo di su

Se veramente gli utenti hanno la necessità di diventare super user sul vostro sistema, ad esempio per installare dei pacchetti o aggiungere utenti, potete utilizzare il comando su per cambiare la vostra identità. Dovreste tentare di evitare ogni accesso come utente root ed utilizzare invece su. Al momento, la soluzione migliore è rimuovere su e passare a sudo, che consente una scelta più ampia di soluzioni rispetto a su. Ad ogni modo, su è più comune visto che viene utilizzato su numerosi altri Unix.

4.11.13. Utilizzo di sudo

sudo allows the user to execute defined commands under another user's identity, even as root. If the user is added to /etc/sudoers and authenticates correctly, the commands defined in /etc/sudoers get enabled. Violations, such as incorrect passwords or trying to run a program you don't have permission for, are logged and mailed to root.

4.11.14. Non permettere accessi per amministrazione remota

Per impedire il login da remoto di account amministrativi dovete modificare /etc/security/access.conf. In questo modo gli utenti dovranno usare su (o sudo) e così rimarrà sempre traccia che un utente locale vuole usare i privilegi di amministratore.
Dovete aggiungere la seguente riga a /etc/security/access.conf, il file di configurazione predefinito di Debian ha una riga simile commentata:
   -:wheel:ALL EXCEPT LOCAL
Remember to enable the pam_access module for every service (or default configuration) in /etc/pam.d/ if you want your changes to /etc/security/access.conf honored.

4.11.15. Restrizioni agli utenti per l'accesso

A volte potreste pensare di avere la necessità di creare utenti nel vostro sistema locale per fornire un determinato servizio (pop3 mail o ftp). Prima di fare ciò, ricordatevi che l'implementazione di PAM in Debian GNU/Linux permette di validare utenti con un'ampia varietà di servizi di directory esterni (radius, ldap, ecc.) forniti dai pacchetti libpam.
If users need to be created and the system can be accessed remotely take into account that users will be able to log in to the system. You can fix this by giving users a null (/dev/null) shell (it would need to be listed in /etc/shells). If you want to allow users to access the system but limit their movements, you can use the /bin/rbash, equivalent to adding the -r option in bash (RESTRICTED SHELL see bash(1) ). Please note that even with restricted shell, a user that access an interactive program (that might allow execution of a subshell) could be able to bypass the limits of the shell.
Debian currently provides in the unstable release (and might be included in the next stable releases) the pam_chroot module (in the libpam-chroot). An alternative to it is to chroot the service that provides remote logging (ssh, telnet). [19]
Se desiderate limitare il quando gli utenti possono accedere al sistema dovrete configurare /etc/security/access.conf per i vostri bisogni.
Per informazioni su come ingabbiare con chroot gli utenti che accedono al sistema mediante il servizio ssh vedete in Sezione B.7, «Chroot environment for SSH».

4.11.16. Esame delle attività degli utenti

Nel caso in cui siate molto sospettosi, potreste configurare l'intero sistema in modo che esami continuamente tutte le attività che gli utenti svolgono nel sistema. Questa sezione presenta alcuni consigli e introduce alcuni strumenti utili.

4.11.16.1. Controllo di input e output con script

Potete utilizzare il comando script per controllare sia ciò che gli utenti stanno eseguendo, sia i risultati di questi comandi. Non potete impostare script come una shell (anche se lo aggiungete a /etc/shells), ma potete far sì che il file di inizializzazione della shell esegua i seguenti comandi:
umask 077
exec script -q -a "/var/log/sessions/$USER"
Di certo, se fate questo globalmente, per tutto il sistema, impedirete che la shell legga i file di inizializzazione personali (dato che la shell viene sovrascritta da script). Un'alternativa è fare questo nei file di inizializzazione dell'utente (ma poi l'utente lo potrà rimuovere, vedete i commenti sotto su questo).
Dovrete anche impostare i file nella directory da controllare (nell'esempio /var/log/sessions/) così che gli utenti possano scrivere in essa ma non possano rimuovere il file. Questo può essere fatto, per esempio, creando i file di sessione dell'utente in anticipo ed impostandoli con l'opzione append-only utilizzando chattr.
Un'utile alternativa per gli amministratori di sistema, che include l'informazione della data, sarebbe:
umask 077
exec script -q -a "/var/log/sessions/$USER-`date +%Y%m%d`"

4.11.16.2. Uso del file storico dei comandi della shell

Se volete rivedere i comandi che l'utente ha usato sulla shell (ma non qual'è stato il risultato di quei comandi), potete impostare un /etc/profile a livello di sistema, che configuri l'ambiente in modo tale che tutti i comandi vengano registrati in un file storico dei comandi. La configurazione a livello di sistema deve essere fatta in modo tale che gli utenti non possano rimuovere le capacità di verifica e registrazione della propria shell. Questo è qualcosa di specifico della shell, perciò assicuratevi che tutti gli utenti stiano usando una shell che supporti questa funzionalità.
For example, for bash, the /etc/profile could be set as follows [20] :
  HISTFILE=~/.bash_history
  HISTSIZE=10000
  HISTFILESIZE=999999
  # Don't let the users enter commands that are ignored
  # in the history file
  HISTIGNORE=""
  HISTCONTROL=""
  readonly HISTFILE
  readonly HISTSIZE
  readonly HISTFILESIZE
  readonly HISTIGNORE
  readonly HISTCONTROL
  export HISTFILE HISTSIZE HISTFILESIZE HISTIGNORE HISTCONTROL
For this to work, the user can only append information to .bash_history file. You need also to set the append-only option using chattr program for .bash_history for all users. [21].
Note that you could introduce the configuration above in the user's .profile. But then you would need to setup permissions properly in such a way that prevents the user from modifying this file. This includes: having the user's home directories not belong to the user (since the user would be able to remove the file otherwise) but at the same time allow the user to read the .profile configuration file and write on the .bash_history. It would be good to set the immutable flag (also using chattr) for .profile too if you do it this way.

4.11.16.3. Completate il controllo dell'utente con le utility per gli account

L'esempio precedente è un modo semplice per configurare il controllo dell'utente ma potrebbe non essere utile per sistemi complessi o per quelli nei quali l'utente non usa per niente o quasi le shell. Se questo è il vostro caso, potete dare un'occhiata alla utility per account acct. Questo programma registrerà tutti i comandi dati dagli utenti o dai processi nel sistema, a scapito dello spazio disco.
All'attivazione dell'accounting tutte le informazioni su processi ed utenti verranno mantenute sotto /var/account/, o più specificamente nel file pacct. Il pacchetto per l'account include alcuni strumenti, come sa, ac e lastcomm, che permettono di analizzare questi dati.

4.11.16.4. Altri metodi di controllo dell'utente

If you are completely paranoid and want to audit every user's command, you could take bash source code, edit it and have it send all that the user typed into another file. Or have ttysnoop constantly monitor any new ttys [22] and dump the output into a file. Other useful program is snoopy (see also github: https://github.com/a2o/snoopy) which is a user-transparent program that hooks in as a library providing a wrapper around execve() calls, any command executed is logged to syslogd using the authpriv facility (usually stored at /var/log/auth.log).

4.11.17. Uno sguardo ai profili utente

Se volete vedere cosa fanno solitamente gli utenti quando si connettono, potete usare il database wtmp che include tutte le informazioni di login. Il file può essere processato con diverse utility, tra cui sac che può restituire un profilo per ogni utente che mostra in quale arco di tempo si è connesso.
Nel caso in cui abbiate attivato l'accounting, potete anche utilizzare gli strumenti da esso forniti per determinare quando gli utenti accedono al sistema e che cosa eseguono.

4.11.18. Impostare delle umask per gli utenti

In base al vostro codice di condotta riguardo agli utenti, potreste voler cambiare il modo in cui gli utenti si scambiano informazioni, ossia quali siano i permessi predefiniti dei nuovi file creati dagli utenti.
L'impostazione predefinita di Debian per l'umask è 022, questo significa che i file (e le directory) possono essere lette e visitate dai membri del gruppo dell'utente e da qualsiasi altro utente del sistema. Questa definizione si trova nel classico file di configurazione /etc/profile, che viene utilizzato da tutte le shell.
If Debian's default value is too permissive for your system you will have to change the umask setting for all the shells. More restrictive umask settings include 027 (no access is allowed to new files for the other group, i.e. to other users in the system) or 077 (no access is allowed to new files to the members the user's group). Debian (by default[23]) creates one group per user so that only the user is included in its group. Consequently 027 and 077 are equivalent as the user's group contains only the user.
This change is set by defining a proper umask setting for all users. You can change this by introducing an umask call in the shell configuration files: /etc/profile (source by all Bourne-compatible shells), /etc/csh.cshrc, /etc/csh.login, /etc/zshrc and probably some others (depending on the shells you have installed on your system). You can also change the UMASK setting in /etc/login.defs, Of all of these the last one that gets loaded by the shell takes precedence. The order is: the default system configuration for the user's shell (i.e. /etc/profile and other system-wide configuration files) and then the user's shell (his ~/.profile, ~/.bash_profile, etc...). Some shells, however, can be executed with a nologin value which might skip sourcing some of those files. See your shell's manpage for additional information.
Per connessioni che fanno uso di login viene usata, prima di tutte le altre, la configurazione di UMASK definita in /etc/login.defs. Ad ogni modo questo valore non viene applicato ai programmi eseguiti dall'utente che non usano login, come ad esempio quelli eseguiti per mezzo di su, cron o ssh.
Non dimenticate di rivedere e magari modificare i file che iniziano con il punto sotto /etc/skel/ dato che questi saranno i file predefiniti dei nuovi utenti quando verranno creati con il comando adduser. I file di Debian predefiniti che iniziano con il punto non includono alcuna chiamata a umask, ma se ce ne dovessero essere, i nuovi utenti creati potrebbero avere valori differenti.
Notate comunque che gli utenti possono modificare l'impostazione della propria a propria umask se lo vogliono, rendendola più o meno permissiva modificando i propri file che iniziano con il punto.
Il pacchetto libpam-umask regola l'umask predefinita degli utenti utilizzando PAM. Aggiungete la seguente riga a /etc/pam.d/common-session dopo aver installato il pacchetto:
session    optional     pam_umask.so umask=077
Infine, dovreste prendere in considerazione il cambiamento dell'umask predefinita 022 di root (come definita in /root/.bashrc) con una umask più restrittiva. Questo impedirà all'amministratore di sistema di rimuovere inavvertitamente file sensibili quando lavora come root in directory leggibili da tutti (come /tmp) e averli disponibili per il proprio utente medio.

4.11.19. Porre limiti a ciò a cui gli utenti possono accedere

FIXME. Dei contenuti sono necessari. Descrivere le conseguenze relative al cambiare i permessi ai pacchetti quando si aggiornano (ed un admin paranoico dovrebbe mettere in chroot i suoi utenti, comunque), se non utilizzando dpkg-statoverride.
Se dovete dare accesso shell agli utenti, pensateci bene. Un utente, a meno che non sia in un ambiente pieno di restrizioni (come una gabbia chroot), può carpire molte informazioni sul sistema, tra cui:
  • some configuration files in /etc. However, Debian's default permissions for some sensitive files (which might, for example, contain passwords), will prevent access to critical information. To see which files are only accessible by the root user for example
    find /etc -type f -a -perm 600 -a -uid 0
    as superuser.
  • i pacchetti installati, sia guardando il database dei pacchetti in /usr/share/doc che tirando ad indovinare guardando gli eseguibili e le librerie installate.
  • some log files at /var/log. Note also that some log files are only accessible to root and the adm group (try
    find /var/log -type f -a -perm 640
    ) and some are even only available to the root user (try
    find /var/log -type f -a -perm
        600 -a -uid 0
    ).
Cosa può visualizzare un utente nel vostro sistema? Probabilmente un sacco di cose, provate questo (fate un respiro profondo):
  find / -type f -a -perm +006 2>/dev/null  
  find / -type d -a -perm +007 2>/dev/null
The output is the list of files that a user can see and the accessable directories.

4.11.19.1. Limitare l'accesso alle informazioni di altri utenti

Se permettete l'accesso tramite shell da parte degli utenti potrebbe essere desiderabile limitare quali informazioni di altri utenti possano vedere. Gli utenti con accesso alla shell tendono a creare un gran numero di file nella loro $HOME: caselle di posta, documenti personali, configurazioni di applicazioni per X/GNOME/KDE...
In Debian ogni utente viene creato con un gruppo associato e due utenti non appartengono mai allo stesso gruppo. Questo è il comportamento predefinito: quando l'utente X viene creato, viene creato anche un gruppo di nome X e l'utente viene assegnato a quel gruppo. Questo evita il concetto di gruppo di utenti che renderebbe più difficile per gli utenti stessi nascondere informazioni agli altri.
However, users' $HOME directories are created with 0755 permissions (group-readable and world-readable). The group permissions is not an issue since only the user belongs to the group, however the world permissions might (or might not) be an issue depending on your local policy.
You can change this behavior so that user creation provides different $HOME permissions. To change the behavior for new users when they get created, change DIR_MODE in the configuration file /etc/adduser.conf to 0750 (no world-readable access).
Users can still share information, but not directly in their $HOME directories unless they change its permissions.
Note that disabling world-readable home directories will prevent users from creating their personal web pages in the ~/public_html directory, since the web server will not be able to read one component in the path - namely their $HOME directory. If you want to permit users to publish HTML pages in their ~/public_html, then change DIR_MODE to 0751. This will allow the web server to access the final public_html directory (which itself should have a mode of 0755) and provide the content published by users. Of course, we are only talking about a default configuration here; users can generally tune modes of their own files completely to their liking, or you could keep content intended for the web in a separate location which is not a subdirectory of user's $HOME directory.

4.11.20. Generare password per gli utenti

Ci sono molti casi in cui un amministratore ha la necessità di creare molti account e di fornire password per ognuno di essi. Ovviamente l'amministratore potrebbe semplicemente scegliere come password il nome scelto dall'utente per l'account, ma ciò non sarebbe molto furbo per quanto riguarda la sicurezza. Un approccio migliore consiste nell'usare un programma per generare password. Debian offre i pacchetti makepasswd, apg e pwgen, che forniscono programmi (con nome uguale a quello del pacchetto) che possono essere usati per questo scopo. makepasswd genererà password totalmente casuali, con enfasi sulla sicurezza piuttosto che sulla pronunciabilità, mentre pwgen cercherà di creare password senza senso ma pronunciabili (ovviamente questo dipende dalla lingua madre). Apg ha algoritmi per entrambi (per questo programma esiste una versione client/server ma non è inclusa nel pacchetto Debian).
Passwd does not allow non-interactive assignation of passwords (since it uses direct tty access). If you want to change passwords when creating a large number of users you can create them using adduser with the --disabled-login option and then use usermod or chpasswd[24] (both from the passwd package so you already have them installed). If you want to use a file with all the information to make users as a batch process you might be better off using newusers.

4.11.21. Controllare le password degli utenti

Le password degli utenti possono talvolta diventare il componente più debole nella sicurezza di un sistema. Ciò è dovuto alla scelta da parte degli utenti di password di scarsa qualità per i loro account (e più utenti hanno accesso più le possibilità che questo accada crescono). Anche se sono stati impostati controlli con il modulo PAM cracklib e limiti per quanto riguarda le password, descritti nella Sezione 4.11.1, «Autenticazione degli utenti: PAM», gli utenti saranno comunque in grado di usare password deboli. Poiché l'accesso per gli utenti potrebbe includerne uno da shell remote (si spera tramite ssh) è importante che la password sia robusta e quindi difficile da indovinare, soprattutto se fossero in qualche modo in grado di raccogliere importanti informazioni come i nomi degli utenti o anche i file passwd e shadow stessi.
A system administrator must, given a big number of users, check if the passwords they have are consistent with the local security policy. How to check? Try to crack them as an attacker would if having access to the hashed passwords (the /etc/shadow file).
An administrator can use john or crack (both are brute force password crackers) together with an appropriate wordlist to check users' passwords and take appropriate action when a weak password is detected. You can search for Debian GNU packages that contain word lists using apt-cache search wordlist, or visit some Internet wordlist sites.

4.11.22. Disconnettere gli utenti inattivi

Solitamente gli utenti inattivi sono un problema per la sicurezza. Un utente potrebbe essere inattivo perché è fuori a pranzo o perché una connessione remota interrotta non è stata ristabilita. Qualunque sia la ragione, gli utenti inattivi possono essere causa di problemi:
  • perché la console dell'utente potrebbe non essere bloccata e un intruso potrebbe accedervi.
  • because an attacker might be able to re-attach to a closed network connection and send commands to the remote shell (this is fairly easy if the remote shell is not encrypted as in the case of telnet).
Alcuni sistemi remoti sono stati compromessi attraverso un programma, screen, inattivo (distaccato).
La disconnessione automatica degli utenti inattivi di solito è una parte della politica di sicurezza che occorre rafforzare. Ci sono molti modi per realizzarla:
  • If bash is the user shell, a system administrator can set a default TMOUT value (see bash(1)) which will make the shell automatically log off remote idle users. Note that it must be set with the -o option or users will be able to change (or unset) it.
  • installare timeoutd e configurare /etc/timeouts secondo la propria politica di sicurezza locale. Il demone controllerà se ci sono utenti inattivi e manderà in time out le loro shell secondo la configurazione impostata.
  • installare autolog e configurarlo per disconnettere gli utenti inattivi.
I demoni timeoutd e autolog sono i metodi consigliati, dal momento che gli utenti possono cambiare la loro shell predefinita o passare ad un'altra shell (non controllata) dopo aver avviato la loro shell predefinita.


[16] In old Debian releases the configuration of the modules was defined directly in /etc/pam.d/passwd.
[17] The minlen option is not entirely straightforward and is not exactly the number of characters in the password. A tradeoff can be defined between complexity and length by adjusting the "credit" parameters of different character classes. For more information read the pam_cracklib(8) manpage.
[18] The default content of this file provides information about the operating system and version run by the system, which you might not want to provide to anonymous users.
[19] libpam-chroot has not been yet thoroughly tested, it does work for login but it might not be easy to set up the environment for other programs
[20] Setting HISTSIZE to a very large number can cause issues under some shells since the history is kept in memory for every user session. You might be safer if you set this to a high-enough value and backup user's history files (if you need all of the user's history for some reason)
[21] Without the append-only flag users would be able to empty the contents of the history file running > .bash_history
[22] Ttys are spawned for local logins and remote logins through ssh and telnet
[23] As defined in /etc/adduser.conf (USERGROUPS=yes). You can change this behaviour if you set this value to no, although it is not recommended
[24] Chpasswd cannot handle MD5 password generation so it needs to be given the password in encrypted form before using it, with the
-e
option.