Pipelight Bringer Widevine Support For Linux Web Browsere

#0: Netscape Plugin API (Firefox, Chrome, Midori), så du kan bruge video streaming websites såsom Neflix, er blevet opdateret i går.

Chrome på Linux supporterer ikke længere NPAPI så vidt jeg ved. DVS Java og Adobe Flash m.f..

Så vidt jeg husker så er PipeLight ikke længere nødvendig på NetFlix.

PipeLight er det eneste der nogensinde har inficeret Linux jeg har været i nærheden af med en Windows trojaner.

http://www.linuxin.dk/node/21311

#1: Så vidt jeg husker så er PipeLight ikke længere nødvendig på NetFlix.

Netflix krever widewine der kun officielt understøtter chrome(ikke chromium) hvilket som jeg forstår det er det de her implementere, browsere der ikke er certificeret af google.

I teorien burde firefox nye MSE understøtte widewine men widevine har vist ikke et plugin til firefox.

Chrome kommer iøvrigt stadigvæk med flash og svjv er pepperflash ikke 110% begrænset til chrome's NaCL LLVM runtime, men er svjv som resten af chrome beskyttet via chroot

#2: Chrome kommer iøvrigt stadigvæk med flash og svjv er pepperflash ikke 110% begrænset til chrome's NaCL LLVM runtime, men er svjv som resten af chrome beskyttet via chroot

Og derfor kan Chrome ikke uden videre køres fra root, men kun fra en standard konto.

Annoncen er efterhånden et år gammelt (January 20, 2014), så jeg tænkte den var mere eller mindre forældet IHT Chrome's NPAPI support, men jeg bruger ikke NetFlix, så det er noget jeg formoder.

Nu ser jeg netflix på chromecast, men sidst jeg tjeckede brugte Netflix silverlight - derfor skal man bruge pipelight. Pipelight fik jeg dog aldrig til at virke på Mageia.

Netflix skulle vist virke med html5, men kun i ubuntu så det har jeg ikke tjecket.

Widewine bruges af HBO nordic og det kan man installere hvis man kører windows udgaven af firefox under wine.

Netflix virker ud af boksen i nyest Chrome (40). Man behøver ikke Silverlight, og ingen ninjatrick.

#3:
Og derfor kan Chrome ikke uden videre køres fra root, men kun fra en standard konto.
????

Bruger chrome ikke stadivæk en suid loader der kicker et chroot miljø igang hvilket svjv betyder at chrome modsat firefox kræver root privilegier for at kunne bruge sin sandbox, og har aldrig hørt om at den ikke skulle kunne fungere for kontoen.

#6: Bruger chrome ikke stadivæk en suid loader der kicker et chroot miljø igang hvilket svjv betyder at chrome modsat firefox kræver root privilegier for at kunne bruge sin sandbox, og har aldrig hørt om at den ikke skulle kunne fungere for kontoen.

Nej. Chrome, modsat Firefox, kan ikke køres fra en root desktop uden man explicit definere en standard konto Chrome kan lagre data på.

Du kan prøve det, f.eks ved at aktive root login på desktop, logge på som root og så køre Chrome. Jeg synes det lyder ganske fornuftigt, og gør formentlig Chrome mere systemsikker end Firefox.

Du vil formentlig se denne meddelse:
https://db.tt/sGIf6WV1

#7: Nej. Chrome, modsat Firefox, kan ikke køres fra en root desktop uden man explicit definere en standard konto Chrome kan lagre data på.

det jeg taler om er

ll /usr/lib/chromium-browser/chrome-sandbox
-rwsr-xr-x 1 root root 14288 Nov 22 21:10 /usr/lib/chromium-browser/chrome-sandbox*

s betyder eksekvere med root privilegie og uden den shim køre chrome uden snadbox det er et gotcha ved cgroups og chroot.

Firefox kan køres uden suid fra en ren user konto, uden at du mister sandbox funktionaliten, mens chrome er afhængig af at have rettigheder til at sætte etchroot op(har kun root).

Tjækkede og det er korekt chrome har en "hvis uid=root så brok"men det er ca 2 liniers kode og ikke en væsentlig sikkerhedsfeature.

/opt/google/chrome$ ls -l
-rwsr-xr-x 1 root root 13836 jan 27 02:58 chrome-sandbox

/usr/lib/firefox$ ls -dl /usr/lib/firefox/libmozsandbox.so
-rw-r--r-- 1 root root 34076 jan 26 00:18 /usr/lib/firefox/libmozsandbox.so

Der er åbenbart lidt forskel på hvor Chrome's sandbox befinder sig, men det er rigtig nok at root er ejer. Det ser også rigtigt ud at sikkerheden i Chrome er potentielt diskutabel.

Hvis du gider må du meget gerne fortælle lidt mere om Firefox sandbox, hvor den er, eventuelt /.mozilla/firefox/, og ikke mindst firejail hvis du kender noget til den.

Det jeg tænker på er at når firefox kører fra root logon, så er det ikke en standard konto, mens det selvfølgelig er når den kører fra en standard konto. Det er, som jeg forstår det, naturligvis nødvendigt, fra tid til anden, i det mindste ved bestemte lejligheder, at kunne køre en browser fra root.

Som jeg ser det, så vil firejail få Chrome's sandbox til at køre inden i en ny sandbox, mens jeg oplever firefox usikker uden firejail fra en root logon. I modsætning til visse andre, så mener jeg det altid er dårlig sikkerhed at browse nettet fra en administrativ konto.

https://l3net.wordpress.com/2014/09/19/firejail-a-security-sandbox-for-…

#9:
Hvis du gider må du meget gerne fortælle lidt mere om Firefox sandbox, hvor den er, eventuelt /.mozilla/firefox/, og ikke mindst firejail hvis du kender noget til den.

Chromes suid binære sandkasse er realt set ikke en sandkasse men en måde at bede linux kernen om at sætte en sandkasse op, eller sagt på en anden måde chrome implementere ikke sin egen sandkasse på linux men slår kernes process isolering til. det betyder at uden adgang til root privilegier så har chrome under linux i princippet ingen sandkasse. firefox derimod ejer hele sin egen sandkasse.

Det er ikke et væsentligt sikkerhedsproblem så længe suid bit'en er sat på chrome-sandbox eftersom chroot og cgroups er så sikkert som software kan blive, men det betyder at enhver fejl i "chrome-sandbox" er et potentielt privilegie eskalations problem. Noget firefox's rene userspace sandkasse ikke tilader, ulempen ved firefox's model er så at firefox udviklet selv har 110% af ansvaret for at skrive deres sandkasse.

Filplaceringerne er her underordnede det vigtige er runtime hvor halvdelen af chromes sandkasse lever inden i kernen hvor root privilegier er nødvendige mens firefox er ren userspace og derfor kan sættes op uden root privilegier. Der er fordele og ulemper ved begge modeller.

Firejail gør i princippet det samme some chome-sandbox men som jeg kan læse med et nyere API end chrome bruger og også bruger lidt mere finkornede regler men jeg er hverken apparmor eller cgroups ekspert så kender ikke alle detaljerne.

Gætter på at chome gør noget tilsvarende på windows men har ikke rigtigt gidet at undersøge det.

#9: Det ser også rigtigt ud at sikkerheden i Chrome er potentielt diskutabel.

suid er den rigtige måde at give adgang til system ressourcer og det er ikke altid en fordel at hole alt ude af kernel space eftersom der er features der er nemmere at få sikre i kernelspace end i userspace.

Vi taler ikke om at chrome kører de idividuelle processer med root privilegier kun at der sendes instruktioner til kernen med root privilegie som en del af start processen for en ny tab.

Ultimativt kunne man komme uden om det kræver root at sætte nye isolations politikker i kernen, ved at have en system daemon der tager forespørgsler fra programmer og giver det videre til kernen men det flytter bare problemet fra kernen til en "speciel" userspace tjeneste, hvilket er hvad hele systemd debatten handler om.