PERFORCE change 156825 for review
Rene Ladan
rene at FreeBSD.org
Wed Jan 28 12:08:18 PST 2009
http://perforce.freebsd.org/chv.cgi?CH=156825
Change 156825 by rene at rene_self on 2009/01/28 20:07:38
MFen handbook/security 1.332 -> 1.334
Affected files ...
.. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/security/chapter.sgml#10 edit
Differences ...
==== //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/security/chapter.sgml#10 (text+ko) ====
@@ -5,7 +5,7 @@
$FreeBSDnl: doc/nl_NL.ISO8859-1/books/handbook/security/chapter.sgml,v 1.80 2006/01/05 21:13:24 siebrand Exp $
%SOURCE% en_US.ISO8859-1/books/handbook/security/chapter.sgml
- %SRCID% 1.332
+ %SRCID% 1.334
-->
<chapter id="security">
@@ -667,26 +667,82 @@
<devicename>bpf</devicename>-apparaat of een ander
snuffelapparaat te installeren in een draaiende kernel. Om
deze problemen te voorkomen, moet de kernel op een hoger
- veiligheidsniveau draaien, ten minste securelevel 1. Het
- securelevel wordt ingesteld met <command>sysctl</command> op de
- <varname>kern.securelevel</varname> variabele. Als securelevel
- op 1 staat, is het niet langer mogelijk te schrijven naar ruwe
- apparaten en speciale <command>chflags</command> vlaggen als
- <literal>schg</literal> worden dan afgedwongen. Ook dient de
- vlag <literal>schg</literal> gezet te worden op kritische
- opstartbestanden, mappen en scriptbestanden. Alles dat wordt
- uitgevoerd voordat het securelevel wordt ingesteld. Dit is
- misschien wat overdreven en het wordt lastiger een systeem te
- vernieuwen als dat in een hoger securelevel draait. Er is een
- compromis mogelijk door het systeem in een hoger securelevel te
- draaien maar de <literal>schg</literal> vlag niet op alle
- systeembestanden en mappen te zetten die maar te vinden zijn.
- <filename>/</filename> en <filename>/usr</filename> zouden ook
- als alleen-lezen aangekoppeld kunnen worden. Het is nog
- belangrijk om op te merken dat als de beheerder te draconisch
- omgaat met dat wat hij wil beschermen, hij daardoor kan
- veroorzaken dat die o-zo belangrijke detectie van een inbraak
- wordt misgelopen.</para>
+ veiligheidsniveau draaien, ten minste securelevel 1.</para>
+
+ <para>Het veiligheidsniveau van de kernel kan op een aantal
+ manieren worden ingesteld. De eenvoudigste manier om het
+ veiligheidsniveau van een draaiende kernel te verhogen is met
+ <command>sysctl</command> op de kernelvariabele
+ <varname>kern.securelevel</varname>:</para>
+
+ <screen>&prompt.root; <userinput>sysctl kern.securelevel=<replaceable>1</replaceable></userinput></screen>
+
+ <para>Standaard start de kernel van &os; op met een
+ veiligheidsniveau van -1. Het veiligheidsniveau blijft -1
+ tenzij het is veranderd, òfwel door de beheerder
+ òfwel door &man.init.8; vanwege een instelling in de
+ opstartscripts. Het veiligheidsniveau kan tijdens het opstarten
+ van het systeem verhoogd worden door de variabele
+ <varname>kern_securelevel_enable</varname> op
+ <literal>YES</literal> te zetten in het bestand
+ <filename>/etc/rc.conf</filename>, en de waarde van de variabele
+ <varname>kern_securelevel</varname> op het gewenste
+ veiligheidsniveau in te stellen.</para>
+
+ <para>Het standaard veiligheidsniveau van een &os;-systeem direct
+ nadat de opstartscripts zijn uitgevoerd is -1. Dit wordt
+ <quote>onveilige modus</quote> genoemd omdat de onveranderlijke
+ bestandsvlag uitgezet kan worden, er van/naar alle apparaten mag
+ worden gelezen en geschreven, enzovoorts.</para>
+
+ <para>Als eenmaal het veiligheidsniveau op 1 of een hogere waarde
+ is ingesteld, worden de alleen-toevoegen en onveranderlijke
+ bestanden gehonoreerd, deze kunnen niet worden uitgezet, en
+ wordt toegang tot rauwe apparaten ontzegd. Hogere niveaus
+ beperken nog meer bewerkingen. Lees, voor een volledige
+ beschrijving van het effect van de verschillende
+ veiligheidsniveaus, de handleidingpagina &man.security.7; (of de
+ handleidingpagina van &man.init.8; voor uitgaven ouder dan &os;
+ 7.0).</para>
+
+ <note>
+ <para>Het ophogen van het veiligheidsniveau naar 1 of hoger kan
+ enkele problemen met X11 (toegang tot
+ <filename>/dev/io</filename> zal worden geblokkeerd), of met
+ de installatie van &os; wanneer die vanaf de broncode is
+ gebouwd (het gedeelte <maketarget>installword</maketarget> van
+ het proces moet tijdelijk de alleen-toevoegen en
+ onveranderlijke vlaggen van sommige bestanden uitzetten), en
+ met enkele andere gevallen veroorzaken. Soms, zoals het geval
+ is met X11, is het mogelijk om dit te omzeilen door
+ &man.xdm.1; behoorlijk vroeg in het opstartproces te starten,
+ wanneer het veiligheidsniveau nog laag genoeg is.
+ Omzeilmethoden zoals deze zijn misschien niet voor alle
+ veiligheidsniveaus of voor alle beperkingen die ze opleggen
+ mogelijk. Wat vooruit plannen is een goed idee. Het is
+ belangrijk om de beperkingen die door elk veiligheidsniveau
+ worden opgelegd te begrijpen omdat ze het gebruiksgemak van
+ het systeem sterk verminderen. Het vergemakkelijkt ook het
+ kiezen van eens standaardinstelling en voorkomt allerlei
+ verassingen.</para>
+ </note>
+
+ <para>Als het veiligheidsniveau van de kernel naar 1 of hoger
+ wordt verhoogd, kan het nuttig zijn om de vlag
+ <literal>schg</literal> aan te zetten voor kritieke
+ opstartprogramma's, mappen, en scriptbestanden (i.e. alles dat
+ gedraaid wordt tot het punt waar het veiligheidsniveau wordt
+ ingesteld). Dit kan overdreven zijn, en het bijwerken van het
+ systeem is veel moeilijker wanneer het op een hoog
+ veiligheidsniveau werkt. Een minder beperkend compromis is om
+ het systeem op een hoger veiligheidsniveau te draaien maar het
+ aanzetten van de vlag <literal>schg</literal> voor elk
+ systeembestand en -map onder de zon over te slaan. Een andere
+ mogelijkheid is om <filename>/</filename> en
+ <filename>/usr</filename> simpelweg als alleen-lezen aan te
+ koppelen. Het dient opgemerkt te worden dat het te draconisch
+ zijn over wat is toegestaan het belangrijke detecteren van een
+ inbraak kan verhinderen.</para>
</sect2>
<sect2 id="security-integrity">
More information about the p4-projects
mailing list