selinux-apache selinux-apache-it.xml,1.1,1.2
Francesco Tombolini (tombo)
fedora-docs-commits at redhat.com
Mon Dec 12 23:24:30 UTC 2005
Author: tombo
Update of /cvs/docs/selinux-apache
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv17431
Modified Files:
selinux-apache-it.xml
Log Message:
Last part of italian translation - draft
Index: selinux-apache-it.xml
===================================================================
RCS file: /cvs/docs/selinux-apache/selinux-apache-it.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- selinux-apache-it.xml 4 Dec 2005 16:40:02 -0000 1.1
+++ selinux-apache-it.xml 12 Dec 2005 23:24:22 -0000 1.2
@@ -114,10 +114,11 @@
</para>
<para>
Come ulteriore controllo, usa il comando <command>ps axZ | grep
- httpd</command>. Lo dovresti vedere in esecuzione sotto il
+ httpd</command>. Dovresti vederlo in esecuzione sotto il
<firstterm>security context</firstterm>
<computeroutput>root_u:system_r:httpd_t</computeroutput>.
- La parte più importante è la terza componente, il
+ La parte più importante è
+ la terza componente, il
<firstterm>type</firstterm> <computeroutput>httpd_t</computeroutput>.
Nota che molti altri processi sul tuo sistema sono in esecuzione sotto il tipo
<computeroutput>unconfined_t</computeroutput>. Essendo eseguito
@@ -150,15 +151,15 @@
<guimenu>Servizio HTTPD</guimenu>, eliminate
il contrassegno a fianco delle voci
<guilabel>Permetti il supporto HTTPD cgi</guilabel> e
- <guilabel>Permetti ad HTTPD di leggere le home directory</guilabel>. In alternativa, puoi eseguire questi
- comandi da un terminale:
+ <guilabel>Permetti ad HTTPD di leggere le home directory</guilabel>. In alternativa,
+ puoi eseguire questi comandi da un terminale:
</para>
<screen>
<command>setsebool httpd_enable_cgi false</command>
<command>setsebool httpd_enable_homedirs false</command>
</screen>
<para>
- SELinux e le booleane sono discusse in <xref
+ SELinux e le booleane sono discusse in <xref
linkend="sn-httpd-booleans"/>.
</para>
<para>
@@ -282,10 +283,10 @@
<computeroutput>user_home_t</computeroutput>.
</para>
<para>
- To relabel the file and allow &APACHE; to read it, you can use
- the <command>chcon</command> utility: <command>chcon -t
+ Per rietichettare il file e permettere ad &APACHE; di leggerlo, puoi usare
+ l'utilità <command>chcon</command>: <command>chcon -t
httpd_sys_content_t /var/www/html/about.html</command>.
- Verify the context on the file is correct:
+ Verifica che il contesto del file sia corretto:
</para>
<screen>
<command>ls -aZ /var/www/html/</command>
@@ -295,79 +296,79 @@
-rw-r--r-- walters walters system_u:object_r:httpd_sys_content_t about.html
</screen>
<para>
- The <command>chcon</command> utility is similar in style to the
- UNIX command <command>chmod</command>. For example, if you
- wanted to recursively change the types of a directory and all
- the files it contains, you could use this command:
- <command>chcon -R -h -t httpd_sys_content_t /path/to/directory</command>.
- The <option>-R</option> switch means to operate recursively,
- and the <option>-h</option> option means to not follow
- symlinks (which is almost always what you want).
+ L'utilità <command>chcon</command> è similare in stile al
+ comando UNIX <command>chmod</command>. Per esempio, se
+ volevi cambiare ricorsivamente i tipi di una directory e tutti
+ i files che essa contiene, potevi usare questo comando:
+ <command>chcon -R -h -t httpd_sys_content_t /path/to/directory</command>.
+ Lo switch <option>-R</option> fa operare ricorsivamente,
+ e l'opzione <option>-h</option> serve a non far seguire
+ i collegamenti (che è quasi sempre quello che vuoi).
</para>
<tip>
<title><command>chcon</command> vs. <command>restorecon</command></title>
<para>
- There is another command available for changing file labels,
- called <command>restorecon</command>. This command is
- useful if you want to revert back to the default labels
- on files. For example, you can run
- <command>restorecon -v -R /var/www/</command> to reset
- all the file labels in the <filename>/var/www/</filename>
- directory. Internally, restorecon reads the
- <filename>/etc/selinux/targeted/contexts/files/file_contexts</filename>
- file, which has a set of regular expressions mapping file
- paths to security contexts.
+ C'è un altro comando a disposizione per cambiare le etichette di files,
+ chiamato <command>restorecon</command>. Questo comando è
+ utile se vuoi ripristinare le etichette dei files nella loro condizione
+ predefinita. Per esempio, puoi eseguire
+ <command>restorecon -v -R /var/www/</command> per resettare
+ tutte le etichette dei files nella directory <filename>/var/www/</filename>.
+ Internamente, restorecon legge il file
+ <filename>/etc/selinux/targeted/contexts/files/file_contexts</filename>,
+ che possiede un insieme di espressioni regolari che mappa i percorsi
+ dei files ai contesti di sicurezza.
</para>
</tip>
</section>
<section id="sn-user-homedir">
- <title>Adding Per-User Content</title>
+ <title>Aggiungere contenuto su base Per-User</title>
<para>
- This section discusses per-user
- <filename>~/public_html</filename> directories. You need to do
- three things:
+ Questa sezione discute la configurazione directory
+ <filename>~/public_html</filename> per-user. Hai bisogno di fare
+ tre cose:
</para>
<procedure>
<step>
<para>
- Edit <filename>/etc/httpd/conf/httpd.conf</filename>.
- Comment out the line <computeroutput>UserDir disable</computeroutput>
- and change the <computeroutput>UserDir</computeroutput> option
- to <computeroutput>public_html</computeroutput>.
+ Edita <filename>/etc/httpd/conf/httpd.conf</filename>.
+ Commenta la linea <computeroutput>UserDir disable</computeroutput>
+ e cambia l'opzione <computeroutput>UserDir</computeroutput>
+ a <computeroutput>public_html</computeroutput>.
</para>
</step>
<step>
<para>
- Execute <command>service httpd reload</command>.
+ Esegui <command>service httpd reload</command>.
</para>
</step>
<step>
<para>
- Start <application>system-config-securitylevel</application>. In
- the <guilabel>&SEL;</guilabel> tab, open the <guimenu>Apache</guimenu>
- menu under <guilabel>Modify SELinux Policy</guilabel>. Switch
- the Boolean <guilabel>Allow httpd to read home
- directories</guilabel> back on. Alternatively, use
- <command>setsebool httpd_enable_homedirs true</command> from a
- terminal.
+ Avvia <application>system-config-securitylevel</application>. Nel
+ tab <guilabel>&SEL;</guilabel>, apri il menu <guimenu>Apache</guimenu>
+ sotto <guilabel>Modifica la Policy di SELinux</guilabel>. Cambia
+ la booleana <guilabel>Permette ad httpd di leggere le home
+ directories</guilabel> attivandola. In alternativa, usa
+ <command>setsebool httpd_enable_homedirs true</command> da un
+ terminale.
</para>
</step>
</procedure>
<para>
- The rest of this process is from the perspective of a user
- wanting to maintain your own website.
+ Il resto di questo processo è dalla prospettiva di un utente
+ che vuole mantenere il suo sito web.
</para>
<note>
- <title>Remember normal Linux permissions</title>
+ <title>Ricorda i normali permessi Linux</title>
<para>
- Make sure that you have your home directory set up with the
- normal Linux permissions for this: in particular, you may need
- to run <command>chmod a+x ~</command>.
+ Sii sicuro di avere la tua home directory impostata con i
+ normali permessi Linux per questo: in particolare, avrai bisogno
+ di eseguire <command>chmod a+x ~</command>.
</para>
</note>
<para>
- In your home directory, execute <command>mkdir
- public_html</command>. Examine the security context of the new
+ Nella tua home directory, esegui <command>mkdir
+ public_html</command>. Esamina il contesto di sicurezza della nuova
directory:
</para>
<screen>
@@ -375,169 +376,169 @@
drwxrwxr-x walters walters user_u:object_r:user_home_t public_html/
</screen>
<para>
- Note that it has the type
- <computeroutput>user_home_t</computeroutput>, because &SEL; has
- a rule that says new files created in a user's home directory
- (<computeroutput>user_home_dir_t</computeroutput>), get assigned
- the type <computeroutput>user_home_t</computeroutput> by
- default. A process running as
- <computeroutput>httpd_t</computeroutput> (i.e., &APACHE;) can't
- read a file with this type. To change the file's type and allow
- &APACHE; to read the file, execute:
+ Nota che ha il tipo
+ <computeroutput>user_home_t</computeroutput>, poichè &SEL; ha
+ a regola che dice che i nuovi files creati nella home directory di un utente
+ (<computeroutput>user_home_dir_t</computeroutput>), per impostazione predefinita
+ dovranno avere assegnato il tipo <computeroutput>user_home_t</computeroutput>
+ Un processo eseguito come
+ <computeroutput>httpd_t</computeroutput> (es., &APACHE;) non può
+ leggere un file con questo tipo. Per cambiare il tipo del file e permettere ad
+ &APACHE; di leggere il file, esegui:
<command>chcon -t httpd_sys_content_t public_html</command>
</para>
<note>
<title>Targeted versus strict</title>
<para>
- In the strict policy, normal users have to use the type
- <computeroutput>httpd_user_content_t</computeroutput>; the
- <computeroutput>_sys_</computeroutput> means it is reserved
- for the system administrator by default. Using separate types
- like this allows stronger separation between the system and
- the user.
+ Nella policy strict, gli utenti normali devono usare il tipo
+ <computeroutput>httpd_user_content_t</computeroutput>; per impostazione
+ predefinita il <computeroutput>_sys_</computeroutput> è inteso essere riservato
+ agli amministratori di sistema. L'uso di tipi separati
+ come questi permette una più forte separazione fra il sistema
+ l'utente.
</para>
</note>
<para>
- Now, create some content in your new
- <filename>public_html</filename> (perhaps
- <filename>index.html</filename>). Test that you can browse to
- <ulink url="http://localhost/~username/index.html"/>, and see
- the expected data. Try relabeling the file back: <command>chcon
- -t user_home_t index.html</command>. When you reload the page,
- the Web server will not have permission to read it any more.
- </para>
- <para>
- One key idea is that there are actually two
- independent layers of security involved. There is the normal Unix
- permissions (which you modify with <command>chmod</command>),
- and the &SEL; file labels, which you modify with
- <command>chcon</command>. Simply making a file world-readable
- with the Unix command <command>chmod a+r
- <replaceable>filename</replaceable></command> will not, with
- &SEL;, in general allow any process to read the file. Each
- process must be explicitly authorized in the &SEL; policy for
- access to a particular file type.
+ Ora crea qualche contenuto nella nuova
+ <filename>public_html</filename> (almeno
+ <filename>index.html</filename>). Prova che puoi navigare verso
+ <ulink url="http://localhost/~username/index.html"/>, ed osserva
+ i risultati attesi. Prova a rietichettare il file come in precedenza: <command>chcon
+ -t user_home_t index.html</command>. Quando ricaricherai la pagina,
+ il Web server non avrà più il permesso di leggerla.
+ </para>
+ <para>
+ Un idea chiave è che attualmente sono coinvolti due
+ livelli di sicurezza indipendenti. Ci sono i normail permessi Unix
+ (che modifichi con <command>chmod</command>),
+ e le etichette dei files di &SEL;, che modifichi con
+ <command>chcon</command>. Rendere semplicemente un file world-readable
+ con il comando Unix <command>chmod a+r
+ <replaceable>filename</replaceable></command> non sarà , con
+ &SEL;, in generale permesso a qualsiasi processo di leggere il file. Ogni
+ processo dovrà essere esplicitamente autorizzato nella policy &SEL; per
+ accedere ad un particolare tipo di file.
</para>
</section>
<section id="sn-security-overview">
- <title>Discussion of Overall Security</title>
+ <title>Discussione sulla sicurezza in generale</title>
<para>
- Having gained an understanding of some basic &SEL; concepts, it
- is useful to step back and see what you have achieved so far, and
- examine some of the philosophy behind &SEL;.
- </para>
- <para>
- Running &APACHE; as <computeroutput>httpd_t</computeroutput>
- does ensure that even if the part of &APACHE; that is running as
- root is compromised or misconfigured, it is isolated from the
- rest of the system, and cannot delete or deface your website.
- </para>
- <para>
- This mention of misconfiguration is useful to elaborate on. At
- a fundamental level, a hostile attacker trying to break into
- &APACHE; is not very different from a webmaster misconfiguring
- it. Given &APACHE;'s extremely complex configuration file, all
- it takes is a one-line mistake such as the following to cause
- serious problems on your system:
+ Avendo ottenuto e compreso alcuni concetti base di &SEL;, è
+ utile fare un passo indietro e vedere cosa hai ottenuto alla fine, ed
+ esaminare alcune delle filosofie dietro &SEL;.
+ </para>
+ <para>
+ Eseguire &APACHE; come <computeroutput>httpd_t</computeroutput>
+ assicura che anche se la parte di &APACHE; che viene eseguita come
+ root è compromessa o misconfigurata, è isolata dal
+ resto del sistema, e non può cancellare o defacciare il tuo sito web.
+ </para>
+ <para>
+ Sulla menzione di misconfigurazione sarà utile tornarci sopra.
+ Fondamentalmente, un attacker ostile che prova ad irrompere in
+ &APACHE; non è molto differente da un webmaster che lo misconfiguri.
+ Dato che il file di configurazione di &APACHE; è estremamente complesso,
+ basterebbe una sola linea sbagliata come la seguente per causare
+ seri problemi al sistema:
</para>
<programlisting>
PidFile /etc/passwd
</programlisting>
<para>
- And there are plenty of other easier to make mistakes in your
- Apache configuration.
+ E ci sono molti altri semplici modi di fare errori nella
+ configurazione Apache.
</para>
<para>
- &SEL; lets you separate your security policy (&APACHE; should
- never have direct access to <filename>/etc/passwd</filename>)
- from the rest of all the complexity in
- <filename>/etc/httpd/conf/httpd.conf</filename>. Having
- specific labels for your Web content and &APACHE; also ensures a
- compromised or misconfigured name server
- (<computeroutput>named_t</computeroutput>) cannot read the
- website at all (which is useful if some parts of the website are
- password-protected by &APACHE;, for example).
+ &SEL; ti permette di separare la tua policy di sicurezza (&APACHE; non dovrebbe
+ mai avere accesso diretto a <filename>/etc/passwd</filename>)
+ dal resto della complessità di
+ <filename>/etc/httpd/conf/httpd.conf</filename>. Avendo
+ specifiche etichette per i tuoi contenuti Web ed &APACHE; assicura che
+ un server dei nomi compromesso o misconfigurato
+ (<computeroutput>named_t</computeroutput>) non possa leggere
+ affatto il sito web (che è utile se alcune parti del sito sono
+ state protette con password da &APACHE;, per esempio).
</para>
<para>
- For a much more thorough discussion of the philosophy behind
- &SEL;, refer to <citetitle>The Inevitability Of
+ Per un maggior approfondimento sulla discussione sulla filosofia dietro
+ &SEL;, fa referimento a <citetitle>The Inevitability Of
Failure</citetitle> (<ulink url="http://www.nsa.gov/selinux/papers/inevit-abs.cfm">http://www.nsa.gov/selinux/papers/inevit-abs.cfm</ulink>.)
</para>
</section>
<section id="sn-suexec-and-cgi-scripts">
- <title>Virtual Hosting, CGI scripts and suEXEC</title>
+ <title>Hosting viryuale, CGI scripts e suEXEC</title>
<para>
- Most installations of &APACHE; have some sort of dynamic
- content; in particular, CGI scripts are very common. This
- section examines a much more complicated use case for
- &SEL;: A website that has a number of users, each of whom owns
- a virtual host, out of which they are allowed to run CGI
- content.
+ La maggior parte delle installazioni di &APACHE; hanno qualche sorta di contenuto
+ dinamico; in particolare, gli scripts CGI sono molto comuni. Questa
+ sezione esamina un caso molto più complicato per
+ &SEL;: Un sito web che ha un numero di utenti, ognuno dei quali ha il proprio
+ host virtuale, nel quale gli è permesso eseguire contenuti
+ CGI.
</para>
<para>
- In this situation, we have a number of security goals:
+ In questa situazione, abbiamo un certo numero di obiettivi di sicurezza:
<itemizedlist>
<listitem>
<para>
- Protect the system from the users
+ Proteggere il sistema dagli utenti
</para>
</listitem>
<listitem>
<para>
- Protect the users from each other
+ Proteggere gli utenti gli uni dagli altri
</para>
</listitem>
<listitem>
<para>
- Protect the user's home directory from their own CGI scripts
+ Proteggere la home directory degli utenti dai propri scripts CGI
</para>
</listitem>
</itemizedlist>
</para>
<para>
- One common method for approaching the first two goals on a
- non-&SEL; setup is to use an &APACHE; module called <firstterm>suEXEC</firstterm>.
- You can read more about suEXEC at <ulink
+ Un metodo comune di approcciare ai primi due obbiettivi su un
+ installazione non-&SEL; è usare un modulo di &APACHE; chiamato <firstterm>suEXEC</firstterm>.
+ Puoi leggere di più su suEXEC su <ulink
url="http://httpd.apache.org/docs-2.0/suexec.html">http://httpd.apache.org/docs-2.0/suexec.html</ulink>.
- Using suEXEC protection, user CGI scripts run under their own
-uid. This
- ensures that user CGI scripts cannot interfere with the system
- &APACHE; daemon (since it runs under its own uid), nor with
- each other (since each user has their own uid).
- </para>
- <para>
- However, when CGI scripts are run via suEXEC using standard
- Linux security, a compromised, misconfigured, or simply buggy
- user CGI script has complete access to any other file the user
- owns, such as their home directory. It also has access to any
- process running under the same uid, and so forth. Given the
- security track record of Web software, protecting the user's
- personal data from CGI programs they may install is very
- desirable.
- </para>
- <para>
- The &SEL; policy specifies that when a user CGI script is
- executed by suEXEC, a <firstterm>domain transition</firstterm>
- occurs to change the script's security label to the
- <computeroutput>httpd_sys_script_t</computeroutput> type. This
- means the user's CGI scripts run in their own confined domain
- (but still the same uid). In the default &FC; setup, the
- <computeroutput>httpd_sys_script_t</computeroutput> domain can read
- <emphasis>and write</emphasis> to files and directories that
- have the <computeroutput>httpd_sys_content_t</computeroutput>
- type. But they still cannot access files with type
- <computeroutput>user_home_t</computeroutput>, in other words the
- user's home directory.
- </para>
- <para>
- To illustrate this, here are example user names, file names,
- and websites involved. In this example, the virtual hosting
- provider has each user store their website in
+ Usando la protezione suEXEC, gli scripts CGI degli utenti vengono eseguiti sotto la loro propria
+ uid. Questo
+ assicura che gli scripts CGI degli utenti non possano interferire con il demone
+ di sistema &APACHE; (poichè è eseguito sotto la propria uid), e neanche
+ l'uno con l'altro (poichè ogni utente possiede la propria uid).
+ </para>
+ <para>
+ Comunque, quando gli scripts CGI vengono eseguiti via suEXEC usando la normale
+ sicurezza di Linux, uno script CGI di un utente, compromesso,
+ misconfigurato, o semplicemente bacato ha completo accesso ad ogni altro file
+ posseduto dall'utente, tipo la loro home directory. Esso ha anche accesso a ogni
+ processo che viene eseguito sotto lo stesso uid, e così via. Dare
+ traccia della sicurezza del software Web, proteggendo i dati personali
+ degli utenti dai programmi CGI che essi possono installare è molto
+ desiderabile.
+ </para>
+ <para>
+ La policy &SEL; specifica che quando uno script CGI utente è
+ eseguito da suEXEC, avviene una <firstterm>transizione di dominio</firstterm>
+ per cambiare l'etichetta di sicurezza dello script al
+ tipo <computeroutput>httpd_sys_script_t</computeroutput>. Questo
+ vuol dire che lo script CGI dell'utente viene eseguito nel proprio confinato dominio
+ (ma ancora sotto la stessa uid). Nelle normali installazioni &FC;, il
+ dominio <computeroutput>httpd_sys_script_t</computeroutput> può leggere
+ <emphasis>e scrivere</emphasis> nei files e directories che
+ hanno il tipo <computeroutput>httpd_sys_content_t</computeroutput>.
+ Ma non possono ancora accedere ai files con il tipo
+ <computeroutput>user_home_t</computeroutput>, in altre parole
+ la home directory utente.
+ </para>
+ <para>
+ Per illustrarvi questo, ecco un esempio di nomi utente, nomi di files,
+ e siti web coinvolti. In questo esempio, il fornitore
+ dell'host virtuale ha ogni utente con il proprio sito web in
<filename>/var/www/<replaceable>sitename</replaceable></filename>,
- and the content is all owned by the user. CGI scripts are
- allowed, and they can be installed anywhere in the user's site;
- the filename just has to end in <filename>.cgi</filename>. Here
- is an overview of the filesystem layout:
+ ed il contenuto è completamente di proprietà dell'utente. Gli scripts sono
+ permessi, e possono essere installati ovunque nel sito web dell'utente;
+ il nome del file devono solo terminare in <filename>.cgi</filename>. Ecco
+ una descrizione della conformazione del sistema:
</para>
<screen>
<command>ls -Z /var/www/</command>
@@ -548,10 +549,10 @@
drwxr-xr-x sam sam system_u:object_r:httpd_sys_content_t sammy.net
</screen>
<para>
- Here is a sample of how the &APACHE; configuration for the
- <computeroutput>example.com</computeroutput> domain might look.
- Note particularly that &APACHE; has been configured to run CGI
- scripts as the user <computeroutput>bob</computeroutput>.
+ Ecco un esempio di come la configurazione di &APACHE; per il
+ dominio <computeroutput>example.com</computeroutput> potrebbe essere.
+ Nota in particolare che &APACHE; è stato configurato per eseguire gli scripts
+ CGI come l'utente <computeroutput>bob</computeroutput>.
</para>
<programlisting>
NameVirtualHost 10.23.54.2:80
@@ -572,42 +573,42 @@
</VirtualHost>
</programlisting>
<para>
- By using the normal &APACHE; suEXEC mechanism, together with
- &SEL;, you have achieved the major security goals set out at the
- beginning of this section. However, this is still only a
- fraction of &SEL;'s power.
+ Usando il normale meccanismo suEXEC &APACHE;, insieme a
+ &SEL;, hai ottenuto l'obiettivo di sicurezza principale descritto
+ all'inizio di questa sezione. Comunque, questa è solo
+ una frazione del potere di &SEL;.
</para>
</section>
<section id="sn-using-other-types">
- <title>Using Other Types To Lock Down CGI Scripts</title>
+ <title>Usare altri Tipi per bloccare gli scripts CGI</title>
<para>
- In the section <xref linkend="sn-suexec-and-cgi-scripts"/> you
- saw that a user's CGI script running in the
- <computeroutput>httpd_sys_script_t</computeroutput> domain can
- read and write all Web content. In many scenarios, this is
- undesirable. For example, the Pyblosxom blog software (<ulink
- url="http://roughingit.subtlehints.net/pyblosxom/">http://roughingit.subtlehints.net/pyblosxom/</ulink>)
- reads in a number of plain text blog entry files, and renders
- them to HTML on the fly to the client. For this, it only needs
- read access to the blog entry files. Ideally, if Pyblosxom was
- compromised or had a bug, it would not have the ability to
- modify or delete your Web log entries.
- </para>
- <para>
- &SEL; allows you to achieve this by defining more types. You
- grant <computeroutput>httpd_sys_script_t</computeroutput> the
- access to those types that you desire. The default &APACHE;
- policy defines a number of other types by default.
+ Nella sezione <xref linkend="sn-suexec-and-cgi-scripts"/> hai
+ visto che uno script CGI eseguito nel
+ dominio <computeroutput>httpd_sys_script_t</computeroutput> può
+ leggere e scrivere tutto il contenuto Web. In molti scenari, ciò
+ è indesiderato. Per esempio, il software di blog Pyblosxom (<ulink
+ url="http://roughingit.subtlehints.net/pyblosxom/">http://roughingit.subtlehints.net/pyblosxom/</ulink>)
+ legge da un certo numero di file di semplice testo, e li renderizza
+ in HTML al volo per il client. Per questo, ha solo bisogno
+ di accesso in lettura ai file di contenuto del blog. Idealmente, se Pyblosxom fosse
+ compromesso o avesse un errore, esso non avrebbe la capacità di
+ modificare o cancellare le tue immissioni Web.
+ </para>
+ <para>
+ &SEL; ti permette di ottenere questo con la definizione di più tipi. Tu
+ garantirai ad <computeroutput>httpd_sys_script_t</computeroutput> di
+ accedere ai quei tipi che desideri. La policy predefinita di &APACHE;
+ definisce già un certo numero di tipi diversi.
</para>
<variablelist>
- <title>User-controllable types defined by the &SEL;
- policy</title>
+ <title>Tipi definiti dalla policy di &SEL; controllabili
+ dall'utente</title>
<varlistentry>
<term><computeroutput>httpd_sys_script_ro_t</computeroutput></term>
<listitem>
<para>
- A CGI script may only read files and directories with this
- type.
+ Uno script CGI può solo leggere files e directories con questo
+ tipo.
</para>
</listitem>
</varlistentry>
@@ -615,8 +616,8 @@
<term><computeroutput>httpd_sys_script_ra_t</computeroutput></term>
<listitem>
<para>
- Like the previous type, except a CGI script may also
- append more data (useful for log files, etc).
+ Come il tipo precedente, eccettuato che uno script CGI può anche
+ appendere dati (utile per i files di log, etc).
</para>
</listitem>
</varlistentry>
@@ -624,8 +625,8 @@
<term><computeroutput>httpd_sys_script_rw_t</computeroutput></term>
<listitem>
<para>
- Content that a CGI script may change in any way, including
- deletion.
+ Contentenuti che uno script CGI può cambiare in qualsiasi modo, inclusa
+ la cancellazione.
</para>
</listitem>
</varlistentry>
@@ -633,7 +634,7 @@
<term><computeroutput>httpd_sys_content_t</computeroutput></term>
<listitem>
<para>
- See below.
+ Vedi sotto.
</para>
</listitem>
</varlistentry>
@@ -641,41 +642,41 @@
<term><computeroutput>httpd_sys_script_exec_t</computeroutput></term>
<listitem>
<para>
- The type for CGI executables.
- <computeroutput>httpd_t</computeroutput> cannot execute
- other types such as
+ Il tipo per gli eseguibili CGI.
+ <computeroutput>httpd_t</computeroutput> non può eseguire
+ altri tipi come
<computeroutput>httpd_sys_script_rw_t</computeroutput>.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
- The &FC; &LOCALVER; release introduces a new <firstterm>policy
- boolean</firstterm> called
- <computeroutput>httpd_unified</computeroutput>. If this boolean
- is enabled, it means that
- <computeroutput>httpd_sys_content_t</computeroutput> (the type
- used for everything up until this point) is treated as the
- <emphasis>union</emphasis> of all the other types above. If
- this boolean is disabled, it means that (for example) in order
- for a CGI script to be executed by
- <computeroutput>httpd_t</computeroutput>, it must be labeled
- with the
- <computeroutput>httpd_sys_script_exec_t</computeroutput> type.
- And it also means that in order for a CGI script to write data,
- the target file must be labeled with
- <computeroutput>httpd_sys_script_rw_t</computeroutput>, as
- above.
- </para>
- <para>
- The <computeroutput>httpd_unified</computeroutput> boolean
- was introduced so that one could, for the most part, use
- a typical &APACHE; installation without a good grasp on file labeling
- and security contexts. However, disabling this boolean grants
- far greater security, and is highly recommended.
+ La versione &FC; &LOCALVER; introduce una nuova <firstterm>policy
+ booleana</firstterm> chiamata
+ <computeroutput>httpd_unified</computeroutput>. Se questa booleana
+ è abilitata, questo vuol dire che
+ <computeroutput>httpd_sys_content_t</computeroutput> (ol tipo
+ usato per ogni cosa fino a questo punto) è trattato come
+ l'<emphasis>unione</emphasis> di tutti gli altri tipi succitati. Se
+ questa booleana è disabilitata, vuol dire che (per esempio) un CGI script
+ per poter essere eseguito da
+ <computeroutput>httpd_t</computeroutput>, deve essere etichettato
+ con il tipo
+ <computeroutput>httpd_sys_script_exec_t</computeroutput>.
+ E vuol dire anche che un CGI script per poter scrivere dati,
+ il file destinazione deve essere etichettato con
+ <computeroutput>httpd_sys_script_rw_t</computeroutput>, come
+ sopra.
+ </para>
+ <para>
+ La booleana <computeroutput>httpd_unified</computeroutput>
+ è stata introdotta affinchè chiunque possa, per la maggior parte, usare
+ una installazione tipica di &APACHE; senza conoscenza stretta sull'etichettatura
+ dei files e dei contesti di sicurezza. Comunque, disabilitando questa boleana si garantisce
+ una sicurezza di gran lunga superiore, ed è caldamente raccomandato.
</para>
<para>
- Now, examine how Bob might set up a Pyblosxom installation:
+ Ora, esaminiamo come Bob potrebbe configurare un installazione Pyblosxom:
</para>
<screen>
# cd /var/www/example.com
@@ -696,124 +697,124 @@
-rw-r--r-- bob bob user_u:object_r:httpd_sys_script_ro_t firstpost.txt
...
</screen>
- <para>Note that the index.cgi executable is marked as
- <computeroutput>httpd_sys_script_exec_t</computeroutput>, and
- the rest of the data is marked as
- <computeroutput>httpd_sys_script_ro_t</computeroutput>. This
- protects all the blog data from a compromised, misconfigured, or
- buggy Pyblosxom.
- </para>
- <para>
- One other important thing to note about these types is that by
- default, <computeroutput>httpd_t</computeroutput>
- <emphasis>cannot</emphasis> access any of them except for
- <computeroutput>httpd_sys_content_t</computeroutput>. In other
- words, by default &APACHE; cannot directly access content
- intended for your CGI scripts.
- </para>
- <para>
- Consider the case of a small intranet, accessed via a CGI
- script, which has some public content, and some
- password-protected content. It stores its data in a large
- database file. In this case, you would label the database file
- as <computeroutput>httpd_sys_script_rw_t</computeroutput> so
- that the intranet CGI could write to it. But if you allow
- <computeroutput>httpd_t</computeroutput> access to
- <computeroutput>httpd_sys_script_rw_t</computeroutput>, then if
- &APACHE; was compromised or simply misconfigured, it could gain
- access to the database directly, bypassing the access control
- that the CGI script was doing for the password-protected
- content.
+ <para>Nota che l'eseguibile index.cgi è marcato come
+ <computeroutput>httpd_sys_script_exec_t</computeroutput>, ed
+ il resto dei dati è marcato come
+ <computeroutput>httpd_sys_script_ro_t</computeroutput>. Questo
+ protegge tutti i dati del blog da un compromesso, misconfigurato, o
+ bacato Pyblosxom.
+ </para>
+ <para>
+ Un altra cosa importante da notare su questi tipi è che per
+ impostazione predefinita, <computeroutput>httpd_t</computeroutput>
+ <emphasis>non può</emphasis> accedere a nessuno di loro eccettuato
+ <computeroutput>httpd_sys_content_t</computeroutput>. In altre
+ parole, di base &APACHE; non può accedere direttamente al contenuto
+ inteso per i tuoi script CGI.
+ </para>
+ <para>
+ Considera il caso di una piccola intranet, a cui si può accedere via CGI
+ script, che ha qualche contenuto pubblico e qualche
+ contenuto protetto da password. Essa registra i dati in un grande
+ file database. In questo caso, vorrai etichettare il file database
+ come <computeroutput>httpd_sys_script_rw_t</computeroutput> affinchè
+ lo script CGI possa scriverci su. Ma se permetti
+ ad <computeroutput>httpd_t</computeroutput> l'accesso a
+ <computeroutput>httpd_sys_script_rw_t</computeroutput>, allora se
+ &APACHE; venisse compromesso o semplicemente misconfigurato, esso potrebbe ottenere
+ l'accesso diretto al database, bypassando il controllo d'accesso
+ che lo script CGI faceva per il contenuto protetto da
+ password.
</para>
</section>
<section id="sn-debugging-and-customizing">
<title>Debugging Problems and Customizing the Policy</title>
<para>
- When first deploying &SEL; and &APACHE;, if your &APACHE;
- configuration varies far from the &FC; or &RHEL; defaults, you
- will likely encounter issues related to the &SEL; policy. This
- section discusses analyzing policy denials, and doing simple
- customizations of the policy.
+ Quando applichi per la prima volta &SEL; e &APACHE;, se la tua configurazione
+ &APACHE; varia molto da quella predefinita di &FC; o &RHEL;, potrai
+ incorrere in alcuni problemi con la policy &SEL;. Questa
+ sezione discute analizzando i dinieghi della policy, e facendo semplici
+ personalizzazioni della policy.
</para>
<section id="sn-httpd-booleans">
- <title>Simple Customization</title>
+ <title>Semplice personalizzazione</title>
<para>
- The first major tool for policy customization is
- <command>system-config-securitylevel</command>. It
- has a number of policy booleans:
+ Il primo principale strumento per la personalizzazione delle policy è
+ <command>system-config-securitylevel</command>. Esso
+ possiede un certo numero di policy boolene:
</para>
<variablelist>
- <title>Boolean options for &APACHE;</title>
- <varlistentry><term><computeroutput>httpd_enable_cgi</computeroutput> (Allow httpd cgi support)</term>
+ <title>Opzioni booleane per &APACHE;</title>
+ <varlistentry><term><computeroutput>httpd_enable_cgi</computeroutput> (Permette ad httpd il supporto cgi)</term>
<listitem>
- <para>Whether or not to allow CGI scripts to run at all.</para>
+ <para> Quando o no permettere agli script CGI di essere eseguiti.</para>
</listitem>
</varlistentry>
- <varlistentry><term><computeroutput>httpd_enable_homedirs</computeroutput> (Allow httpd to read home directories)</term>
+ <varlistentry><term><computeroutput>httpd_enable_homedirs</computeroutput> (Permette ad httpd di leggere le home directories)</term>
<listitem>
<para>
- Whether or not to allow &APACHE; to access top-level home
- directories. This does not allow for reading of the
- <emphasis>content</emphasis> of home directories
+ Quando o no permettere ad &APACHE; di accedere alle home
+ directories. Questo non consente la lettura del
+ <emphasis>contenuto</emphasis> delle home directories
(<computeroutput>user_home_t</computeroutput>).
</para>
</listitem>
</varlistentry>
- <varlistentry><term><computeroutput>httpd_ssi_exec</computeroutput> (Allow httpd to run SSI executables in the same domain as system CGI scripts)</term>
+ <varlistentry><term><computeroutput>httpd_ssi_exec</computeroutput> (Permette ad httpd di eseguire gli eseguibili SSI nello stesso dominio dei CGI scripts di sistema)</term>
<listitem>
<para>
- If enabled, this boolean causes &APACHE; to transition to the
- <computeroutput>httpd_sys_script_t</computeroutput> when
- executing a shell.
+ Se abilitata, questa booleana causa la transizione di &APACHE; verso
+ <computeroutput>httpd_sys_script_t</computeroutput> quando
+ esegue una shell.
</para>
</listitem>
</varlistentry>
- <varlistentry><term><computeroutput>httpd_unified</computeroutput> (Unify httpd handling of all content files)</term>
+ <varlistentry><term><computeroutput>httpd_unified</computeroutput> (Unifica il modo in cui httpd manipola tutti i files dei contenuti)</term>
<listitem>
<para>
- This boolean controls whether
- <computeroutput>httpd_sys_content_t</computeroutput> is
- treated as the union of all the other types such as
- <computeroutput>httpd_sys_script_exec_t</computeroutput>. See
+ Questa booleana controlla quando
+ <computeroutput>httpd_sys_content_t</computeroutput> è
+ trattata come l'unione di tutti gli altri tipi come
+ <computeroutput>httpd_sys_script_exec_t</computeroutput>. Vedi
<xref linkend="sn-using-other-types"/>
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
- In addition, you can disable &SEL; enforcement for &APACHE;
- entirely with <application>system-config-securitylevel</application>.
+ Inoltre, con <application>system-config-securitylevel</application>,
+ puoi interamente disabilitare il &SEL; enforcement per &APACHE;.
</para>
<procedure>
<step>
<para>
- First, click the <guilabel>&SEL;</guilabel> tab.
+ Primo, clicca il tab <guilabel>&SEL;</guilabel>.
</para>
</step>
<step>
<para>
- Click on the <guimenu>Transition</guimenu> tree.
+ Clicca sull'albero <guimenu>Transizioni</guimenu>.
</para>
</step>
<step>
<para>
- Check <guilabel>Disable &SEL; protection for
+ Controlla <guilabel>Disabilita la protezione &SEL; per
&APACHE;</guilabel>
</para>
</step>
<step>
<para>
- Execute <command>/etc/init.d/httpd restart</command>
+ Esegui <command>/etc/init.d/httpd restart</command>
</para>
</step>
</procedure>
</section>
<section id="sn-policy-debugging">
- <title>Policy Debugging</title>
+ <title>Debugging della Policy </title>
<para>
- It is very important to monitor
- <filename>/var/log/messages</filename> for any denials due to
- the &SEL; policy. Suppose that you see the following denial:
+ E' importantissimo controllare
+ <filename>/var/log/messages</filename> per ogni diniego causato dalla
+ policy &SEL;. Supponi di vedere il seguente diniego:
</para>
<screen>
Oct 19 17:54:59 hostname kernel: audit(1098050626.859:0): avc: denied { write } \
@@ -822,72 +823,72 @@
tcontext=user_u:object_r:httpd_sys_script_ro_t tclass=dir
</screen>
<para>
- The <computeroutput>{ write }</computeroutput> is telling you
- that the denial involves writing to an object. The
- <computeroutput>tclass=dir</computeroutput> says that the object
- in question is a directory. The two most crucial parts are the
- <computeroutput>scontext</computeroutput> and
- <computeroutput>tcontext</computeroutput>, which contain the
- types of the subject
- (<computeroutput>httpd_sys_script_t</computeroutput>) and the
- object (<computeroutput>httpd_sys_script_ro_t</computeroutput>).
- Notice there is other auxilliary information as well; since the
- object is a file, there is its name
- (<computeroutput>pyblosxom</computeroutput>) and inode number
+ La <computeroutput>{ write }</computeroutput> ti dice
+ che il diniego riguarda la scrittura di un oggetto. La
+ <computeroutput>tclass=dir</computeroutput> ti dice che l'oggetto
+ in questione è una directory. Le due parti più cruciali sono
+ l'<computeroutput>scontext</computeroutput> e
+ <computeroutput>tcontext</computeroutput>, che contengono i
+ tipi del soggetto
+ (<computeroutput>httpd_sys_script_t</computeroutput>) e
+ l'oggetto (<computeroutput>httpd_sys_script_ro_t</computeroutput>).
+ Nota che c'è un'altra informazione ausiliaria comunque; poichè
+ l'oggetto è un file, c'è il suo nome
+ (<computeroutput>pyblosxom</computeroutput>) ed il suo numero di inode
(<computeroutput>4374593</computeroutput>).
</para>
<para>
- In other words, the Python CGI script is trying to write to
- a directory that is marked read-only. There are many reasons this could
- happen; perhaps the script was misconfigured or buggy, for
- example. But in this particular case, it turns out that the
- Python interpreter normally tries to generate
- <filename>.pyc</filename> files for each
- <filename>.py</filename> file it encounters. If the directory
- is marked as
- <computeroutput>httpd_sys_script_ro_t</computeroutput>, then it
- will not be able to create new files in it, and you will see the
- denial. This is a very common problem with Python CGI scripts.
+ In altre parole, il CGI script in Python sta provando a scrivere in
+ una directory che è contrassegnata di sola lettura. Ci sono diverse ragioni percui ciò può
+ accadere; potrebbe essere che lo script sia misconfigurato o bacato, per
+ esempio. Ma in questo caso particolare, viene fuori che
+ l'interprete Python normalmente usa generare
+ files <filename>.pyc</filename> per ogni file
+ <filename>.py</filename> che incontra. Se questa directory
+ è marcata come
+ <computeroutput>httpd_sys_script_ro_t</computeroutput>, allora
+ non avrà la possibilità di creare nuovi files, e vedrai
+ il diniego. Questo è un problema molto comune con gli script CGI in Python.
</para>
</section>
<section id="sn-simple-changes-to-policy-source">
- <title>Simple Changes to Policy Sources</title>
+ <title>Semplici cambiamenti al sorgente della Policy</title>
<para>
- The issue with Python mentioned in <xref
- linkend="sn-policy-debugging"/> is not an issue with &SEL;,
- since it is Python that is trying to write to a directory of
- supposedly read-only objects. To deal with these spurious
- errors that don't affect the functionality of the CGI script,
- you can direct &SEL; to ignore them. &SEL; supports a
- <computeroutput>dontaudit</computeroutput> directive in the
- policy sources, but you must rebuild a policy from the source.
- To install the policy sources, use <command>up2date</command> or
- <command>yum</command> to install the
- <computeroutput>selinux-policy-targeted-sources</computeroutput>
- package.
- </para>
- <para>
- To get the rule syntax you need, you can use a
- <command>audit2allow</command>, which will generate the SELinux
- policy to allow a set of logged denials. For example, you
- could invoke <command>audit2allow -i /var/log/messages
- -l</command>. This generates allow rules for every denial since
- a policy was last loaded. The output for the denial in <xref
- linkend="sn-policy-debugging"/> would look like this:
+ Il problema con Python menzionato nella <xref
+ linkend="sn-policy-debugging"/> non è un problema di &SEL;,
+ poichè è Python che prova a scrivere in una directory di
+ supposti oggetti di sola lettura. Per risolvere questi errori
+ spuri, che non hanno effetto sulla funzionalità dello script CGI,
+ puoi direttamente dire a &SEL; di ignorarli. &SEL; supporta una
+ direttiva <computeroutput>dontaudit</computeroutput> nei
+ sorgenti delle policy, ma devi ricompilare la policy dai sorgenti.
+ Per installare i sorgenti della policy, usa il tool <command>up2date</command> o
+ <command>yum</command> per installare il
+ pacchetto
+ <computeroutput>selinux-policy-targeted-sources</computeroutput>.
+ </para>
+ <para>
+ Per avere la sintassi della regola di cui hai bisogno, puoi usare un
+ <command>audit2allow</command>, che genererà la policy
+ SELinux per permettere un gruppo di dinieghi loggati. Per esempio, puoi
+ invocare <command>audit2allow -i /var/log/messages
+ -l</command>. Questo genererà regole di consenso per ogni diniego finchè
+ una policy verrà alla fine caricata. L'output per il diniego nella <xref
+ linkend="sn-policy-debugging"/> sarà come questo:
</para>
<screen>
<command>audit2allow -i /var/log/messages -l</command>
allow httpd_sys_script_t httpd_sys_script_ro_t:dir { write };
</screen>
<para>
- However, in this case you don't want to actually
- <emphasis>allow</emphasis> this operation, you simply want to
- avoid audit messages from it. &SEL; supports a directive called
- <computeroutput>dontaudit</computeroutput> instead of
- <computeroutput>allow</computeroutput>. Now your generated
- policy is <computeroutput>dontaudit httpd_sys_script_t
- httpd_sys_script_ro_t:dir { write };</computeroutput>. To
- add this to the system policy, follow these steps:
+ Comunque, in questo caso, non vorrai attualmente
+ <emphasis>permettere</emphasis> questa operazione, semplicemente vorrai
+ evitare di avere ulteriori messaggi di audit. &SEL; supporta una direttiva chiamata
+ <computeroutput>dontaudit</computeroutput> da usare al posto di
+ <computeroutput>allow</computeroutput>. Ora la tua policy generata
+ è <computeroutput>dontaudit httpd_sys_script_t
+ httpd_sys_script_ro_t:dir { write };</computeroutput>. Per
+ aggiungerla alla policy di sistema, seguite i seguenti passi:
</para>
<procedure>
<step>
@@ -897,9 +898,9 @@
</step>
<step>
<para>
- Use your favorite editor to create the file
- <filename>domains/misc/local.te</filename>, and
- add the rule above to it (or <command>echo "dontaudit httpd_sys_script_t httpd_sys_script_ro_t:dir { write };" > domains/misc/local.te</command>).
+ Usa il tuo editor di testi preferito per creare il file
+ <filename>domains/misc/local.te</filename>, ed
+ aggiungi la regola succitata (oppure <command>echo "dontaudit httpd_sys_script_t httpd_sys_script_ro_t:dir { write };" > domains/misc/local.te</command>).
</para>
</step>
<step>
@@ -909,128 +910,128 @@
</step>
</procedure>
<caution>
- <title>Analyze <command>audit2allow</command> output carefully</title>
+ <title>Analizza l'output di <command>audit2allow</command> con attezione</title>
<para>
- You should not simply place all of the output from
- <command>audit2allow</command> in your
- <filename>domains/misc/local.te</filename>. It is very easy to
- compromise the security of your system that way; for example,
- using <computeroutput>allow</computeroutput> instead of
- <computeroutput>dontaudit</computeroutput> above would have
- rendered the security from the
- <computeroutput>httpd_sys_script_ro_t</computeroutput> type
- useless.
- </para>
- <para>
- For more information about policy debugging and customization
- in general, refer to the <citetitle>Red Hat &SEL; Policy
- Guide</citetitle>, available online at <ulink
+ Non dovrai semplicemente mettere tutto l'output di
+ <command>audit2allow</command> nel tuo
+ <filename>domains/misc/local.te</filename>. E' molto facile
+ compromettere la sicurezza del sistema in questo modo; per esempio,
+ usando <computeroutput>allow</computeroutput> invece di
+ <computeroutput>dontaudit</computeroutput> si renderÃ
+ inusabile la sicurezza
+ fornita dal tipo
+ <computeroutput>httpd_sys_script_ro_t</computeroutput>.
+ </para>
+ <para>
+ Per maggiori informazioni sul debugging e la personalizzazione
+ in generale, fa riferimento alla <citetitle>Red Hat &SEL; Policy
+ Guide</citetitle>, disponibile online su <ulink
url="http://www.redhat.com/docs">http://www.redhat.com/docs</ulink>.
</para>
</caution>
</section>
</section>
<section id="sn-strict-policy">
- <title>Differences Between Strict and Targeted Policy</title>
+ <title>Differenze fra policy Strict e Targeted</title>
<para>
- The fundamental difference with the strict policy is that it
- restricts every process, including user logins, instead of just
- a few selected daemons. This has important ramifications for
- &APACHE;, because ordinary users are often involved in providing
- and controlling Web content.
+ La differenza fondamentale con la policy strict è che questa
+ restringe ogni processo, inclusi i login utente, invece di soli
+ pochi demoni selezionati. Questo ha importanti ramificazioni per
+ &APACHE;, perchè gli utenti ordinari sono spesso coinvolti nel fornire
+ e controllare il contenuto Web.
</para>
<para>
- In the default strict policy, there are two user login types,
- <computeroutput>user_t</computeroutput> and
- <computeroutput>staff_t</computeroutput>. The strict Apache
- policy defines an additional set of types for each user login
- type, replacing
+ Nella policy strict predefinita, ci sono due tipi di login utente,
+ <computeroutput>user_t</computeroutput> e
+ <computeroutput>staff_t</computeroutput>. La policy strict
+ di Apache definisce un ulteriore gruppo di tipi per ogni tipo
+ di login utente, sostituendo
<computeroutput><replaceable>_sys_</replaceable></computeroutput>
- with <computeroutput>_user_</computeroutput> and
- <computeroutput>_staff_</computeroutput>. For example, this gives
- <computeroutput>httpd_user_script_ro_t</computeroutput> and
+ con <computeroutput>_user_</computeroutput> e
+ <computeroutput>_staff_</computeroutput>. Per esempio, questo ti da
+ <computeroutput>httpd_user_script_ro_t</computeroutput> e
<computeroutput>httpd_staff_script_exec_t</computeroutput>.
- This provides for a stronger, mandatory separation between
- users, administrators, and the system. An ordinary user is
- prevented from reading system Web content directly, and a
- compromised or misconfigured system CGI script is prevented from
- reading a user's content.
+ Questo fornisce una più forte, mandatoria separazione tra gli
+ utenti, administratori, ed il sistema. Un utente ordinario è
+ prevenuto dal leggere il contenuto Web di sistema direttamente, ed un
+ compromesso o misconfigurato script CGI di sistema è prevenuto dal
+ leggere il contenuto di un utente.
</para>
</section>
<section id="sn-further-approaches">
- <title>Further Approaches for Stronger Security</title>
+ <title>Ulteriori approcci per una maggior sicurezza</title>
<para>
- For some, the default &APACHE; policy may actually not be
- expressive enough. This section discusses extending
- and fundamentally rewriting the &APACHE; policy for even
- stronger security. It is assumed that you are familiar with
- the concepts discussed earlier. This section will generally
- only outline solutions, instead of going into step-by-step
- detail.
+ Per alcuni, la policy predefinita per &APACHE; può attualmente non
+ sembrare abbastanza espressiva. Questa sezione discute l'estensione
+ e fondamentalmente la riscrittura della policy &APACHE; per ottenere
+ una sicurezza più forte. Si da per assunto che hai familiarità con
+ i concetti discussi prima. Questa sezione generalmente indicherÃ
+ soluzioni a grandi linee, invece di scendere nel dettaglio
+ passo passo.
</para>
<section id="sn-cgi-subdomains">
- <title>Individual Domains for Particular CGI Scripts</title>
+ <title>Domini individuali per particolari scripts CGI</title>
<para>
- Using the default policy, a compromise of one CGI script means
- a compromise of <emphasis>all</emphasis> of them. This is
- because they all run in the same domain
- (<computeroutput>httpd_sys_script_t</computeroutput>) with
- access to the same other types (e.g.
- <computeroutput>httpd_sys_script_rw_t</computeroutput>). Put a
- different way, types are security equivalence classes.
- </para>
- <para>
- Most of the type definitions and permissions regarding CGI
- scripts are in
- <filename>/etc/selinux/<replaceable>policyname</replaceable>/src/policy/macros/program/apache_macros.te</filename>.
- Open that file up in your favorite editor. This entire file
- is definining an <command>m4</command> macro called
- <computeroutput>apache_domain</computeroutput>.
+ Usando la policy predefinita, la compromissione di uno script CGI vuol dire
+ comprometterli <emphasis>tutti</emphasis>. Questo perchè
+ vengono eseguiti tutti sotto lo stesso dominio
+ (<computeroutput>httpd_sys_script_t</computeroutput>) con
+ accesso agli stessi altri tipi (es.
+ <computeroutput>httpd_sys_script_rw_t</computeroutput>). Mettiamola
+ in un altro modo, i tipi sono classi di sicurezza equivalente.
+ </para>
+ <para>
+ Molte delle definizioni e dei permessi che riguardano gli scripts
+ CGI sono in
+ <filename>/etc/selinux/<replaceable>policyname</replaceable>/src/policy/macros/program/apache_macros.te</filename>.
+ Aprite il file con il vostro editor di testi preferito. Questo intero file
+ definisce una macro <command>m4</command> chiamata
+ <computeroutput>apache_domain</computeroutput>.
</para>
<note>
- <title>Understanding <command>m4</command> in one paragraph</title>
+ <title>Comprendere <command>m4</command> in un paragrafo</title>
<para>
- The
+ La
<computeroutput>define(`apache_domain',`</computeroutput>
- begins the macro definition. Inside the definition, the
- <computeroutput>$1</computeroutput> represents the parameter
- passed to the macro.
+ cominica la definizione della macro. All'interno della definizione, il
+ <computeroutput>$1</computeroutput> rappresenta il parametro
+ passato alla macro.
</para>
</note>
<para>
- If you then look in
+ Se quindi dai uno sguardo in
<filename>/etc/selinux/<replaceable>policyname</replaceable>/src/policy/domains/program/apache.te</filename>,
- you'll see the following invocation:
+ vedrai la seguente invocazione:
</para>
<programlisting>
apache_domain(sys)
</programlisting>
<para>
- This single line then generates a large set of types and
- rules, substituting <computeroutput>sys</computeroutput> for
- every <computeroutput>$1</computeroutput>. Suppose that you
- have two CGI programs you want to protect: a blog
- installation, and a wiki installation. Because these domains
- will be largely similar, you will create a macro. Open up the
- file you are using for local policy,
+ Questa singola linea quindi genera un gran numero di tipi e
+ regole, sostituendo <computeroutput>sys</computeroutput> per
+ ogni <computeroutput>$1</computeroutput>. Supponi che
+ hai due programmi CGI che vuoi proteggere: una installazione
+ blog, ed una installazione wiki. Siccome questi domini
+ sono molto similari, creerai una macro. Apri il
+ file che stai usando per la policy locale,
<filename>/etc/selinux/<replaceable>policyname</replaceable>/src/policy/domains/misc/local.te</filename>.
</para>
<para>
- In order to separate the blog and the wiki, you need to create
- separate types (domains) for them, allow
- <computeroutput>httpd_t</computeroutput> the ability to
- transition to those domains, and create new derived types to
- label their data. This is very similar to what most of
- <computeroutput>apache_domain</computeroutput> already does,
- but unfortunately that macro does too much for your simple
- needs. However, you can use that macro as a guide for creating
- your macro.
+ Per poter separare il blog dalla wiki, avrai bisogno di creare
+ per loro tipi separati (domini), permettere ad
+ <computeroutput>httpd_t</computeroutput> la capacità di
+ transitare verso questi domini, e creare nuovi tipi derivati per
+ etichettare i loro dati. Tutto ciò è abbastanza simile a quello che
+ il dominio <computeroutput>apache_domain</computeroutput> già fa,
+ ma sfortunatamente quella macro fa fin troppo per le tue semplici
+ esigenze. Comunque, puoi usare questa macro come guida per crearne
+ una tua.
</para>
<procedure>
<step>
<para>
- Start with the macro skeleton:
+ Comincia con lo scheletro della macro:
</para>
<programlisting>
define(`apache_script_domain',`
@@ -1042,13 +1043,13 @@
</step>
<step>
<para>
- Define types for the CGI script executables (similar to
- <computeroutput>httpd_sys_script_exec_t</computeroutput>),
- and domains for the script processes (similar to
- <computeroutput>httpd_sys_script_t</computeroutput>). You
- also need to authorize the
- <computeroutput>system_r</computeroutput> role for the
- type.
+ Definisci i tipi per gli script eseguibili CGI (similmente ad
+ <computeroutput>httpd_sys_script_exec_t</computeroutput>),
+ ed i domini per i processi degli scripts (similmente a
+ <computeroutput>httpd_sys_script_t</computeroutput>). Hai
+ anche bisogno di autorizzare il
+ ruolo <computeroutput>system_r</computeroutput> per il
+ tipo.
</para>
<programlisting>
type httpd_sys_$1_exec_t, file_type, sysadmfile;
@@ -1058,9 +1059,9 @@
</step>
<step>
<para>
- Allow &APACHE; to execute the script, and cause it to
- transition to the script domain. You also want it to be
- able to signal your CGI script.
+ Permetti ad &APACHE; di eseguire lo script, e provocane la
+ transizione verso il dominio dello script. Vorrai altresì che sia
+ capace di segnalare il tuo script CGI.
</para>
<programlisting>
domain_auto_trans(httpd_t, httpd_sys_$1_exec_t, httpd_sys_$1_t)
@@ -1069,11 +1070,11 @@
</step>
<step>
<para>
- Define new types for content. The following demonstrates
- a read-only type and a read-write type, but you can easily
- define different, more refined types. After defining
- them, grant your CGI domain the access to them that you
- want.
+ Definisci nuovi tipi per i contenuti. Cio che segue mostra
+ un tipo sola-lettura ed un tipo sola scrittura, ma puoi facilmente
+ definirne differenti, tipi più raffinati. Dopo averli
+ definiti, garantisci al tuo dominio CGI l'accesso a quelli che
+ vuoi.
</para>
<programlisting>
type httpd_sys_$1_ro_t, file_type, sysadmfile;
@@ -1085,18 +1086,18 @@
<note>
<title>User domains in strict policy</title>
<para>
- On a strict policy system, you also need to allow the
- user domain to manage files with your new types. See
+ Su un sistema con policy strict, devi anche permettere al
+ dominio utente di manipolare i files con i nuovi tipi. Vedi
<computeroutput>apache_domain</computeroutput>.
</para>
</note>
</step>
<step>
<para>
- Now at this point, you need to give your new domain
- permissions. There are a lot of permissions defined in
- <computeroutput>apache_domain</computeroutput>. You can
- copy the core of those.
+ Adesso a questo punto, devi fornire i permessi al nuovo
+ dominio. Ci sono molti permessi definiti nel dominio
+ <computeroutput>apache_domain</computeroutput>. Puoi
+ copiarne il cuore.
</para>
<programlisting>
# Copied from apache_macros, more is needed
@@ -1113,85 +1114,85 @@
...
</programlisting>
<para>
- There are actually more permissions likely to be
- necessary; they have been omitted for brevity.
+ Attualmente ci sono ancora permessi che potrebbero essere
+ necessari; sono stati omessi per brevità .
</para>
</step>
<step>
<para>
- You can now use your new macro to create the actual types:
+ Adesso puoi usare la nuova macro per creare i tipi attuali:
</para>
<programlisting>
apache_script_domain(wiki)
apache_script_domain(blog)
</programlisting>
<para>
- Looking at your macro definition, you can mentally
- substitute <computeroutput>wiki</computeroutput> and
- <computeroutput>blog</computeroutput> for
- <computeroutput>$1</computeroutput> and see what has
- happened. You can easily define quite a bit of policy,
- having built the macro.
+ Osservando le definizioni della tua macro, puoi mentalmente
+ sostituire <computeroutput>wiki</computeroutput> e
+ <computeroutput>blog</computeroutput> con
+ <computeroutput>$1</computeroutput> e vedere cos'è
+ successo. Puoi facilmente definire che specie di policy,
+ ha costruito la macro.
</para>
</step>
<step>
<para>
- Execute a <command>make reload</command> in the source
- directory. Debug any problems that occur.
+ Eseguite un <command>make reload</command> nella directory
+ dei sorgenti. Esegui il debug di ogni problema che occorre.
</para>
</step>
<step>
<para>
- Finally, you need to label your data. Use the
- <command>chcon</command> command to do this. For example,
- the wiki CGI executable should be labeled as
- <computeroutput>httpd_sys_wiki_exec_t</computeroutput>,
- its read-only data as
- <computeroutput>httpd_sys_wiki_ro_t</computeroutput>, and
- its database as
- <computeroutput>httpd_sys_wiki_rw_t</computeroutput>, etc.
- Similarly for the blog.
+ In fine, dovrai rietichettare i tuoi dati. Usa il
+ comando <command>chcon</command> per farlo. Per esempio,
+ gli eseguibili del CGI wiki dovranno essere etichettati come
+ <computeroutput>httpd_sys_wiki_exec_t</computeroutput>,
+ ed i suoi dati di sola lettura come
+ <computeroutput>httpd_sys_wiki_ro_t</computeroutput>, ed
+ il suo database come
+ <computeroutput>httpd_sys_wiki_rw_t</computeroutput>, etc.
+ In modo simile per il blog.
</para>
</step>
</procedure>
</section>
<section id="sn-multiple-httpd-subdomains">
- <title>Multiple HTTP Subdomains</title>
+ <title>Sottodomini HTTP multipli</title>
<para>
- In the virtual hosting setup outlined in <xref
- linkend="sn-suexec-and-cgi-scripts"/>, a compromise or
- misconfiguration of the main &APACHE;
- (<computeroutput>httpd_t</computeroutput>) means all sites are
- affected. It would be nice if you could actually have
- multiple &APACHE; servers, each running in their own domain;
- for example,
- <computeroutput>httpd_<replaceable>site</replaceable>_t</computeroutput>.
- This subsection simply discusses the problems and outlines
- possible solutions.
- </para>
- <para>
- Looking at the current policy, it is fairly obvious that in
- order to accomplish this goal, you will need to essentially
- rewrite it from scratch. The entire policy is predicated on a
- single <computeroutput>httpd_t</computeroutput>. The main
- idea would be to change it into a macro, along the lines of what you did
- with <computeroutput>apache_script_domain</computeroutput> in
+ Nell'installazione hosting virtuale descritta in <xref
+ linkend="sn-suexec-and-cgi-scripts"/>, una compromisione o
+ misconfigurazione del server principale &APACHE;
+ (<computeroutput>httpd_t</computeroutput>) significa che tutti i siti sono
+ affetti. Sarebbe bello se tu potessi attalmente avere
+ servers &APACHE; multipli, ogniuno eseguito nel proprio dominio;
+ per esempio,
+ <computeroutput>httpd_<replaceable>site</replaceable>_t</computeroutput>.
+ Questa sottosezione discute semplicemente i problemi e ne delinea
+ le possibili soluzioni.
+ </para>
+ <para>
+ Osservando la policy corrente, sembra abbastanza ovvio che per
+ conseguire un simile obbiettivo, hai bisogno essenzialmente
+ di riscriverla da capo. L'intera policy è impostata su un
+ singolo <computeroutput>httpd_t</computeroutput>. L'idea
+ principale potrebbe essere di trasformarla in una macro, sulla falsa riga di quello che
+ hai fatto con <computeroutput>apache_script_domain</computeroutput> in
<xref linkend="sn-cgi-subdomains"/>.
- In fact, if you also want to have individual domains on
- CGI scripts, you will end up with types of the form:
- <computeroutput>httpd_<replaceable>vhost</replaceable>_sys_<replaceable>script</replaceable>_t</computeroutput>.
- For example,
- <computeroutput>httpd_examplecom_sys_wiki_t</computeroutput> would be
- a wiki CGI for <computeroutput>example.com</computeroutput>.
+ Infatti, se vuoi anche avere domini individuali sugli
+ scripts CGI, dovrai finire con tipi nella seguente forma:
+ <computeroutput>httpd_<replaceable>vhost</replaceable>_sys_<replaceable>script</replaceable>_t</computeroutput>.
+ Per esempio,
+ <computeroutput>httpd_examplecom_sys_wiki_t</computeroutput> sarÃ
+ un CGI wiki per <computeroutput>example.com</computeroutput>.
</para>
<para>
- Assuming that you have a macro
- <computeroutput>apache_server_domain</computeroutput> which
- defines all of the desired types and rules. If you are
- fortunate enough that you have an IP address per domain, one
- approach is simply to copy the
- <computeroutput>/usr/sbin/httpd</computeroutput> binary
- multiple times, but label each one differently:
+ Assumendo che tu abbia una macro
+ <computeroutput>apache_server_domain</computeroutput> che
+ definisca tutti i tipi e le regole che desideri. Se sei
+ abbastanza fortunato da avere un indirizzo ip per dominio, un
+ approccio è semplicemente di copiare il
+ binario <computeroutput>/usr/sbin/httpd</computeroutput>
+ tutte le volte, ma rietichettando ogniuno differentemente:
</para>
<screen>
<command> ls -aZ /usr/sbin/httpd.*</command>
@@ -1199,54 +1200,54 @@
-rwxr-xr-x root root system_u:object_r:httpd_barorg_exec_t /usr/sbin/httpd.barorg
</screen>
<para>
- Next, have your init scripts give each one a separate
- configuration, for example <command>/usr/sbin/httpd.foocom -f
+ Successivamente, daremo a ciascuno dei nostri init scripts una configurazione
+ separata, per esempio <command>/usr/sbin/httpd.foocom -f
foocom.com</command>.
</para>
<para>
- If you have to serve multiple virtual sites from one IP
- address, one approach might be to modify the &APACHE; source
- code so that once it has read the desired domain from a
- requesting client, it passes off the request to a child which
- is running in the domain for that site.
+ Se devi servire molteplici siti virtuali da un singolo indirizzo
+ IP, un approccio potrebbe essere quello di modificare il codice
+ sorgente di &APACHE; affinchè una volta letto il dominio desiderato da un
+ client richiedente, passi la richiesta ad un figlio che
+ corra nel dominio per quel sito.
</para>
</section>
<section id="sn-defining-webmaster">
- <title>Defining a Webmaster Role</title>
+ <title>Definizione del ruolo Webmaster</title>
<para>
- This guide has posited that, from a security point of view, a
- misconfigured &APACHE; is no different from a compromised one.
- &SEL; deliberately separates the security policy from the
- configuration of every daemon on the system. One neat
- consequence of this is that it allows you to actually create a
- <firstterm>webmaster</firstterm> role that is allowed to
- modify the &APACHE; configuration file
- <filename>/etc/httpd/conf/httpd.conf</filename>, restart the
- daemon, etc. But no matter how the webmaster changes the
- configuration, <command>httpd</command> is still restricted by
- the security policy.
- </para>
- <para>
- In order to do this, you would need to use the strict policy.
- The overall approach is to create a new account with a uid of
- 0, but only allowed to log in with the
- <computeroutput>webmaster_r</computeroutput> role, which is
- only authorized for the
- <computeroutput>webmaster_t</computeroutput> type. You could
- create <computeroutput>webmaster_t</computeroutput> with
- <computeroutput>full_user_role(webmaster)</computeroutput>,
- and then proceeed to add a few permissions, such as:
+ Questa guida ha supposto che, dal punto di vista della sicurezza, un
+ &APACHE; misconfigurato non è differente da uno compromesso.
+ &SEL; separa deliberatamente la policy di sicurezza dalla
+ configurazione di ogni demone sul sistema. Una netta
+ conseguenza di ciò, è che attualmente ti permette di creare un
+ ruolo <firstterm>webmaster</firstterm> a cui è permesso di
+ modificare il file di configurazione di &APACHE;
+ <filename>/etc/httpd/conf/httpd.conf</filename>, riavviare il
+ demone, etc. Ma non ha importanza come il webmaster cambi la
+ configurazione, <command>httpd</command> è ancora ristretto dalla
+ policy di sicurezza.
+ </para>
+ <para>
+ Per far questo, avrai bisogno di usare la policy strict.
+ L'approccio generale è quello di creare un nuovo account con uid pari a
+ 0, ma a cui sia consentito il login esclusivamente
+ con il ruolo <computeroutput>webmaster_r</computeroutput>, che è
+ solo autorizzato per il
+ tipo <computeroutput>webmaster_t</computeroutput>. Potresti
+ creare <computeroutput>webmaster_t</computeroutput> con
+ <computeroutput>full_user_role(webmaster)</computeroutput>,
+ e quindi procedere all'aggiunta di un po di permessi, tipo:
</para>
<programlisting>
create_dir_file(webmaster_t, httpd_config_t)
</programlisting>
<para>
- Since you are giving uid 0
- (<computeroutput>root</computeroutput>) access to the
- webmaster, in this setup you are entirely relying on the &SEL;
- policy. There is more to do here (making init scripts work
- will be slightly tricky), but this outlines the general idea.
- The remainder is left as an exercise for you.
+ Poichè stai dando accesso uid 0
+ (<computeroutput>root</computeroutput>) al
+ webmaster, in questo tipo di installazione stai contando interamente sulla policy
+ &SEL;. C'è molto altre da fare qui (rendere gli init scripts funzionanti
+ sarà un po macchinoso), ma questo delinea l'idea generale.
+ Il resto ti è lasciato come un esercizio.
</para>
</section>
</section>
More information about the Fedora-docs-commits
mailing list