OS waarbij alle apps volledig geïsoleerd draaien?

[Juup]

Is er een OS waarbij elke applicatie volledig geïsoleerd draait en alleen met het OS kan communiceren middels een set "veilige" APIs?

Een applicatie zou dan geen info meer moeten kunnen krijgen over andere processen, niet kunnen lezen of schrijven buiten de eigen directory, geen geheugen kunnen lezen of schrijven buiten de eigen geheugenruimte etc.

Van chroot onder linux heb ik begrepen dat het helemaal niet zo waterdicht is.
Ook ASLR is maar beperkt nuttig.

Er zal toch wel iemand zijn die zoiets aan het maken is?

[justahuman]

Naja veilig is het nooit helemaal maar een mooi voorbeeld is https://www.qubes-os.org, hier in draaien alle apps in verschillende VM's en hebben beperkt acces.

[Juup]

justahuman schreef op maandag 11 april 2016 @ 16:24:
Naja veilig is het nooit helemaal maar een mooi voorbeeld is https://www.qubes-os.org, hier in draaien alle apps in verschillende VM's en hebben beperkt acces.

Hmmm interessant.
Gebaseerd op Xen met voor elke applicatie een VM.
Klinkt niet echt als een "native" oplossing maar toch een grote verbetering tov plain linux.

[justahuman]

Als je nog wat anders zoekt kan je ook nog kijken naar of containers onder linux, jails onder bsd of zones onder solaris.

[johnkeates]

Wat je beschrijft is in feite al wat een OS is, of, kernel. Een set API's voor veilige toegang tot hardware. Zonder die API's zou software gelijktijdig met hardware kunnen proberen te communiceren, wat niet werkt en crashes zou veroorzaken

[Juup]

justahuman schreef op maandag 11 april 2016 @ 16:37:
Als je nog wat anders zoekt kan je ook nog kijken naar of containers onder linux, jails onder bsd of zones onder solaris.

Ook interessant maar ik kan me moeilijk voorstellen dat dat ooit echt secure gaat worden.
Het is teveel gebaseerd op bestaande functionaliteit (zoals chroot) en vertrouwt bestaande libs te veel.

[johnkeates]

Als je ook de libs niet vertrouwt, vertrouw je de kernel dan wel? Of een eventuele hypervisor? Qubes is eigenlijk het enige OS dat voldoet aan je wensen tot zo ver. De meeste commerciële systemen kan je wel vergeten (zoals Windows)...

[Juup]

Oh je hebt helemaal gelijk.
Het gaat me vooral om een theoretische oplossing die dan fundamenteel een stuk veiliger moet zijn dan de huidige OSsen.
Als ik nu zou switchen dan zou Qubes een redelijk goede oplossing zijn ws.

[Hero of Time]

Als je geen overhead van een hele VM wilt, dan kom je al snel bij oplossingen die gebruik maken van bijvoorbeeld Docker of LXC (Linux Container). In zekere zin ook helemaal gescheiden, een programma in Docker kan niet zomaar bij je documenten tenzij je dat specifiek aangeeft en het kan ook niet bij een andere container.

[jan99999]

Misschien is dit iets,
https://developer.ubuntu.com/en/snappy/

[Hero of Time]

Snappy apps is heel wat anders. Wat Ubuntu heeft is een package dat alles in zich heeft, te vergelijken met OSX programma's in /Application.

[swbr]

Al eens gekeken naar CloudABI?

https://nuxi.nl/

[Juup]

swbr schreef op maandag 11 april 2016 @ 21:46:
Al eens gekeken naar CloudABI?

https://nuxi.nl/

Interessant. Moeilijk te beoordelen hoe veilig dit is (of wordt) maar een mooi project.

[CyBeR]

Juup schreef op maandag 11 april 2016 @ 16:44:
[...]

Ook interessant maar ik kan me moeilijk voorstellen dat dat ooit echt secure gaat worden.
Het is teveel gebaseerd op bestaande functionaliteit (zoals chroot) en vertrouwt bestaande libs te veel.

Dan heb je toch niet echt door wat containers zijn.

[CH4OS]

Juup schreef op dinsdag 12 april 2016 @ 11:31:
Interessant. Moeilijk te beoordelen hoe veilig dit is (of wordt) maar een mooi project.

Het staat je natuurlijk ook vrij om eens iets op te zetten en te testen of het wat is wat je zoekt?

[init6]

Het meest secure is een VM, containers zijn erg secure als je dit met een systeembeheerder mindset neerzet: Niemand is root in de container, niemand kan privileged acties uitvoeren, drop capabilities en gebruik selinux/apparmor. Meer info in blogpost van Daniel Walsh
https://opensource.com/business/15/3/docker-security-tuning

Download je alle docker images random van het internet dan vraag je erom, maar zelf docker containers uitrollen en deze signed aanleveren is redelijk secure. Zorg iig dat je geen passwords in je container hebt staan.

[BCC]

Hero of Time schreef op maandag 11 april 2016 @ 20:04:
Als je geen overhead van een hele VM wilt, dan kom je al snel bij oplossingen die gebruik maken van bijvoorbeeld Docker of LXC (Linux Container). In zekere zin ook helemaal gescheiden, een programma in Docker kan niet zomaar bij je documenten tenzij je dat specifiek aangeeft en het kan ook niet bij een andere container.

Ja maar dan heb je totaal geen isolatie: alle containers sharen 1 kernel, met alle Security issues en mogelijke stabiliteits problemen die erbij horen. Resource restriction is bijvoorbeeld ook niet goed mogelijk. Er zijn op dit moment ook nog een aantal security issues bij docker waardoor het soms wel mogelijk is om bij andere containers te komen. Het is ook niet voor niets niet geschikt voor productie

Zie ook YouTube: Hitler uses Docker semi nsfw

[ Voor 5% gewijzigd door BCC op 12-04-2016 14:08 ]

[Hero of Time]

BCC schreef op dinsdag 12 april 2016 @ 14:06:
[...]

Ja maar dan heb je totaal geen isolatie: alle containers sharen 1 kernel, met alle Security issues en mogelijke stabiliteits problemen die erbij horen. Resource restriction is bijvoorbeeld ook niet goed mogelijk. Er zijn op dit moment ook nog een aantal security issues bij docker waardoor het soms wel mogelijk is om bij andere containers te komen. Het is ook niet voor niets niet geschikt voor productie

En in hoeverre heb je geen last van kernel bugs met VMs e.d.? En het is nogal een verschil als je 20 VMs moet gaan lopen patchen, of 1 systeem en alleen even de docker containers hoeft aan te slingeren (die ook nog eens in de fractie van de tijd van een VM weer draaien). Vanuit een beheeroogpunt, specifiek op dit onderwerp gericht, zijn VMs een nachtmerrie om bij te houden.

[BCC]

Klopt, maar dat was niet de vraag van de ts toch? Daarnaast is hiervan ook veel te automatiseren middels chef of puppet. Maar meer veiligheid is meestal complexer beheer. Security vs usability blijft altijd lastig. Docker is mooi en kan dit misschien over een paar jaar wel, maar echte proces isolatie is nu alleen te garanderen als het op seperate hardware draait.

[ Voor 60% gewijzigd door BCC op 12-04-2016 14:22 ]

[Soldaatje]

BCC schreef op dinsdag 12 april 2016 @ 14:06:
[...]

Ja maar dan heb je totaal geen isolatie: alle containers sharen 1 kernel, met alle Security issues en mogelijke stabiliteits problemen die erbij horen. Resource restriction is bijvoorbeeld ook niet goed mogelijk. Er zijn op dit moment ook nog een aantal security issues bij docker waardoor het soms wel mogelijk is om bij andere containers te komen. Het is ook niet voor niets niet geschikt voor productie

Zie ook YouTube: Hitler uses Docker semi nsfw

Mooi filmpje, lol!

Maar docker is denk ik wel veiliger dan apps die gewoon native naast elkaar draaien, dan kunnen ze doen wat ze willen.

[BCC]

Soldaatje schreef op dinsdag 12 april 2016 @ 14:22:
[...]
Maar docker is denk ik wel veiliger dan apps die gewoon native naast elkaar draaien, dan kunnen ze doen wat ze willen.

Klopt, maar niet heel veel.

[CyBeR]

BCC schreef op dinsdag 12 april 2016 @ 14:06:
[...]

Ja maar dan heb je totaal geen isolatie: alle containers sharen 1 kernel, met alle Security issues en mogelijke stabiliteits problemen die erbij horen. Resource restriction is bijvoorbeeld ook niet goed mogelijk. Er zijn op dit moment ook nog een aantal security issues bij docker waardoor het soms wel mogelijk is om bij andere containers te komen. Het is ook niet voor niets niet geschikt voor productie

Dat kan wel. Docker heeft inderdaad wel meer issues en is eigenlijk meer gericht op developers. En inderdaad je deelt een kernel, maar anders deel je een hypervisor en als jij denkt dat er geen manier is om uit een VM te breken heb ik je een brug te verkopen.

[init6]

BCC schreef op dinsdag 12 april 2016 @ 14:06:
[...]

Ja maar dan heb je totaal geen isolatie: alle containers sharen 1 kernel, met alle Security issues en mogelijke stabiliteits problemen die erbij horen. Resource restriction is bijvoorbeeld ook niet goed mogelijk. Er zijn op dit moment ook nog een aantal security issues bij docker waardoor het soms wel mogelijk is om bij andere containers te komen. Het is ook niet voor niets niet geschikt voor productie

Zie ook YouTube: Hitler uses Docker semi nsfw

Welke security issues?

[Thulium]

Wat potentieel iets minder bloated kan zijn dan een LXC/docker container (je moet immers een heel OS meeleveren :-) )

Je moet hier (net als voor Docker en LXC) een recent kernel voor draaien, maar je kunt dan wel finegrained aangeven wat je applicatie namespace wel en niet kan (en waar deze wel en niet bij mag).

https://firejail.wordpress.com/

De naam is afgeleid van Firefox Jail, maar het is veel breder inzetbaar dan alleen dat.

[init6]

Thulium schreef op dinsdag 12 april 2016 @ 15:08:
Wat potentieel iets minder bloated kan zijn dan een LXC/docker container (je moet immers een heel OS meeleveren :-) )

Je moet hier (net als voor Docker en LXC) een recent kernel voor draaien, maar je kunt dan wel finegrained aangeven wat je applicatie namespace wel en niet kan (en waar deze wel en niet bij mag).

https://firejail.wordpress.com/

De naam is afgeleid van Firefox Jail, maar het is veel breder inzetbaar dan alleen dat.

Welk OS?
https://github.com/a-nldi...er/blob/master/Dockerfile
https://github.com/jfraze...on/blob/master/Dockerfile

niet geheel ontopic, maar sommige statements zijn vanuit een visie geschreven ipv een waarheid.

[ Voor 10% gewijzigd door init6 op 12-04-2016 15:26 ]

[Hero of Time]

Thulium schreef op dinsdag 12 april 2016 @ 15:08:
Wat potentieel iets minder bloated kan zijn dan een LXC/docker container (je moet immers een heel OS meeleveren :-) )

Je moet hoe dan ook een heel OS draaien, anders kan je nogal weinig met je computer. Of dacht je dat de aansturing van de hardware, alloceren van geheugen, etc. gedaan werd door feetje? Dus of je nou met containers werkt ala docker of VMs, je hebt in alle gevallen een OS nodig. Ook met jouw firejail toepassing.

[Thulium]

Dat weet ik, en ook niet wat ik bedoelde.

Wat ik bedoelde was dat een container ook z'n eigen OS moet draaien (en bij Docker hoeft dat volgens de links van init6 dus niet per se waar te zijn).

[CyBeR]

Hero of Time schreef op dinsdag 12 april 2016 @ 15:28:
[...]

Je moet hoe dan ook een heel OS draaien, anders kan je nogal weinig met je computer. Of dacht je dat de aansturing van de hardware, alloceren van geheugen, etc. gedaan werd door feetje? Dus of je nou met containers werkt ala docker of VMs, je hebt in alle gevallen een OS nodig. Ook met jouw firejail toepassing.

Dat doet de kernel. Binnen je container heb je niet meer nodig dan wat je app nodig heeft aan libraries. Veel docker-bouwers leveren inderdaad een compleet OS mee maar da's meer onkunde dan noodzaak.

[Hero of Time]

Thulium schreef op dinsdag 12 april 2016 @ 15:50:
Dat weet ik, en ook niet wat ik bedoelde.

Wat ik bedoelde was dat een container ook z'n eigen OS moet draaien (en bij Docker hoeft dat volgens de links van init6 dus niet per se waar te zijn).

Een container draait niet z'n eigen OS. Er wordt geen kernel in geladen, geen extra libraries, etc. Alleen je programma met z'n dependencies. Als je 'hello world' wilt draaien, heb je alleen maar libc nodig in principe (even simpel gezegd).

CyBeR schreef op dinsdag 12 april 2016 @ 15:53:
[...]


Dat doet de kernel. Binnen je container heb je niet meer nodig dan wat je app nodig heeft aan libraries. Veel docker-bouwers leveren inderdaad een compleet OS mee maar da's meer onkunde dan noodzaak.

Precies, dat zeg ik. Maar initieel heb je altijd een OS nodig om de boel aan te sturen, ongeacht wat je draait. Thulium heeft 't over 'extra bloat' wat een container zou bevatten, maar dat is dus niet zo.

[d1ng]

init6 schreef op dinsdag 12 april 2016 @ 15:06:
[...]
Welke security issues?

Wat leesvoer over Docker specifiek
https://blog.opendns.com/...-consider-security-first/

Samengevat:
“If you talk to the Docker guys, they say ‘Of course there are security issues. This is beta code,”

[ Voor 3% gewijzigd door d1ng op 12-04-2016 20:07 ]

[CyBeR]

Hero of Time schreef op dinsdag 12 april 2016 @ 16:13:
[...]

Precies, dat zeg ik. Maar initieel heb je altijd een OS nodig om de boel aan te sturen, ongeacht wat je draait. Thulium heeft 't over 'extra bloat' wat een container zou bevatten, maar dat is dus niet zo.

Oh pardon jij bedoelt buiten de containers. Dat klopt, maar zo ongeveer alles wat daar draait is per definitie een OS. Hoeveel er in zit verschilt. CoreOS, RancherOS en SmartOS zijn redelijk uitgekleed bijvoorbeeld.

[Verwijderd]

CyBeR schreef op dinsdag 12 april 2016 @ 20:26:
[...]CoreOS, RancherOS en SmartOS zijn redelijk uitgekleed bijvoorbeeld.

Idd. En nog wat leeswerk: kijk eens bij MirageOS, lees het weblog van SmartOS en kijk eens bij AlpineLinux.

Hoe ik het als geïnteresseerde leek begrijp, is dat je tussen het "metaal" en je applicatie een aantal lagen hebt draaien. En dat er daarin veel varianten zijn. Nou ik erover nadenk, een beetje vergelijkbaar met de fat client of thin client discussie. Waar heb je je intelligentie?

Als je de onderste laag minimaal houdt (Xen, SmartOS) dan moet je in de volgende laag meer functies hebben. Om, zoals gezegd, allerlei processen aan te sturen. Iemand moet het doen, zeg maar. Als je de onderste laag dikker maakt (een volledige BSD distributie bijv.) dan kan de laag daarop weer minimaler zijn.

[Hero of Time]

Nee, zo werkt het niet. Voor virtualisatie heb je 2 types. VMWare ESX en Xen zijn sneller en werken directer met de hardware naar de VM toe voor betere performance en mogelijkheden. Maar VMware Workstation en VirtualBox bijvoorbeeld zijn type-2, het heeft een Host OS nodig om te functioneren. Ze hebben een laag extra, het Host OS om de harware te kunnen benaderen en dat zorgt voor minder performance. Voor zo'n type-2 hypervisor maakt het niets uit of je een minimaal OS gebruikt of vol met extra software knalt. Het moet hoe dan ook door dezelfde laag heen. Je hebt alleen voor de VM te maken met shared resources met wat er op het Host OS draait. Een volledige GUI met visuele effecten, download clients, etc zorgen natuurlijk voor minder resources voor de VM, maar dat heb je ook bij type-1 als een guest flink staat te stampen.

Voor containers is het een heel ander verhaal. Dat draait geen volledig OS. Het bevat alleen dat wat nodig is om de specifieke applicatie te draaien. Als je bijvoorbeeld alleen vim gaat draaien in een container, dan heb je alle dependencies van vim nodig, maar niets meer. Dus geen kernel e.d. Het is vergelijkbaar met type-2 hypervisors, echter heb je minder overhead omdat je niet een heel OS nodig hebt in de container. Dit kan zorgen voor betere performance, maar is ook weer beperkt in mogelijkheden afhankelijk van je configuratie van de container.

Dan heb je nog je thin vs fat client, dat is weer heel wat anders. Die dingen worden gebruik voor remote desktop werk, waarbij een thin client niets doet behalve de verbinding maken en that's it. Een fat client daarentegen draait ook lokaal applicaties en kan zelfs video zaken afhandelen zodat de remote server dit niet hoeft te doen. Denk aan hardware acceleratie voor video afspelen. Een server zou dat allemaal op de CPU moeten doen, terwijl een fat client de GPU van zichzelf kan gebruiken.

[Verwijderd]

Dank voor de verbeteringen, Hero of Time !

[JaQ]

Is dit niet waar Apple met haar sandboxes zich op heeft geprobeerd te richten in OS X? (jammerlijk gefaald, want techneuten willen pielen). De sandbox strategie is wel redelijk succesvol in iOS.

[CyBeR]

Soort van. De sandbox in OSX limiteert waar apps toegang toe hebben, maar de apps worden niet in containers gestopt. Ze hebben dus een volledige view van het systeem terwijl de gemiddelde container zich voordoet als een volledig eigen systeem. (Hoeft niet -- in linux kun je als container runtime instellen wat er wel en niet gedaan moet worden qua fs, netwerk en users.)

Zo hard heeft dat niet gefaald overigens -- voor distributie in de app store is sandboxen volgens mij inmiddels verplicht.