Chroot, virtuelle Maschinen und Jails

Rund um die Sicherheit des Systems und die Applikationen
User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Chroot, virtuelle Maschinen und Jails

Post by daemotron » 2009-02-07 15:58

Hallo kami,

um Deine Frage beantworten zu können, wäre es hilfreich zu wissen, was Du Dir davon versprichst, die verschiedenen Dienste in chroot-Umgebungen zu stecken, und was für ein Setup Dir genau vorschwebt (bzw. was Du bereits benutzt). IMHO kann es dafür zwei Hauptgründe geben:

Zum einen schlicht und ergreifend Organisation: Da Linux eine simple OS-Level Virtualisierung fehlt, kann man Chroot-Umgebungen verwenden, um komplett konfigurierte lauffähige Umgebungen (auch verschiedener Distributionen) bequem nebeneinander auf einer Maschine zu betreiben oder sie von einer Maschine auf die nächste verschieben zu können - oder bestimmte Dienste mehrfach auf einem System laufen zu lassen, die sich sonst ggf. in die Quere kommen würden. Das ganze lässt sich noch beliebig ausschmücken, LVM wäre hier ein weiteres Stichwort.

Der andere Grund, der häufig angeführt wird, sind Sicherheitserwägungen. Dazu muss man aber wissen, dass der chroot-Syscall ursprünglich nicht zu diesem Zweck implementiert wurde. Der chroot-Syscall setzt für einen Prozess ein bestimmtes Verzeichnis als neues root level directory. Somit sind die übrigen Bestandteile des Verzeichnisbaums für diesen Prozess nicht mehr sichtbar, was zunächst schon einen gewissen Schutz darstellt. Allerdings bleibt es dem Prozess weiterhin gestattet, beliebige Syscalls an den Kernel abzusetzen. Mit einer einfachen Kombination aus chdir() und chroot() ist der Prozess auch schon wieder schwuppdiwupp aus der chroot-Umgebung "ausgebrochen".

Um an einem Beispiel zu verdeutlichen, was ich damit meine: Angenommen, Du betreibst in einer chroot-Umgebung Apache mit mod_php. Nehmen wir weiter an, ein fieser Angreifer sei in der Lage, eine laufende PHP-Anwendung zu kompromittieren und PHP dazu zu bringen, eine Remote Shell auszuführen. Dies wäre dann ein Kindprozess des Apache Webservers, der alle Eigenschaften (unter anderem den root directory context) von seinem Elternprozess geerbt hat. Stellt der Angreifer nun fest, dass er innerhalb einer chroot-Umgebung eingesperrt ist (z. B. fehlende Verzeichnisse und/oder Dateien, die in einer "echten" Installation vorhanden wären), könnte er mit chdir() und chroot() dafür sorgen, dass sich der root directory context seiner Shell wieder auf das "echte" / ändert - er wäre also ausgebrochen.

Es gibt aber Möglichkeiten, einen solchen Ausbruchsversuch zu erschweren bzw. unmöglich zu machen. Die Rede ist dabei von Kernel-Patches, die es sich zur Aufgabe gemacht haben, die Standard-Implementierung bestimmter SysCalls durch "gehärtete" Fassungen zu ersetzen. Die beiden bekanntesten Projekte sind grsecurity und RSBAC. Ersteres habe ich selbst seit einigen Jahren im Einsatz (was nicht heißen soll, das RSBAC schlechter ist - im Gegegenteil, es geht bei vielen Dingen noch deutlich weiter als grsecurity, allerdings ist es auch wesentlich komplexer zu konfigurieren). Beide verändern den Kernel so, dass vor der Ausführung eines SysCalls immer geprüft wird, welchen root level context ein Prozess hat. Entspricht dieser nicht dem "echten" /, darf der Prozess z. B. kein chdir() oder chroot() aufrufen; auch andere Syscalls werden gesperrt. Darüber hinaus bieten beide Patches noch viele weitere Sicherheitsverbesserungen, deren Aufzählung hier allerdings den Rahmen sprengen würde.

Wenn Du also chroot aus Sicherheitsgründen verwenden möchtest, solltest Du auf jeden Fall den Einsatz eines gehärteten Kernels in Erwägung ziehen. Außerdem gilt dann auch: weniger ist mehr, also wirklich nur die Bibliotheken und Binaries in die chroot-Umgebung kopieren, die der einzusperrende Dienst zum laufen benötigt - die debootstrap-Methode würde deutlich mehr installieren, was eben zu einem gewissen Grad das Risiko erhöht. Bei einer manuell erstellten chroot-Umgebung kannst Du dann auch auf den Einsatz von mod_chroot verzichten - der Apache "weiß" dann gar nicht erst, dass er eingesperrt wurde.

Wenn Du nun (aus welchen Erwägungen heraus auch immer) Apache und MySQL in chroot-Umgebungen stecken willst, müssen Dir noch folgende Dinge klar sein:

  • Wenn Du mod_php einsetzt, läuft PHP automatisch im selben Kontext wie Apache, da mit mod_php jeder Apache-Prozess selbst die Fähigkeit erhält, PHP-Skripte zu interpretieren, womit keine externen Prozesse mehr erzeugt werden müssen
  • Wenn Apache (bzw. PHP) und MySQL in jeweils unterschiedlichen chroot-Umgebungen stecken, ist die Kommunikation zwischen beiden nicht mehr über Unix Sockets möglich ("localhost"), sondern nur noch über TCP ("127.0.0.1"). Eine Möglichkeit wäre das sezten eines Hardlinks innerhalb des Apache-chroot auf den MySQL-Socket, aber das geht nur, wenn beide auf derselben Partition liegen.
  • Besonders interessant wäre es, Apache und PHP mit unterschiedlichem Kontext laufen zu lassen (z. B. Apache in /var/www, PHP-Prozesse des einen virtuellen Hosts in /var/www/user1 und die des nächsten in /var/www/user2 etc.). Das funktioniert aber nur mit FastCGI, da (zumindest bei einem gehärteten Kernel) vom Apache erzeugte Prozesse nicht noch einmal den Kontext wechseln dürfen, womit CGI und suPHP ausscheiden (bei mod_php ist es ohnehin nicht möglich).
  • Gegen bestimmte Angriffsformen bietet chroot() keine zusätzliche Sicherheit, ob gehärtet oder nicht. Hat es ein Angreifer nur darauf abgesehen, Deine Website zu verwüsten (Defacing), muss er dazu aus der chroot-Umgebung gar nicht ausbrechen. Während eine defaced Website noch durch zurückspielen eines Backups leicht behoben ist, sieht es bei einer anderen Angriffsform schon deutlich schwieriger aus: Die Rede ist von Spammern, die Deinen Server zum Versand ihres Dosenfleischs nutzen wollen. Auch für sie besteht keine Notwendigkeit, aus einer chroot-Umgebung auszubrechen, solange sie einen Prozess kontrollieren, der per TCP mit dem MTA kommunizieren darf (TCP-Verbindungen aus chroot-Umgebungen lassen sich nur mit RSBAC einschränken => Stichwort Jail) - 127.0.0.1 wird von den meisten Mailservern als vertrauenswürdige Quelle erachtet, für die keine Authentifizierung verlangt wird.

encbladexp
Posts: 84
Joined: 2006-01-04 12:09
Location: Lichtenfels

Re: Wie installiere ich Apache in chroot?

Post by encbladexp » 2009-02-17 23:49

Ich halte auch nicht von chroot für Security zwecke. Sinnvoller wäre da (wenn es ein "richtiger" Server ist) sowas wie Xen, den das ausbrechen aus einer VM ist wesentlich komplexer wie das brechen eines Chroot's.

mfg Betz Stefan

User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Re: Wie installiere ich Apache in chroot?

Post by daemotron » 2009-02-18 10:22

matzewe01 wrote:Inzwischen lässt es sich aus jeder VM erfolgreich ausbrechen.

Das mag wohl stimmen, aber teilweise ist der Aufwand, den man dafür treiben muss, enorm (im Gegensatz zu einem ungeschützten chroot). Beispiel sysjails unter OpenBSD: Der Ausbruch gelingt, aber nur, wenn ein SMP-System zugrunde liegt und es einem gelingt, eine Race Condition zu gewinnen (siehe http://www.watson.org/~robert/2007woot/). Seit der Behebung eines Bugs in 2007 ist es auch keinem mehr gelungen, aus einem FreeBSD-Jail auszubrechen (zumindest keinen dokumentierten erfolgreichen Versuch). Ähnlich sieht es bei grsecurity- oder RSBAC-gehärteten (chroot-)Jails aus.

Wie es bei Full- oder Paravirtualisierung aussieht, kann ich hingegen weniger beurteilen, da ich auf meinen Produktivsystemen ausschließlich mit OS-Level-Virtualisierung arbeite. Ich könnte mir aber vorstellen, dass die Entwicklung eines Exploits sehr tiefgreifendes Fachwissen erfordert (siehe blaue und rote Pillen), die Anwendung eines Exploits aber sehr viel zuverlässiger funktioniert als in einem OS-Level Jail - dort ist man IMHO viel stärker den "Launen" des Admin ausgeliefert, da Restriktionen aus dem Basis-System (Resource Limits, MAC, Mount-Restriktionen) automatisch auch innerhalb des Jails gelten.

User avatar
Joe User
Project Manager
Project Manager
Posts: 11139
Joined: 2003-02-27 01:00
Location: Hamburg

Re: Wie installiere ich Apache in chroot?

Post by Joe User » 2009-02-18 11:47

Grundsätzlich gilt: Weder Chroots, VMs, noch Jails sind sicher. Ein guter(!) Assambler-Programmierer kommt mit Speicheradresstricks, oder die RTC (spätestens jedoch über (un)dokumentierte Hardwarebugs) aus allen Lösungen raus...
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Re: Wie installiere ich Apache in chroot?

Post by daemotron » 2009-02-18 13:50

Man muss halt immer im Auge behalten, welchen Sicherheitsgewinn (v. a. welche Art von Sicherheitsgewinn) OS-Level-Virtualisierung tatsächlich bringt (bei kompletten VMs halte ich die Diskussion für obsolet, da ich in jedem Fall ein kompromittiertes System habe - mit Glück nur das innerhalb der VM). Der größte Vorteil ist IMHO Zeit. Den Ausbruch aus einem Jail (ich benutze den Begriff jetzt mal synonym für "echte" Jails (FreeBSD), sysjails (OpenBSD), Solaris Zones, RSBAC Jails und grsecurity gehärtetes chroot) kostet einen Angreifer immer Zeit. Kommen außer dem reinen Jailing noch weitere Hürden hinzu (MAC, Secure Level, Resource Limits, ...), wird es noch schwieriger und aufwändiger.

Mag sein, dass einem wirklich fähiger Angreifer am Ende mit einem genau auf die Situation zugeschnittenen Toolset (dafür braucht man nicht zwingend Assembler, C tut's in den meisten Fällen auch :wink: ) der Ausbruch gelingt - allerdings muss er dazu das Jail gründlich von innen analysieren, möglicherweise mehrfach einbrechen oder sich sogar eine Hintertür offen lassen. Das sind alles Dinge, die man mit den richtigen Werkzeugen auch rechtzeitig bemerken kann, und zwar von außerhalb des Jails. Mit Werkzeugen (am Ende also Prozessen), die der Angreifer nicht wahrnehmen und beeinflussen kann, solange er noch nicht aus dem Jail ausgebrochen ist. Security Event Auditing (auditd unter FreeBSD, BSM unter Solaris) gekoppelt mit einer entsprechenden Warnmeldekette wäre hier wohl das Mittel der Wahl.

Das Fazit ist wie immer dasselbe: Nur durch den Einsatz bestimmter Werkzeuge ergibt sich nicht automatisch eine Erhöhung der Systemsicherheit. Zusammen mit den richtigen Prozessen und einer permanenten Überprüfung derselben (und der Werkzeugwahl) kann man ernstgemeinte Angriffe aber zumindest so frühzeitig erkennen, dass man größeren Schaden verhindern kann - notfalls durch "Stecker raus". Voraussetzung ist aber, dass man selbst über potenzielle Angriffspfade Bescheid weiß und auch in der Lage ist einzuschätzen, wie groß der Vorsprung ist, den man sich bzw. seinen Systemen verschaffen kann.

Dazu muss man sich dann aber mit dem Quellcode und nicht nur mit der Konfiguration seines Systems (OS, Applikationen) vertraut machen. Kennt man die Implementierung zumindest der zentralen Mechanismen, fällt die Sicherheitseinschätzung in der Regel deutlich realistischer aus. Ein bisschen Lesestoff findet sich z. B. hier:

http://www.ibm.com/developerworks/linux ... ppriv.html
http://www.freebsd.org/doc/en_US.ISO885 ... index.html
http://www.freebsd.org/doc/en_US.ISO885 ... index.html
und natürlich die Man pages der Sektionen 2, 3 und 9

P. S. die letzten paar Posts entfernen sich sehr stark vom Topic und sind im Webserver-Unterforum eigentlich nicht korret untergebracht. Wenn Interesse an weiterer Diskussion zu dem Thema besteht, würde ich einen der Mods bitten, die Posts, die mit dem eigentlichen Thema des OT nichts oder nicht mehr viel zu tun haben, in einen eigenen Thread im Security-Unterforum zu verschieben...

User avatar
Joe User
Project Manager
Project Manager
Posts: 11139
Joined: 2003-02-27 01:00
Location: Hamburg

Re: Chroot, virtuelle Maschinen und Jails

Post by Joe User » 2009-02-18 15:12

PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Re: Chroot, virtuelle Maschinen und Jails

Post by daemotron » 2009-02-19 20:34

@Joe User: hast Du irgendwelche Quellen zu Ausbrüchen aus OS-Level-virtualisierten Umgebungen? Ich finde immer nur Hinweise, die sich auf konkrete (und mittlerweile behobene) Bugs beziehen...

User avatar
Joe User
Project Manager
Project Manager
Posts: 11139
Joined: 2003-02-27 01:00
Location: Hamburg

Re: Chroot, virtuelle Maschinen und Jails

Post by Joe User » 2009-02-20 09:45

Konkrete Quellen darf ich nicht nennen, nur soviel, dass es per Assambler-Tricks (Speicheradressen und/oder Hardwarebugs) kein Problem ist. Man muss halt nur die Datenblätter und Errata der Hardware (insbesondere CPU, Chipsatz, Speichercontroller und RTC) studieren und kreativ programmieren können. Mit Hochsprachen wie C funktioniert es übrigens nicht, da man mit Hochsprachen die Hardware nicht direkt manipulieren kann ;)
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

oxygen
Posts: 2138
Joined: 2002-12-15 00:10
Location: Bergheim

Re: Chroot, virtuelle Maschinen und Jails

Post by oxygen » 2009-02-20 11:39

Joe User wrote:Konkrete Quellen darf ich nicht nennen, nur soviel, dass es per Assambler-Tricks (Speicheradressen und/oder Hardwarebugs) kein Problem ist. Man muss halt nur die Datenblätter und Errata der Hardware (insbesondere CPU, Chipsatz, Speichercontroller und RTC) studieren und kreativ programmieren können. Mit Hochsprachen wie C funktioniert es übrigens nicht, da man mit Hochsprachen die Hardware nicht direkt manipulieren kann ;)

Sorry, aber so einen Unsinn habe ich selten gehört. :oops:

User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Re: Chroot, virtuelle Maschinen und Jails

Post by daemotron » 2009-02-20 11:43

Joe User wrote:Konkrete Quellen darf ich nicht nennen

Schade. Ich werde allerdings in die Richtung mal ein bisschen experimentieren (insb. Ausbruch aus Jails). Mein Interesse gilt dabei gar nicht so sehr konkreten Exploits, sondern eher Design-bedingten Schwächen von Virtualisierungstechniken.

Joe User wrote:nur soviel, dass es per Assambler-Tricks (Speicheradressen und/oder Hardwarebugs) kein Problem ist. Man muss halt nur die Datenblätter und Errata der Hardware (insbesondere CPU, Chipsatz, Speichercontroller und RTC) studieren und kreativ programmieren können. Mit Hochsprachen wie C funktioniert es übrigens nicht, da man mit Hochsprachen die Hardware nicht direkt manipulieren kann ;)

s/C/Java/ *scnr* Mit C kann man sehr Hardware-nah programmieren (siehe Linux-, *BSD-, Solaris-Kernel); für Speicheradressierung und -allokierung ist man als Programmierer selbst zuständig (und kann damit ein System auch ganz nett zum Zusammenbruch bringen). Im übrigen übersetzt ein C-Kompiler C-Sourcen auch nur in Assembler, bevor er diesen dann zu Object-Code weiterverarbeitet. Wer sich das mal anschauen möchte, sollte gcc mal mit der Option -S verwenden :wink:

User avatar
Joe User
Project Manager
Project Manager
Posts: 11139
Joined: 2003-02-27 01:00
Location: Hamburg

Re: Chroot, virtuelle Maschinen und Jails

Post by Joe User » 2009-02-20 14:06

jfreund wrote:Mit C kann man sehr Hardware-nah programmieren (siehe Linux-, *BSD-, Solaris-Kernel);

In den Kerneln, insbesondere bei der Hardwareunterstützung, kommt mehr Assembler zum Tragen als Du glaubst ;)

jfreund wrote:für Speicheradressierung und -allokierung ist man als Programmierer selbst zuständig (und kann damit ein System auch ganz nett zum Zusammenbruch bringen).

Man kann mit Hochsprachen aber nicht reservierte und/oder geschützte Speicherbereiche direkt manipulieren, da dies bereits vom Compiler unterbunden wird. Mit Assembler geht soetwas problemlos, wenn man weiss wie.
Oder ein simpleres Beispiel: Schonmal versucht mittels Hochsprache eine Division durch 0 durchzuführen, ohne vom Compiler angemeckert zu werden?

jfreund wrote:Im übrigen übersetzt ein C-Kompiler C-Sourcen auch nur in Assembler, bevor er diesen dann zu Object-Code weiterverarbeitet. Wer sich das mal anschauen möchte, sollte gcc mal mit der Option -S verwenden :wink:

Bei dem generierten Assembler wird einem Assembler-Programmierer übrigens extrem übel...


Und da Bücher manchmal glaubhafter sind als meine Posts, hier ein weiterer Unterschied zwischen Hochsprachen und Assembler:
http://books.google.com/books?id=3vY35U ... 9#PPA89,M1
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Re: Chroot, virtuelle Maschinen und Jails

Post by daemotron » 2009-02-20 14:45

Joe User wrote:Man kann mit Hochsprachen aber nicht reservierte und/oder geschützte Speicherbereiche direkt manipulieren, da dies bereits vom Compiler unterbunden wird. Mit Assembler geht soetwas problemlos, wenn man weiss wie.

Nein, der Kompiler unterbindet das nicht wirklich. Beispiel:

Code: Select all

#include <stdio.h>

int main() {
  int *ptr;
  int value;
  ptr = &value;
  printf("Pointer-Adresse: %pn", ptr);
  ptr +=100;
  printf("Pointer-Adresse: %pn", ptr);
  *ptr = 4711;
  printf("Wert an Adresse %p: %dn", ptr, *ptr);
  return 0;
}

Dieses kleine Progrämmchen übersetzt gcc ohne Mucken. Ich greife darin aber schreibend auf eine Speicheradresse zu, die ich mir willkürlich zusammenbastele (ich könnte natürlich gezielter direkt eine Adresse hart verdrahten). Der Kernel wird den Prozess allerdings abschießen, wenn ptr auf eine Adresse außerhalb des zugewiesenen Speicherbereichs zeigt und ich mit *ptr=4711 versuche, in diesen Speicherbereich hineinzuschreiben. Das wird er aber auch mit einem in Assembler geschriebenen Prozess tun, wenn er versucht, sich daneben zu benehmen.

Joe User wrote:Oder ein simpleres Beispiel: Schonmal versucht mittels Hochsprache eine Division durch 0 durchzuführen, ohne vom Compiler angemeckert zu werden?

Code: Select all

int main() {
  int x = 0;
  int y;
  y = 100 / x;
  return 0;
}
Auch das übersetzt gcc ohne meckern, da er den Laufzeitwert von x nicht kennt (in diesem simplen Beispiel sieht man's sofort, aber C-Kompiler prüfen generell nur Formalia, nie Variableninhalte).

Joe User wrote:Bei dem generierten Assembler wird einem Assembler-Programmierer übrigens extrem übel...

Ach, einfach mal mit -O0 bis -O3 durchprobieren - es wird von mal zu mal lustiger :D

Kurz zusammengefasst: Wenn der Kernel es zulässt (Design- oder Implementierungsschwäche), kann ich auch mit C Prozesse erzeugen, die böse Dinge mit dem Speicher anstellen. Umgekehrt unterliegen auch in Assembler geschriebene Programme den Restriktionen des Kernels. Wenn ich (böser Angreifer) Code (Assembler oder C) in den Kernel-Space einschleusen kann, habe ich eh gewonnen. Übrigens: auch auf PCI-Adressen kann man mit C herumferkeln. Es gibt - soweit ich das überblicke - allerdings eine Sache, die sich tatsächlich nur mit Assembler steuern lässt: der gezielte Zugriff auf bestimmte CPU-Register. Wenn natürlich gerade der Prozessor einen Bug hat (Core2 lässt grüßen :wink:), muss man sich halt mal ein bisschen mit x86-asm auseinandersetzen.

User avatar
Joe User
Project Manager
Project Manager
Posts: 11139
Joined: 2003-02-27 01:00
Location: Hamburg

Re: Chroot, virtuelle Maschinen und Jails

Post by Joe User » 2009-02-21 13:38

matzewe01 wrote:Zur Laufzeit wirst Du aber nicht auf geschütze Adressbereiche z.B. reservierter Speicher durch HW / Prozessor etc. zugreifen können. Das liegt letzenendes am generierten Maschinencode, der es u.a. auch verhindert.
Mit Assembler klappt das zur Laufzeit.

Es liegt vor Allem an den vom Compiler und/oder Libraries (hier libc) genutzten Syscalls. Mit Assembler kann man nahezu komplett am OS (Kernel) vorbei programmieren. So lassen sich im Gegensatz zu Hochsprachen mit Assembler Prozessor-Features wie NX umgehen und so zum Beispiel wunderbar RootKits absichern. Wobei ich Letztere per Assembler und der RTC gleich direkt per BIOS ausführen würde, wodurch man sie zur OS-Runtime gar nicht mehr entdecken könnte. Das geht theoretisch auch mit C, wenn der generierte Code nur nicht so aufgebläht und langsam wäre...
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

User avatar
Joe User
Project Manager
Project Manager
Posts: 11139
Joined: 2003-02-27 01:00
Location: Hamburg

Re: Chroot, virtuelle Maschinen und Jails

Post by Joe User » 2009-02-21 17:10

matzewe01 wrote:
Joe User wrote:So lassen sich im Gegensatz zu Hochsprachen mit Assembler Prozessor-Features wie NX umgehen und so zum Beispiel wunderbar RootKits absichern. Wobei ich Letztere per Assembler und der RTC gleich direkt per BIOS ausführen würde, wodurch man sie zur OS-Runtime gar nicht mehr entdecken könnte.


Ist das denn überhaupt möglich?
Ich meinte, dass ich durchaus dem Prozessor / im Speucher Programme ablegen kann und diese unabhängig vom Os abgearbeitet werden.

Ja, das Prinzip schimpft sich heute Virtualisierung ;)

matzewe01 wrote:Also zwangsläufig auch kein BIOS nötig wäre. EPROMS (bzw. diese statischen Speicher) gibt es ja eigentlich auch genug.

EEPROMS und andere Hardware kann man immer austauschen/hinzufügen und selbst programmieren, ebenso das BIOS. Ganz ohne BIOS geht es allerdings nur, wenn die Hardware fest definiert ist und nicht verändert wird. Dann muss man die Hardware-Programmierung nur noch direkt im Prozessor/ROM ablegen und fertig.

matzewe01 wrote:Das letzte mal als ich mich ernsthaft mit Assembler beschäftigt habe, war zu Z80 Zeiten an der Hochschule und später noch mit P1.

Das ist schon paar Tage her ;)
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

User avatar
Joe User
Project Manager
Project Manager
Posts: 11139
Joined: 2003-02-27 01:00
Location: Hamburg

Re: Chroot, virtuelle Maschinen und Jails

Post by Joe User » 2009-02-21 20:26

matzewe01 wrote:
Joe User wrote:Ja, das Prinzip schimpft sich heute Virtualisierung ;)


Ich meinte her eine unabhängiges Ansprechen der HW mit und / ohne einfluss auf andere Prozesse auf der HW.

Ich auch ;)

matzewe01 wrote:Spricht man dann eigentlich auch schon von einer Virtualisierung? HW gestützte Virtualisierung?

Ja, Letzteres. Virtualisierung auf OS-Level ist lediglich primitiver und billiger umzusetzen, da man dies in Hochsprachen machen kann und keinen guten und teuren Assembler-Programmierer dauerhaft an sich binden muss...
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.