De zwakste schakel is en blijft de gebruiker van het OS.

Complexheid & oncontroleerbaarheid (onoverzichtelijkheid) v.s. Gebruikersvriendelijkheid.

compatibiliteit is de zwakste schakel

en idd de gebruiker

Zie niet zo zeer in waarom compatibiliteit een veilighieds risico op zich zou moeten zijn....? wel dat complexheid & oncontroleerbaarheid (onoverzichtelijkheid) v.s. Gebruikersvriendelijkheid zeker een risico is. Microsoft heeft b.v. te veel toegegeven aan de gebruikersvriendelijkheid van het systeem en de beveiliging pas aan het einde van het lijstje wensen gezet.

Mensen willen mooie systemen die snel en goed met elkaar kunnen kletsen (misschien dat hier de bedoelde compatibiliteit zit) en ze moeten ook nog eens niet al te moeilijk te beheren zijn.

Microsoft heeft er voor gekozen om een systeem te bouwen waar voor de gewone thuisgebruiker bijna geen drempels in zitten en daar hebben ze echter te veel moeten toegeven aan het gedeelte security. Mensen weten niet meer wat wel aanstaat en wat niet wat wel mag en wat niet en in een zekere zin hebben ze ook het idee dat het allemaal wel zal (de human factor).

Het uptodate houden van de systemen wat betreft alle bugfixes en dergelijke is ook bijna een dagtaak en iets wat je niet van elke thuis gebruiker kan vragen.


-----------------
Als je een veilig systeem wil bouwen voor de consumenten markt dan zal je rekening moeten houden met de dat de gebruiker als eerste jou product tegen dat van windows gaat houden met de vraag wat is het beste voor mij.

Dan zal hij gaan kijken, snap ik het en kan ik er alles zelf mee regelen wat security betreft (we hebben het over een iets meer dan gemiddelde gebruiker de basic gebruiker kijkt niet eens naar beveiliging)

De volgende vraag die hij gaat stellen is wat moet ik doen als er een fout wordt gevonden,... moet ik telkens een over ander servicepack draaien op mijn systeem of niet.

De algemene vraag,..... kan ik er snel en simpel mee werken maar alles zelf wel regelen als ik dat wil.

En dan natuurlijk moet het hele zaakje wel opensource zijn zodat mensen zelf de fouten er uit kunnen grasduinen en een oplossing kunnen aandragen die je dan weer kan gebruiken in een official bugfix.
------------------------------


SUNTAC

Hoi bedankt voor jullie reacties,
Ik zie nu dat het vooral draait om complexiteit en oncontroleerbaarheid vs gebruikersvriendelijkheid.
Verder snap ik ook wel dat de gebruiker de zwakste schakel is, maar een feit is dat je daar weinig aan kan doen.
het is immers toch heel moeilijk om hen te kunnen beinvloeden.
Maar is een OS dan naar jullie mening secure wanner je de OS gaat strippen???
Ik bedoel zijn naar jullie mening de memory management en file system ed. al secure genoeg op dit moment?
Want een veel voorkomende issue is toch wel bufferoverflow.

Nog een vraagje.
Is het volgens jullie mogelijk om bijvoorbeeld bufferoverflow te voorkomen dmv goede authenticatie te implementeren in een OS?

Nee, bufferoverflows, underruns, overruns en andere malheur voorkom je door netjes te programmeren. Niet met tweede-lijns 'security' features om ze af te vangen..

Ik denk dat dit nog steeds een van de heftigste is..
Wang XT300-STOP , ouwe bagger, maar nice

http://www.radium.ncsc.mil/tpep/epl/entries/CSC-EPL-92-003-C.html

Helemaal mee eens BufferMySox. :-)
het zou gewoon de eerste keer al goed afgevangen moeten worden in de code en dit zou niet moeten gebeuren door een of andere tool of vreemdsoortige ondervanging van het probleem.

Maar terug te komen op de vraag... nee er is op dit moment geen enkel OS wat goed genoeg beveiligd is naar de wens van de veeleisende gebruiker. Iets is nooit helemaal voor 100% te beveiligen.....

wil je meer weten over het beveiligen van system en dergelijke onderwerpen kijk dan eens een keer het boek "Secrets & Lies: Digital Security in a Networked World" in geschreven door Bruce Schneier. Ja inderdaad ook de man van het boek "Applied Cryptography" zoals je misschien al wel eens hebt gelezen. Meer informatie over deze knaap kijk dan even op http://www.counterpane.com/schneier.html

SUNTAC

We gaan dom doen:)


-------zo hoort het niet-------

* bron, onbekende lengte. Maar we gaan er van uit dat nooit meer dan 255 tekens en braaf een '0' null aan het eind staat.
* definieer buffer, 256 tekens, beeindig op karakter '0' null.
*label:dom
* lees 1 teken van bron, bewaar in register x
* controleer of teken in register x is '0' null, zo ja spring naar :heeldom
* schrijf teken in register x naar buffer, verhoog pointer in buffer en bron.
* spring naar :dom
*label:heeldom

-----------------------------------

Hmmmm als het naar heeldom gaat dan doet ie het wel naar behoren dus :)

Ik heb trouwens het boek van Bruce Schneier al gelezen.
Het is zeg maar toch wel vrij abstract.
Wel makkelijk om te lezen en vrij grappig overigens.
Maar ken je misschien nog andere adviezen qua literatuur wat meer gerelateerd is aan de combinatie van OS en security?

Maar als ik het goed begrijp wordende meeste security flaws veroorzaakt door onzorgvuldig programmeren (bugs) en niet zozeer aan het design van de OS?

inderdaad heeft hij een leuk boek geschreven en vrij abstract maar als je een basic inzicht wil krijgen over security denken dan is dit in mijn ogen zeker een aanrader.

het design van het OS is ook trouwens aangetast door de onzorgvuldige manier van programmeren. Onder de streep gezien is het design van OS op zich meestal wel in orde maar zijn de losse componenten er van soms niet goed doordacht en hebben een slecht design en dus slechte code. Hierdoor valt het hele design van het totaal plaatje (OS) dus in elkaar.

Als je een huis gaat bouwen en de stenen zijn slecht dan kan je de bouwtekening van je huis nog zo goed voor elkaar hebben het zal toch instorten...... een ketting is zo sterk als de zwakste schakel..... dat soort dingen dus...

SUNTAC

Errrrm, jij bedoelt dat ik met een 'onbekende' input NIET in staat ben om over je code heen te schrijven door simpelweg 256 keer een 'x' te voeren + m'n eigen code ? Welke '0' null ?
Volgens mij ben ik dingen erg aan het overschrijven dan.
Als je ook nog eens je buffer (laten we het de dombuff noemen) pas definieerd in je code zelf, durf ik te wedden dat het label :heeldom wel eens weg zou kunnen zijn..
Ofzo.

Als je niet ook nog op de ;plaats' van de pointer in je buffer / lengte van reeads geschreven data controleerd, beloof ik je veel debug-plezier..