-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 5 Oct 2003, RoLinux wrote:
> Buna Dizzy, > Pana acum nu auzisem de ele dar ar fi interesant de aflat care este > cel mai sigur din punctul de vedere a separarii proceselor si al > securitatii. Nu exista "cel mai" niciodata. Exista limitari care sunt logice, de exemplu cu cat "virtualizezi" mai tare (deci cu cat separi mai tare, cu cat teoretic pare mai sigur) de fapt devine sistemul mai lent. Exemplul software ultim de virtualizare este probabil ceva de genul vmware (masina virtuala fizica emulata software). Pe urmatorul nivel ar urma ceva la nivel de kernel gen UML. Urmatorul nivel ar fi vserver/ctx iar ultimul nivel ar fi un simplu chroot. > Andy probabil doreste sa invete diferite distributii dar > pe mine ma intereseaza ca daca root-ul virtual este compromis sa fie > aproape imposibil sa obtina root in server host sau sa schimbe route > si altele. Asa e mai bine, ai specificat cerintele tale :) Pai cu ce ai cerut tu aci presupun ca te rezolva orice sistem de la vserver in sus (deci vserver, UML si vmware). Eu am rulat si rulez in productie vserver/ctx si chiar iti permite sa faci ceea ce in afara se vinde la greu (VPS, virtual private servers). Procesele dintr-un context virtual pot fi limitate cu sistemul de capabilitati din linux (deci de exemplu sa nu schimbe rute/etc..) in plus are o chestie care face "bound" la aceste limite sa nu poate fi ridicate o data ce sunt scazute. > La un moment dat si redhat a oferit un kernel compilat > cu support uml. Pe de alta parte UnixWare rula linux in > chroot. > > UML este interesant din punctul meu de vedere ca filesistemul este > intr-un fisier si exista fisierelor-filesistem de tip copy-on-write > (COW). > > > The way to share a filesystem between two virtual machines is to > use the copy-on-write (COW) layering capability of the ubd block > driver. As of 2.4.6-2um, the driver supports layering a read-write > private device over a read-only shared device. A machine's writes > are stored in the private device, while reads come from either device > - the private one if the requested block is valid in it, the shared > one if not. Using this scheme, the majority of data which is unchanged > is shared between an arbitrary number of virtual machines, each of > which has a much smaller file containing the changes that it has made. > With a large number of UMLs booting from a large root filesystem, > this leads to a huge disk space saving. It will also help performance, > since the host will be able to cache the shared data using a much > smaller amount of memory, so UML disk requests will be served from > the host's memory rather than its disks. Aici vserver/ctx vine cu sugestia de link-uri hard. Ai mai multe masini logice (chroot-uri) in care fisierele sunt de fapt link-uri hard la un "skel". Astfel poti face upgrade instant la toate (prin suprascriere) plus economisire spatiu harddisk. > Probabil solutia cea mai buna este cea mai simpla ca implementare > si care in acelasi satisface toate cerintele. Pe vserver/ctx ai o structura de genul: - - skel - - s0 - - s1 Unde skel e skeletul unde se afla multimea tuturor inode-urilor din fisierele din servere (s0, s1, etc..) iar in s0, s1 ... ai link-uri hard la fisierele din skel. Aceste fisiere (cele care se doresc protejate cum sunt programele de sistem) le pui immuatable pe ele, asta combinata cu limitarea ca un proces dintr-un context virtual nu poate sa scoata acest atribut de pe un fisier obtii protectie "perfecta" (daca nu sunt scapari in codul din kernel care face asta). PS: bineinteles solutia cu plain-old chroot (fara patch-uri suplimentare prin kernel) nu e deajuns (pe orice linux am testat pana acum am putut sa ies din chroot daca aveam root) - ---------------------------- Mihai RUSU Email: [EMAIL PROTECTED] GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/gJBePZzOzrZY/1QRAmpgAJ0bjyeC1CAnIgterGNTMckts03sfgCg3lgN WGf7r+IbEgRgSE2DiwiUx6Y= =c614 -----END PGP SIGNATURE----- --- Detalii despre listele noastre de mail: http://www.lug.ro/
