Mono vs. sikkerhed

Så længe det bliver opdateret hyppigt og du sørger for generelt at holde dig opdateret, samt evt. bruger mitigation software/sandboxing på applikationen, såsom apparmor (Ubuntu/SUSE) eller SELinux (hele systemet, ikke appbaseret, - Fedora/Centos/RHEL)



Og bruger en content blocker som uBlock Origin i Firefox, så sker der ikke en pind nogensinde.



Men er du ligeglad med alt hvad jeg har skrevet, bør du nok ikke bruge det.

Jeg kan ikke rigtig se hvorfor brugen af Mono skulle gøre softwaren mindre sikker på dit system end så meget andet. Hvis du laver software compiled sprog (C/C++/Rust osv.) så gør du dig også afhængig af biblioteker som alle potentielt kan have sikkerhedsproblemer. Man vil sikkert endda kunne argumentere at brugen af Mono (og for vidt skyld Java) mindsker risikoen da programmet du kører allerede kører i en virtuel maskine hvor angrebsfladen (samt tilgang til hukommelsen) vil være begrænset set i forhold til et program skrevet i C.



I stedet for at være bange for hvad et program bruger af programmeringssprog så bør du hellere fokusere på det element at du kører software skrevet af fremmede og om du stoler på dem (specielt om de håndterer sikkerhedsproblemer eller bare ignorer dem). Der findes usikre programmer skrevet i et hvilket som helst sprog men det er sku ikke sproget der afgør om et program er mere eller mindre sikkert set fra et sikkerhedsperspektiv.



Bare sørg for at installere mono igennem dit pakkesystem således det holdes opdateret. Og samme råd gør sig selvfølgelig gældende for et hvilket som helst programbibliotek du måtte installere som krav for at køre et givent program. ;)

men det er sku ikke sproget der afgør om et program er mere eller mindre sikkert set fra et sikkerhedsperspektiv.



Mono og .NET er notorisk fejlbefængt, det er almen viden. Ligesom Java runtime. Mere komplekst = flere fejl, flere fejl, flere sårbarheder, flere sårbarheder, større angrebsflade. Sådan er det bare.



KISS :-)

Mono og .NET er notorisk fejlbefængt, det er almen viden. Ligesom Java runtime. Mere komplekst = flere fejl, flere fejl, flere sårbarheder, flere sårbarheder, større angrebsflade. Sådan er det bare.



Angrebsflade set fra hvad? Et program X du installerer på dit system kan gøre skade på dit system? Hvorledes er det mere sikkert at program X er native frem for at det bruger Mono?



Eller snakker vi om at program X er godartet men misbruges pga. fejl i biblioteker som programmet benytter?



Hvis det er det sidste er det så fair at tælle samtlige fejl i Mono's standardbibliotek med som fejl når det er de færreste programmer der gør brug af alle features? Eller konkluderer du bare at hvis der findes et sikkerhedshul i Mono's webserver implementering så vil en lommeregner skrevet i Mono udgøre en sikkerhedsrisiko selvom den faktisk ikke gør brug af webserver-komponenten?

#3:

Mono og .NET kender jeg ikke fra et udviklerperspektiv, så det vil jeg nødigt udtale mig om. Java programmerer jeg selv en smule i, og har godt nok aldrig hørt, at det skulle være mere usikkert end så meget andet. Jeg er med på, at Java til browsere havde et dårligt ry, men det var jo lidt en anden problematik :)



Det med kompleksiteten er naturligvis rigtigt. Men det er jo allerede på spil i et programmeringssprog som C, hvor der jo også sker mange ting bag ryggen på koderen. Og så har mange af de mere komplekse sprog jo den fordel, at buffer overlow ikke er så påtrængende.



Og ja, det er rigtigt at der fortløbende sikkerhedsopdateres til mange af de programmeringssprog, der kører i virtuelle maskiner, men det handler jo bare om, at man kan opdatere disse. Det ville jo ikke rigtig give mening at "opdatere" C, f.eks., for at forhindre at et program, der er lavet heri, laver rav bag brugerens ryg.

KISS :-)



Alt ny kode har en risiko for fejl. Derfor er det en rigtig god ide at bruge standardbiblioteker til at abstrahere en række koncepter og algoritmer således din kode kan holdes simpel. Risikoen for at du introducere sikkerhedsfejl er væsentlig mindre hvis du bruger store kendte standardbiblioteker frem for at forsøge at kode det hele selv.



Højniveausprog der kører i en virtuel maskine (Mono, Java mm.) er gode til at fjerne en meget stor risiko for kodefejl og det er håndtering af hukommelse som nok er den største skyldner hvad angår sikkerhedsproblemer. Sandheden er desværre den at selv halvgode C udviklere laver mange fejl når det gælder håndtering af hukommelse og specielt når der gør brug af flere tråde. Rust (og go kan delvis smides i samme kategori) kan være svaret på problemerne men det er stadig ikke så udbredt.



En anden god ting ved højniveausprog er de kommer ofte med et meget brugervenligt SDK som bruges af mange. Det gør så at kvaliteten af dette API holdes i en høj kvalitet og fejl rent faktisk bliver udredt.



Jeg må ærlig talt sige at hvis jeg skal køre software skrevet af udviklere af tvivlsom kvalitet så vil jeg langt foretrække at softwaren er skrevet i Java eller C# frem for at stå med et C program der lækker hukommelse og måske crasher efter længere tid uden mulighed for en god fejlbesked om hvad der gik galt.

Og ja, det er rigtigt at der fortløbende sikkerhedsopdateres til mange af de programmeringssprog, der kører i virtuelle maskiner, men det handler jo bare om, at man kan opdatere disse. Det ville jo ikke rigtig give mening at "opdatere" C, f.eks., for at forhindre at et program, der er lavet heri, laver rav bag brugerens ryg.



En anden detalje her er at folk måske ser overskrifter hvor der står "sikkerhedsfejl i højniveausprog X" men det der i virkeligheden er tale om er SDK'et som følger med programmeringssproget og ikke sproget i sig selv. Det gør at hvis du bare ser på overskrifter så kunne man gå hen og tro at C ingen sikkerhedsfejl har. I stedet er det jo glibc eller andre biblioteker der har fejllen.



Sandheden er at hvis du har et stort SDK der bruges af mange så vil der også blive fundet flere fejl. Men det er altså ikke meget værre end hvis du tager og kombinerer de 10-15 mest benyttede C biblioteker (ca. den mængde der skal til for at sammenligne med fx Java SDK) og ser på fundne fejl her.

Koden er kompleks, ligesom meget kode fra Oracle og Microsoft, Java og afarter. Generelt, og kun generelt, er det en god idé, at undgå kompleks kode i det hele taget, da kompleks kode øger angrebsfladen, hvis man gør brug af det, både på webservers og på desktop, datacentre, overalt.



Kompleks kode kan også betyde at der sikres imod forkert brug af koden. Jeg er som sådan enig i at man bør holde sine funktioner simple men det er temmelig endimensionelt bare at sige at kompleksitet == ondt.



Un-native kode er langtfra altid sandboxed, Wine er ikke engang en container, der er kapslet inde, - men eksekverer fra wrappers. Wrappers er hacks. Hacks beviser, at det er nødvendigt at reverse engineer noget. Er det nødvendigt, at reverse engineer noget, er det fordi den oprindelige un-native kode ikke er ligetil. Var den ligetil, ville den være simpel. Var den simpel, ville man ikke behøve, at reverse engineer'e noget, fordi man bare kunne porte den rent. Kunne man det, var det fordi koden var så nem, at porte, og var den det, var der højst sandsynligt færre fejl i koden, og dermed også færre sikkerhedshuller.



Wine er lavet til at tage X86 (og X86_64) programmer der er linket op imod Windows kernen og Windows systembiblioteker og gør således de kan køres på Linux. Det gør den ved at løbende oversætte Windows specifikke systemkald til noget tilsvarende på Linux. Det betyder at alt kode inde i EXE programmerne som ikke gør brug af systembiblioteker vil køre fuldstændig native (fx logikken i programmerne). Det er derfor man siger at "Wine is not a emulator" fordi den emulerer faktisk ikke en X86 processor men oversætter kun systemkald.



Windows er desværre ikke komplet åbent hvad angår logikken bag alle systemkald og alle de undtagelser der måtte være (trods alt ikke alle programmer der bruger Windows API'et 100% efter spec.). Derfor er der brug for en del reverse engineer for at kunne implementere en tro kopi af hvordan Windows håndterer systemkald. Derudover så er der en række standardbiblioteker med Windows (DLL'er) som også er nød til at blive lavet som en erstatning da du ikke bare på tage dem direkte fra Windows.



Software vil i mere eller mindre grad gør brug af det operativsystem der kører i og hvert operativsystem har forskellige standardbiblioteker og systemkald. For ikke at skrive alt fra bunden så gør langt de fleste også bruge af 3. parts biblioteker som måske ikke er lavet til flere platforme.



Dette er kerneårsagen til du ser programmer der er skrevet specifikt til Windows og ikke er særlig nemt at portere til andre platforme. Og her kan det sagtens give mening at prøve at se om ens program kører 90% fint ved brug af wine og så konkludere at dette er OK set ud fra antal brugere der bruger Linux versus Windows perspektivet. Kunne det gøres bedre? Ja, men alting er ikke så komplet ensidet og vi må erkende at ikke alle behov er løst lige godt på alle platforme.



Hvis vi forestiller os, at Java kørte inde i Apparmor på Linux, ville jeg aldrig være bekymret for den. Hvis vi forestiller os, at Wine kørte inde i Apparmor, ville jeg aldrig være bekymret for den.



Personligt synes jeg måske du har lige høje nok forventninger til AppArmor set i forhold til der også er fundet sikkerhedsproblemer i denne løsning som er langt fra simpelt implementeret men fair nok. Problemet for Java er at mange af disse sikkerhedsfokuseret container-teknologier lige skruer sikkerheden lidt højt nok i vejret og afviser at køre programkode der er i hukommelsen som ikke kommer fra programmet selv (altså tillader ikke at Java VM'en genererer programkode på runtime).



En løsning der ser ud til at være på vej her er muligheden for at compile Java programmer til native programmer hvilket fjerner behovet for dynamisk at generere kode ved kørsel.



Jeg skal ikke kunne sige hvordan Wine fungerer og hvorfor det ikke virker med AppArmor men det kan tænkes den laver noget lignende hvor den dynamisk modificere det kørende program således systemkald der oversættes bliver persisteret i hukommelsen således oversættelsen kun skal se en gang imens programmet kører og derved give en langt bedre performance. Igen, denne form for opførsel er no-go ved teknologier som AppArmor.



Og ja, Rust er potentielt en sikkerhedsrisiko, omend ikke beviseligt forhøjet. Sikkerhed handler om tillid, og har du tillid til Mono's kodekvalitet? Jeg har ikke. Jeg har tillid til Rust. Men er man i tvivl om man skal bruge det, og det gælder generelt alt, så lad være med, at bruge det. Alt software udgør i en vis grad en sikkerhedsrisiko.



Igen vil jeg sige at den største sikkerhedstrussel er det at du kører programmer skrevet af andre og det har ikke en dyt at gøre med hvad for en teknologi der benyttes til at køre programmet. Jeg har en forholdsvis fin tiltro til kodekvaliteten i mono projektet da det bruges af temmelig mange og modtager rigtig mange ændringer. Min tiltro er under alle omstændigheder langt højere end til random program X skrevet i C# eller noget andet sprog.

Igen vil jeg sige at den største sikkerhedstrussel er det at du kører programmer skrevet af andre og det har ikke en dyt at gøre med hvad for en teknologi der benyttes til at køre programmet.



Det har det jo al den stund, at det kan blive eksploitet. Ja, det er proof of concept, men i princippet; lad være, at have software liggende, du ikke bruger. You'll never know.



I øvrigt glæder det mig, hvis Wine kører så native, som du siger. Så kan det ikke være så komplekst, som jeg troede.

#10: I øvrigt glæder det mig, hvis Wine kører så native, som du siger. Så kan det ikke være så komplekst, som jeg troede.

Wine, CrossOver og Mono kører native, også på macOS. De er ikke emulatorer, Kompleksiteten handler om at få Windows programmerne til at fungere. At få de nødvendige Frameworks installeret.



Sikkerheden handler om installation af eventuelt inficerede Windows programmer. Man går ikke på internettet med Wine etc., men muligvis med et installeret og inficeret Windows program. Problemet er man formentlig ikke opdager det, hvis ikke Linux eller macOS har et anti malware program installeret. På en Windows maskine har man bare sådan et.



Kun en gang har jeg oplevet en mulig inficeret ie.exe i en default installation på, jeg husker ikke om det var Wine eller CrossOver, og jeg ved ikke om det var en falsk positiv (opdaget af daværende Bitdefender Free for Unix).

#10: Så kan det ikke være så komplekst, som jeg troede.



Det er faktisk uhyre komplekst, og det er en stor bedrift af folkene bag wine. Det komplekse består I at MS ikke har udgivet kildekoden, så det hele er lavet som en reverse engineering af en "sort boks". Man har puttet nogen i den ene ende i API'en og set hvad der kommer ud af den anden ende. Så har man lavet noget kode der giver samme resultat. Men implementeringen kan være fuldstændig anderledes.



Engang i mellem opstår der imidlertid problemer, og det er derfor wine-programmer ofte ikke er 100% kompatible. Selv er jeg helt afhængig af Total Commander som er verdens bedste filhåndtering, men den er heldigvis 98-99% kompatibel. Enkelte ting virker ikke optimalt, og en sjælden gang imellem crasher den, men stor set virker den perfekt.



#12: Men da Wine indeholder Windows-biblioteker er der ikke så meget, at bekymre sig om på *Nix.



Det er korrekt. Malware vil oftest fejle under wine fordi den har nogle forventninger til OS'et som ikke bliver indfriet. Den vil med andre ord bliver "forvirret" og fejle. Men man dog udmærket forestille sig en virusudvikler der specifikt målretter virussen mod wine, og så er det en anden sag. Sandsynligheden er dog lille fordi målgruppen er så beskeden. Vedkommende får mere ud af besværet ved at udvikle til Windows. Og vel efterhånden også til MacOS.



Med andre ord, wine er temmelig sikkert, men ikke helt.



#11: Problemet er man formentlig ikke opdager det, hvis ikke Linux eller macOS har et anti malware program installeret. På en Windows maskine har man bare sådan et.



Jeg har ikke :-) Og har alligevel ikke haft virus siden 1994 hvor Napster bragte noget snavs med sig.



Jeg skanner dog filer manuelt jeg ikke stoler på. Også windowsprogrammer under wine, hertil bruger jeg clamav.

Virus kontra malware. Virus, nej der eksisterer ikke meget virus længere til nogen systemer. Malware, I DEN GRAD til Windows og MacOS, meget lidt til Linux og BSD.

#13: Jeg har ikke :-) Og har alligevel ikke haft virus siden 1994 hvor Napster bragte noget snavs med sig.

Mener du på en Windows maskine? Hvis ja og hvis det er Windows 10, så er Windows Defender AV og Firewall standard installeret. På Windows 7 og tidligere var WD kun Anti Spyware.



Er det Linux du mener, så er der ikke mange grunde til at installere Anti Virus ;) Med mindre man bruger Linux som mail server ...



#14: Virus kontra malware

Det er lidt forskelligt hvordan folk bruger begreberne, men kort er malware (maliciøst software) et fælles ord for virus og spyware og hvor teknologierne er blandet sammen, inklusiv ransomware, bitcoinminers etc..

Når jeg skriver virus, mener jeg malware generelt. De fleste beskyttelsesprogrammer hedder jo stadig noget med antivirus.



Jeg har en virtuel Windows 7 uden noget som helst beskyttelse (andet end hvad der evt måtte være indbygget). Men jeg installerer næsten aldrig noget, bruger den mest til eksperimenter eller for at tjekke noget i Windows.



Så har jeg en Windows 10 på min nye bærbare, her følger der noget antivirus med som er udløbet nu. Jeg bruger stort set aldrig Windows på den bærbare.



Jeg har i øvrigt nogle gange sluppet virus løs for sjov på min virtuelle maskine. Men forinden har jeg taget et snapshot og derefter fjernet alle delte diske så den ikke kan bryde ud. Nogle gange er det interessant at se hvad den laver af ravage.

Tak for jeres overvældende reaktioner på mit simple spørgsmål. Det er dejligt at læse jeres svar og jeres diskussioner. Jeg er stadig ikke helt sikker på, nøjagtigt hvad man skal tage sig i agt for, men har nok en bedre fornemmelse for det nu.

Ud over at man altid skal tage sig i agt på det store stygge internet.



#1: Men er du ligeglad med alt hvad jeg har skrevet, bør du nok ikke bruge det.

Havde jeg været ligeglad, havde jeg aldrig spurgt.



#2: I stedet for at være bange for hvad et program bruger af programmeringssprog så bør du hellere fokusere på det element at du kører software skrevet af fremmede og om du stoler på dem (specielt om de håndterer sikkerhedsproblemer eller bare ignorer dem).

Selvfølgeligt skal man vurdere, hvilke programmer, man bruger, om man virkeligt har brug for dem, men hvis ikke vi alle skal skrive alle vore programmer og styresystemer selv, og det er vist ønsketænkning, så må vi vel vælge at tro på nogen/nogle.



Nu har jeg ikke Windows på computeren og kører heller ikke noget gennem Wine længere, så der er jeg dækket.



Men som sagt: Tak for jeres input og jeres betragtninger.

#18: Min personlige holdning er, at du først og fremmest skal vurdere på, om du har tiltro til udgiveren. Så er det ud fra et sikkerhedsmæssigt synspunkt mindre vigtigt, hvad det er programmeret i. Alle apps kan indeholde sikkerhedsproblemer, men hvis udgiveren er seriøs vil der hurtigt blive udgivet sikkerhedsopdateringer, når det sker.



Hvis man som privat bruger (desktop) gerne vil gøre lidt ekstra for sikkerheden, så kan der til tider være en fordel i at køre løsninger, som ikke så mange andre bruger -- fordi man som privat bruger primært er udsat for angreb fra de masseorienterede malwareformer, og disse vil typisk gå efter konfigurationer, som mange har. Der er simpelthen for lidt "økonomi" i at angribe en applikation, som ikke særlig mange bruger.



En anden ting er så dog, at jeg i nogle sammenhænge har oplevet, at .NET-programmer ikke kører så godt i Wine. Men det finder du jo i givet fald hurtigt ud af :)

#19

Nu kommer det an på hvor Windows afhængigt .NET programmet er skrevet men det er værd at prøve at køre disse programmer med mono (specielt hvis det er terminalprogrammer). Microsoft har åbnet op for rigtig meget af deres API'er så store dele af .NET framework virker i dag med Linux men selvfølgelig ikke alt.

#20: Det var ikke min egen maskine, jeg bøvlede med, og jeg mener nu også vi prøvede at gå Mono-vejen - uden held dengang. Men det er 1-2 år siden, og kan sagtens være blevet bedre i mellemtiden.

#17: Så har jeg en Windows 10 på min nye bærbare, her følger der noget antivirus med som er udløbet nu. Jeg bruger stort set aldrig Windows på den bærbare.

Det bør resultere i at WD overtager efter det udløbede AV, eller i et mindste advarsler fra Windows 10 og AV programmet.



Hvis du er interesseret, så afinstaller det udløbede AV med vendors afinstalleringsprogram (overordentligt vigtigt), og installer derefter Bitdefender Free eller Avira Free. De er gratis og stadig bedre end Windows Defender. Suppler med MalwareBytes Antimalware uden realtime beskyttelse, hvis det skal være gratis.



Det vil deaktive WD's AV, men ikke WD's Firewall. Ønsker du en intelligent Stateful Firewall som erstatning til WD's basis Firewall, så prøv at se om ZoneAlarm Free Firewall eller Comodo Free Firewall opfylder behovet. Comodo Free Firewall er iøvrigt server kompatibel.



Jeg vil gerne tilføje at WD's effektivitet er steget betydeligt på de nyeste Windows 10 versioner. WD er stadig ca 1% dårligere end de fleste købe AV, inklusiv eventuelle gratis versioner, men til forskel fra førhen, var WD's effektivitet ca 10% dårligere. Det er en tydelig forbedring.



Windows 7 er notorisk usikker. Det er klart at hvis man ikke installere noget og ikke går på internettet med Windows 7, så falder risici for den inficeres. Helt kort, så er Windows 7 død.



#17: Jeg har i øvrigt nogle gange sluppet virus løs for sjov på min virtuelle maskine. Men forinden har jeg taget et snapshot og derefter fjernet alle delte diske så den ikke kan bryde ud. Nogle gange er det interessant at se hvad den laver af ravage.



Også jeg, førhen, dels af nysgerrighed og dels fordi AV programmerne ikke altid opdagede malwaren. Især før AV vendors blev så dygtige som de efterhånder er blevet. De fleste AV misser kun omkring 0,1% idag. Det er næsten acceptabelt. Jeg benytter AV-Comparatives som reference https://www.av-comparatives.org/



Derfor er sikkerhedsprogrammernes (AV og Firewall) ressource forbrug efterhånden den største faktor. Disse ekstra lag af beskyttelse koster ressourcer. Derfor skal (forenklet) maskiner med Windows OS være kraftigere end med Linux OS, for at opnå hurtig ydelse, med eller uden WD.

Hej Frogmaster



Du har vel ik brug for WD når du bruger linux og WD er vel en m$windows ting?? Iøvrigt er WD windows defenter??



/allan

Hej 1bot.



1. Nej, du har ikke brug for det (og kan ikke bruge det, i Linux)

2 Nej, Windows Defender er lavet af Microsoft til Windows 10.



Du har ikke brug for AV i Linux

Hej OracleJMT



Jeg blev bare itvil hvad WD stod for.



TAK FOR DIT SVAR!!



/allan

Jeg blev bare itvil hvad WD stod for.



Ja, det kunne tydeligt ses på dit spørgsmål.



TAK FOR DIT SVAR!!



Så vigtigt var det nu heller ikke. Andet end lidt sædvanlig semantisk hygiejne i kommentartråden, ryddende al mulig tvivl af vejen. ;-)

#24: Du har ikke brug for AV i Linux



Jeg må indrøme, at jeg bliver en smule itvivl mht AV når jeg læser jeres andre tråde omkring wine.



Men jeg har ik AV installeret og tænker heller ik det er nødvendig på trods af jeg har installeret wine.



/allan

og uden problemer.



Der er nok større risiko ved en e-mail om, at du har vundet $15.000.000 i et nigeriansk lotteri, du aldrig har spillet med i, eller en e-mail som

"Kære kunde Nordea,

Send strax din NemID adgangskode o g et billde af dit kodrkort.

Ellers bliver din konto spærret om 24 timer.

Venlig hilsen

Net support"



Man skal selvfølgeligt holde hovedet koldt og bevare sin sunde skepsis, men virus er ikke noget, der plager Linux-miljøet.

#29: Man skal selvfølgeligt holde hovedet koldt og bevare sin sunde skepsis

Ja altid, og det er naturligvis et problem for dem der ikke forstår. Sådan noget er ikke nemt for sårbare individer. De vil ofte udlevere deres personlige oplysninger på en sådan forespørgsel ... Det handler om alle der ikke er specielt interesserede i IT.



Samme sårbare individer vil installere inficerede programmer i ren naivitet. Tro mig. Jeg har oplevet overordentligt intelligente personer installere malware (både i Windows og macOS), simpelthen fordi de ikke forstår IT sikkerhed. Netop disse forstår, når de får at vide, at nu skal de altså stoppe med at installere det shit, at det er alvor.



Heldigvis, for alles beskyttelse, er det ikke nemt at installere malware i Linux. Er man kløgtig nok til at installere crossplatform i en Linux, så kan man håbe, samme også er kløgtige nok til at vide hvad de skal holde sig fra.



Off topic, men dog impliceret, hvem kender ikke til politikere, elitære, intelligente eller ej, der har tilladt installation og implementering af maliciøse, ikke mindst religiøse, ideologier? Det er totalt idiotisk og mere normen end undtagelsen ...



Hvis ikke man forstår hvad man har med at gøre, så er man idiot ..., men bare rolig. Vi er alle idioter på et eller flere områder. Den største idiot er "hende", der nægter at lære af sine fejltagelser ...