Correctie. MS-DOS had helemaal GEEN beveiligingsmodel.

ASLR, NX en al die andere trukendozen hebben in principe ook helemaal niets te maken met een beveiligingsmodel. Beveiligingsmodellen zijn bijv. RBAC, MLS, ACL en nog een aantal anderen.

Dat de veiligheid van X om te huilen is dat klopt. Maar dat is al zo'n 10-15 jaar bekend geloof ik.

Wat toevallig dat deze dame zelf een OS aan het knutselen is met AppVMs voor het isoleren van applicaties...

http://qubes-os.org/Home.html

;-)

Ben wel benieuwd wat er uit gaat komen. Het is nu nog in Alpha.

Docu staat hier: http://qubes-os.org/files/doc/arch-spec-0.3.pdf

Beetje vreemde stelling. Er is geen probleem met de gebruikersaccounts onder Linux/MacOS, maar met de X-server (die bovendien lang niet altijd gebruikt word). Bovendien kunnen accounts voor een hoop meer dingen praktisch zijn dan alleen het afschermen van bestanden/gegevens lijkt mij.

"I guess" ??
LOL, en die noemt zichzelf rootkit expert.

Inderdaad, OS-X gebruikt geen X en heeft z'n eigen implementatie (Aqua/Quartz Compositor) die toch heel anders in elkaar steekt dan X11R6.

Met de Windows Vista kernel werd een nieuw beveiligingsmodel geïntroduceerd: Mandatory Integrity Control
https://secure.wikimedia.org/wikipedia/en/wiki/Mandatory_Integrity_Control

En voor de media industrie werden ook sinds Vista protected processes toegevoegd.
https://www.microsoft.com/whdc/system/vista/process_vista.mspx

File attributes zijn niet hetzelfde als file permissions (ACLs). Verder was er geen 'voorziening' voor undelete, dat was gewoon een leuke bijkomstigheid vanwege de manier waarop bestanden werden verwijderd. Deze zaken hebben overigens meer met het filesystem te maken en niet zo zeer iets met het OS.

Wat Rutkowska -m.i. terecht- zegt is dat als je een willekeurige applicatie start, dat die applicatie, ondanks alle "moderne" voorzieningen, alles kan met al jouw bestanden wat de programmeur maar wil.

Voorbeeld: je start onder Windows het calculator programma; als de programmeur daarvan code heeft ingebakken om (onder specifieke omstandigheden) al jouw Word documenten naar een adres in Rusland te e-mailen dan zal waarschijnlijk niets op jouw systeem dit programma een strobreed in de weg leggen.

Zelf zul je het waarschijnlijk ook niet merken, we vinden het tegenwoordig heel normaal dat netwerkledjes ook knipperen als je niets internet-achtigs zit te doen en/ofdat je schijf reutelt terwijl je niets aan het openen of opslaan bent (ik heb zojuist de service mcods.exe op disabled gezet, had al een uur CPU tijd opgevroten, gebruikte 130MB RAM en 30-50% CPU, meende kennelijk dat hij de baas was op de PC waarop ik dit tik en ik wel even kon wachten - dacht het niet).

Onder Windows heb je permissies op bestanden (ACL's) en privileges (vaak user rights genoemd) die aan groepen of personen worden toegekend. Er is (bij mijn weten) geen enkel vergelijkbaar mechanisme dat je aan executable code kunt knopen; daarmee zouden aanvalsvectoren enorm kunnen worden ingeperkt.

Personal firewalls vullen dit een beetje op door te vragen of je het in het bovenstaande voorbeeld goed vindt als calculator.exe een internetverbinding probeert te maken. Echter de bijbehorende meldingen zijn meestal zo cryptisch en onvolledig (svchost.exe wants to connect to port 80/tcp at 81.95.144.123, okay?) dat normale mensen JA kiezen en meteen [v] stel me nooit meer zo'n onbegrijpelijke vraag aanvinken, en bovendien blijkt het in de praktijk steeds weer mogelijk om personal firewalls te bypassen, bijv. door zo'n connectie via MSIE of zo te maken.

Dus dat soort support wil je eigenlijk in het OS geregeld hebben. Daarnaast heeft calc.exe m.i. geen enkele reden om Word bestanden van jou te openen. Per bestandsextensie zou er, naast het lijstje van apps die handig zijn om bestanden van dat type te openen, een lijst van programma's kunnen bestaan die dat mogen (wellicht kunnen die lijsten hetzelfde zijn).

Ook heel belangrijk zijn privileges als het mogen injecteren van DLL's en het hooken van API calls. Zo zijn er nogal wat handige utilities die alle toetsaanslagen monitoren voordat ze het actieve venster op je scherm bereiken - maar er is natuurlijk ook zat malware die dat doet. Dus ook dat zouden privileges kunnen zijn die je (als beheerder) selectief toekent aan programma's (leuk dat virusscanners dit proberen maar dat leidt vaakt tot false positives en blijk in de praktijk onvoldoende betrouwbaar te werken).

Kortom, het feit dat ik een programma start moet niet automatisch betekenen dat de programmeur daarvan alles mag wat ik mag, en dat is sinds MSDOS nog niet veranderd. OS features om dit te voorkomen zijn non-existent (in plaats daarvan douwen ze je meuk als 3D desktops door de strot - is even leuk maar verspilt uiteindelijk meer tijd dan een "classic" desktop).

in principe kun je met desktop apps hetzelfde doen als wat met server-apps common practice is. De processen onder een andere user laten draaien (even los van die "X-bug" waar over wordt geschreven). Dan heeft ieder proces niet zomaar toegang tot alles van de user. Uiteraard brengt dit momenteel moeilijkheden met het gebruik van bestanden. Stel je download een file in een geisoleerde Firefox en je wilt als user Y gebruik maken van een bestand gedownload en geowned door user firefox. Ben er mee eens dat dat niet heel lekker soepel en secure mogelijk is voor een gebruiker (dus zonder gebruik van bijv. sudo).

Verder is bijv. AppArmor toch bedacht voor dit soort zaken? (wederom los van eventuele root X processen die vanalles mogelijk maken)

Grappig, in de tijd dat ik als programmeur bij een mainframe-site werkzaam was boden de beveiligingspakketten wel dit soort mogelijkheden. TopSecret had "program pathing", waarbij een gebruiker een dataset alleen via een specifieke load module mocht benaderen. Ook ben ik de mogelijkheid tegengekomen om een applicatie van securityprofiel te laten wisselen, zodat een applicatie effectief een eigen user kon worden gegeven voor de benadering van eigen datasets, terwijl andere datasets met de rechten van de gebruiker werden benaderd. Je moet een applicatie die je die mogelijkheid geeft (dat was een recht dat weer op een ander niveau kon worden toegekend geloof ik) natuurlijk wel heel grondig vertrouwen. Ik dacht dat zowel RACF als TopSecret die mogelijkheid boden. Zo achterlijk is dat goeie oude mainframe kennelijk ook weer niet ;-).

Je kan dezelfde resultaten behalen door de benadering van data via een separaat proces te laten lopen dat met andere rechten dan de gebruiker draait. Op een desktop-systeem wil je vaak juist wel met allerlei applicaties bij dezelfde data kunnen. Er zijn al vijf verschillende toepassingen die ik regelmatig gebruik om met grafische bestanden te werken, en dan vergeet ik er vast wel een paar die ik minder vaak gebruik. En met je normale bestandsbeheer-tools wil je natuurlijk bestanden die je als je eigen beschouwt kunnen beheren. Flexibiliteit is ook wat waard.

Sind de Vista kernel kan je aan processen een integrity level koppelen: Mandatory Integrity Control
https://secure.wikimedia.org/wikipedia/en/wiki/Mandatory_Integrity_Control
Een process met een lager integrity level kan een process met een hoger integrity level niet manipuleren (openen van een process handle faalt). Dit is hoe IE in protected mode werk. Die integrity levels worden o.a. ook op files en registry keys gezet. Technisch gezien gebeurt het toekennen van de integrity level middels een nieuw type ACE in de security descriptor, m.a.w., het kan gebruikt worden op elk securable object.

Aanvulling: strict genomen bestaat er geen privilege voor het injecteren van DLLs of het hooken van API calls, omdat er geen specifieke API functies zijn om een DLL te injecteren of de IAT te patchen.
Een DLL injecteren gaat als volgt: process A opent een handle naar process B, schrijft dan een piepklein programma in het geheugen van process B (met WriteProcessMemory), en start dan het programma met CreateRemoteThread. Het programma is gewoon een jump naar LoadLibrary + de naam/path van de DLL.
Om WriteProcessMemory en CreateRemoteThread te mogen gebruiken op processen van een andere account, heb je het debug privilege nodig. Voor je eigen processen heb je dit niet nodig.
AV end HIPS die DLL injectie controleren doen dit meestal door CreateRemoteThread te monitoren en zonodig te blokkeren.