From owner-p4-projects@FreeBSD.ORG Wed Jan 28 20:08:17 2009 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 4F6031065675; Wed, 28 Jan 2009 20:08:17 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DA78106566B for ; Wed, 28 Jan 2009 20:08:17 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id EFBDD8FC23 for ; Wed, 28 Jan 2009 20:08:16 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.3/8.14.3) with ESMTP id n0SK8GCn099484 for ; Wed, 28 Jan 2009 20:08:16 GMT (envelope-from rene@FreeBSD.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.14.3/8.14.3/Submit) id n0SK8Gxg099482 for perforce@freebsd.org; Wed, 28 Jan 2009 20:08:16 GMT (envelope-from rene@FreeBSD.org) Date: Wed, 28 Jan 2009 20:08:16 GMT Message-Id: <200901282008.n0SK8Gxg099482@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to rene@FreeBSD.org using -f From: Rene Ladan To: Perforce Change Reviews Cc: Subject: PERFORCE change 156825 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 20:08:18 -0000 http://perforce.freebsd.org/chv.cgi?CH=156825 Change 156825 by rene@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 --> @@ -667,26 +667,82 @@ bpf-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 sysctl op de - kern.securelevel variabele. Als securelevel - op 1 staat, is het niet langer mogelijk te schrijven naar ruwe - apparaten en speciale chflags vlaggen als - schg worden dan afgedwongen. Ook dient de - vlag schg 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 schg vlag niet op alle - systeembestanden en mappen te zetten die maar te vinden zijn. - / en /usr 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. + veiligheidsniveau draaien, ten minste securelevel 1. + + 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 + sysctl op de kernelvariabele + kern.securelevel: + + &prompt.root; sysctl kern.securelevel=1 + + 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 + kern_securelevel_enable op + YES te zetten in het bestand + /etc/rc.conf, en de waarde van de variabele + kern_securelevel op het gewenste + veiligheidsniveau in te stellen. + + Het standaard veiligheidsniveau van een &os;-systeem direct + nadat de opstartscripts zijn uitgevoerd is -1. Dit wordt + onveilige modus genoemd omdat de onveranderlijke + bestandsvlag uitgezet kan worden, er van/naar alle apparaten mag + worden gelezen en geschreven, enzovoorts. + + 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). + + + Het ophogen van het veiligheidsniveau naar 1 of hoger kan + enkele problemen met X11 (toegang tot + /dev/io zal worden geblokkeerd), of met + de installatie van &os; wanneer die vanaf de broncode is + gebouwd (het gedeelte installword 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. + + + Als het veiligheidsniveau van de kernel naar 1 of hoger + wordt verhoogd, kan het nuttig zijn om de vlag + schg 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 schg voor elk + systeembestand en -map onder de zon over te slaan. Een andere + mogelijkheid is om / en + /usr 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.