© 1995-2008 by The FreeBSD Project. All rights reserved.URL: http://www.FreeBSD.de
as 2007-08-06 12:47:10 UTC
FreeBSD ports repository
Modified files:
books/developers-handbook/secure chapter.sgml
Log:
Kapitel 3 formatiert.
Revision Changes Path
1.6 +604 -607 de-docproj/books/developers-handbook/secure/chapter.sgml
Index: chapter.sgml
===================================================================
RCS file: /home/cvs/de-docproj/books/developers-handbook/secure/chapter.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -I$FreeBSDde.*$ -r1.5 -r1.6
--- chapter.sgml 6 Aug 2007 00:31:10 -0000 1.5
+++ chapter.sgml 6 Aug 2007 12:47:10 -0000 1.6
@@ -6,649 +6,646 @@
basiert auf: 1.27
-->
- <chapter id="secure">
- <chapterinfo>
- <authorgroup>
- <author>
- <firstname>Murray</firstname>
- <surname>Stokely</surname>
- <contrib>Contributed by </contrib>
- </author>
- </authorgroup>
- </chapterinfo>
-
- <title>Sicheres Programmieren</title>
-
- <sect1 id="secure-synopsis">
- <title>Zusammenfassung</title>
-
- <para>Dieses Kapitel beschreibt einige Sicherheitsprobleme,
- die &unix;-Programmierer seit Jahrzehnten quälen, und
- inzwischen verfügbare Werkzeuge, die Programmierern
- helfen, Sicherheitslücken in ihrem Quelltext zu
- vermeiden.</para>
- </sect1>
-
- <sect1 id="secure-philosophy">
- <title>Methoden des sicheren Entwurfs</title>
-
- <para>Sichere Anwendungen zu schreiben erfordert eine sehr
- skeptische und pessimistische Lebenseinstellung.
- Anwendungen sollten nach dem Prinzip der
- <quote>geringsten Privilegien</quote> ausgeführt
- werden, sodass kein Prozess mit mehr als dem absoluten
- Minimum an Zugriffsrechten arbeitet, die er zum
- Erfüllen seiner Aufgabe benötigt. Wo es
- möglich ist, sollte Quelltext, der bereits
- überprüft wurde, wiederverwendet werden, um
- häufige Fehler, die andere schon korrigiert haben,
- zu vermeiden.</para>
-
- <para>Eine der Stolperfallen der &unix;-Umgebung ist, dass es
- sehr einfach ist Annahmen über die Gesundheit der
- Umgebung zu machen. Anwendungen sollten Nutzereingaben (in
- allen Formen) niemals trauen, genausowenig wie System-Ressourcen,
- Inter-Prozess-Kommunikation oder dem zeitlichen Ablauf von
- Ereignissen. &unix;-Prozesse arbeiten nicht synchron. Daher
- sind logische Operationen selten atomar.</para>
- </sect1>
+<chapter id="secure">
+ <chapterinfo>
+ <authorgroup>
+ <author>
+ <firstname>Murray</firstname>
+ <surname>Stokely</surname>
+ <contrib>Contributed by </contrib>
+ </author>
+ </authorgroup>
+ </chapterinfo>
+
+ <title>Sicheres Programmieren</title>
+
+ <sect1 id="secure-synopsis">
+ <title>Zusammenfassung</title>
+
+ <para>Dieses Kapitel beschreibt einige Sicherheitsprobleme, die
+ &unix;-Programmierer seit Jahrzehnten quälen, und
+ inzwischen verfügbare Werkzeuge, die Programmierern helfen,
+ Sicherheitslücken in ihrem Quelltext zu vermeiden.</para>
+ </sect1>
+
+ <sect1 id="secure-philosophy">
+ <title>Methoden des sicheren Entwurfs</title>
+
+ <para>Sichere Anwendungen zu schreiben erfordert eine sehr
+ skeptische und pessimistische Lebenseinstellung. Anwendungen
+ sollten nach dem Prinzip der <quote>geringsten
+ Privilegien</quote> ausgeführt werden, sodass kein Prozess
+ mit mehr als dem absoluten Minimum an Zugriffsrechten arbeitet,
+ die er zum Erfüllen seiner Aufgabe benötigt. Wo es
+ möglich ist, sollte Quelltext, der bereits
+ überprüft wurde, wiederverwendet werden, um
+ häufige Fehler, die andere schon korrigiert haben, zu
+ vermeiden.</para>
+
+ <para>Eine der Stolperfallen der &unix;-Umgebung ist, dass es
+ sehr einfach ist Annahmen über die Gesundheit der Umgebung
+ zu machen. Anwendungen sollten Nutzereingaben (in allen Formen)
+ niemals trauen, genausowenig wie System-Ressourcen,
+ Inter-Prozess-Kommunikation oder dem zeitlichen Ablauf von
+ Ereignissen. &unix;-Prozesse arbeiten nicht synchron. Daher sind
+ logische Operationen selten atomar.</para>
+ </sect1>
+
+ <sect1 id="secure-bufferov">
+ <title>Puffer-Überläufe</title>
+
+ <para>Puffer-Überläufe gibt es schon seit den
+ Anfängen der Von-Neuman-Architektur <xref linkend="COD">.
+
+ <indexterm><primary>Puffer-Überlauf</primary></indexterm>
+ <indexterm><primary>Von-Neuman</primary></indexterm>
- <sect1 id="secure-bufferov">
- <title>Puffer-Überläufe</title>
+ Sie fanden zum ersten Mal verbreitete Beachtung durch den
+ Internetwurm Morris im Jahr 1988. Unglücklicherweise
- <para>Puffer-Überläufe gibt es schon seit den
- Anfängen der Von-Neuman-Architektur <xref linkend="COD">.
+ <indexterm><primary>Morris Internetwurm</primary></indexterm>
- <indexterm><primary>Puffer-Überlauf</primary></indexterm>
- <indexterm><primary>Von-Neuman</primary></indexterm>
-
- Sie fanden zum ersten Mal verbreitete Beachtung durch den
- Internetwurm Morris im Jahr 1988. Unglücklicherweise
-
- <indexterm><primary>Morris Internetwurm</primary></indexterm>
-
- funktioniert der gleiche grundlegende Angriff noch heute. Von
- den 17 CERT Sicherheitshinweisen im Jahr 1999 wurden zehn
-
- <indexterm>
- <primary>CERT</primary>
- <secondary>Sicheitshinweise</secondary>
- </indexterm>
-
- direkt durch Puffer-Überläufe in Software
- verursacht. Die bei weitem häufigste Form eines
- Puffer-Überlauf-Angriffs basiert darauf den Stack
- zu korrumpieren.</para>
+ funktioniert der gleiche grundlegende Angriff noch heute. Von
+ den 17 CERT Sicherheitshinweisen im Jahr 1999 wurden zehn
- <indexterm><primary>Stack</primary></indexterm>
- <indexterm><primary>Arguments</primary></indexterm>
+ <indexterm>
+ <primary>CERT</primary>
+ <secondary>Sicheitshinweise</secondary>
+ </indexterm>
- <para>Die meisten modernen Computer-Systeme verwenden einen
- Stack, um Argumente an Prozeduren zu übergeben und
- lokale Variable zu speichern. Ein Stack ist ein
- last-in-first-out-Puffer (LIFO) im hohen Speicherbereich
- eines Prozessabbilds. Wenn ein Programm eine Funktion
+ direkt durch Puffer-Überläufe in Software
+ verursacht. Die bei weitem häufigste Form eines
+ Puffer-Überlauf-Angriffs basiert darauf den Stack
+ zu korrumpieren.</para>
+
+ <indexterm><primary>Stack</primary></indexterm>
+ <indexterm><primary>Arguments</primary></indexterm>
+
+ <para>Die meisten modernen Computer-Systeme verwenden einen
+ Stack, um Argumente an Prozeduren zu übergeben und
+ lokale Variable zu speichern. Ein Stack ist ein
+ last-in-first-out-Puffer (LIFO) im hohen Speicherbereich
+ eines Prozessabbilds. Wenn ein Programm eine Funktion
- <indexterm><primary>LIFO</primary></indexterm>
- <indexterm>
- <primary>Prozessabbild</primary>
- <secondary>Stack-Pointer</secondary>
- </indexterm>
+ <indexterm><primary>LIFO</primary></indexterm>
+ <indexterm>
+ <primary>Prozessabbild</primary>
+ <secondary>Stack-Pointer</secondary>
+ </indexterm>
- aufruft wird ein neuer "Stack-Frame" erzeugt. Dieser
- besteht aus den Argumenten, die der Funktion übergeben
- wurden, und einer dynamischen Speichermenge für lokale
- Variablen. Der "Stack-Pointer" ist ein Register, das die
-
- <indexterm><primary>Stack-Frame</primary></indexterm>
- <indexterm><primary>Stack-Pointer</primary></indexterm>
-
- aktuelle Position der Spitze des Stacks enthält.
- Da sich dieser Wert andauernd ändert, wenn neue Werte
- auf dem Stack abgelegt werden, bieten viele Implementierungen
- einen "Frame-Pointer", der nahe am Anfang des Stack-Frames
- liegt und es so leichter macht lokale Variablen relativ dazu
- zu adressieren. <xref linkend="COD">
- Die Rücksprungadresse
+ aufruft wird ein neuer "Stack-Frame" erzeugt. Dieser besteht aus
+ den Argumenten, die der Funktion übergeben wurden, und
+ einer dynamischen Speichermenge für lokale Variablen. Der
+ "Stack-Pointer" ist ein Register, das die
----------------------------------------------
Diff block truncated. (Max lines = 200)
----------------------------------------------
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-cvs-doc" in the body of the message
Received on Mon 06 Aug 2007 - 14:48:40 CEST