Avui els meus estudiants de FP han aconseguit tombar amb un
atac DOS l'ordinador amb el que feia una presentació (un Ubuntu
18.04 completament actualitzat) fent que en menys d'un segon el
Firefox reclamés tota la memòria del sistema (16Gb RAM + 4Gb
swap)
Hi ha alguna protecció del nucli per quan una aplicació que
s'executa amb permisos d'usuari demani instantàniament tota la
memòria RAM i swap del sistema, causant un atac D.O.S. ?
He trobat això, però no sé si hi ha una manera més senzilla:
https://unix.stackexchange.com/questions/44985/limit-memory-usage-for-a-single-linux-process
dona'ns detalls de l'arquitectura:
- amb quina eina has fet la presentació (alguna cosa a sobre de
firefox, oi? quina)
- com visualitzen els alumnes la teva presentació: esteu en una
mateixa aula (xarxa local) i ho veuen per un projector o en remot (i
els alumnes amb els portàtils)
qualsevol descripció adicional que afegeixis millor, en seguretat
sempre s'ha de tenir en compte el major detall possible
[...]
L'atac ha estat amb Google Slides i sembla fàcil de reproduir.
Algú em va passar una presentació de Google Slides i, enlloc de
passar-ho a pdf, vaig compartir l'enllaç de la presentació amb 25
alumnes. Fins aquí res anormal.
Els 25 alumnes van obrir la presentació al seu ordinador. Un alumne
per fer la gracia va posar la URL en una pàgina que obria moltes URLs automàticament alhora, així que realment aquella presentació estava oberta o compartida per 100 persones o pestanyes de navegadors. Fins
aquí tot funcionava bé.
Però en el moment que algú feia clic al botó d'iniciar presentació, Firefox en menys d'un segon reclamava tota la memòria del sistema
(16Gb ram + 4 gb swap), i el sistema deixava de respondre.
Em crida molt l'atenció que Google Slides faci petar el navegador quan
es comparteix una presentació amb 100 persones.
Em crida molt l'atenció que Google Slides faci petar el navegador quan
es comparteix una presentació amb 100 persones.
No és tant quan 100 persones obren el document, com quan un d'ells fa
clic al botó d'iniciar reproducció.
Quan moltes persones tenen el document obert el sistema no tenía més que
1 Gb de RAM ocupada entre escriptori i navegador. És quan faig clic al
botó d'iniciar presentació qué de sobte demana tota la RAM i peta. Per què? No ho sé.
Només ho he reproduit un parell de cops amb Ubuntu 18.04 + Firefox 92.0
No ho he provat amb Chromium . Tampoc ho he provat a Windows ni MacOS.
Fa uns dies que veig que els llocs de Google funcionen millor amb
Chromium que amb Firefox. Potser només passa amb Firefox.
Però de les tres preguntes que sorgeixen ...
(1) Per què passa això a Google Slides ?
(2) Per què els navegadors no controlen quan una pestanya es menja tota
la RAM del sistema per avisar l'usuari si la vol bloquejar ?
(3) Per què un sistema operatiu multiusuari no ve de sortida més
protegit per que el procés d'un usuari no es mengi tota la ram causan
una denegació de servei a la resta ?
... a llarg termini m'interessen més la pregunta (3) ó la (2) que la (1)
Fa uns dies que veig que els llocs de Google funcionen millor amb
Chromium que amb Firefox. Potser només passa amb Firefox.
Hola,
Sobre el tema del límit d'usuaris per les aplicacions de Google Drive
(Docs, Sheets, Slides), Google diu el següent:
Share & collaborate on a file with more than 100 people
Up to 100 people with view, edit, or comment permissions can work on a
Google Docs, Sheets, or Slides file at the same time. When more than
100 people are accessing a file, only the owner and some users with
editing permissions can edit the file.
Podeu veure la informació completa aquí[1] amb les solucions que
proposen per compartir amb més de 100 persones. Potser seria
interessant que ens comentessis com vas compartir aquesta presentació:
quins permisos tenies tu sobre la presentació? els alumnes tenien el
mateix enllaç i, per tant, permisos que tu? o l'enllaç dels alumnes
només tenia permisos com a lector ?? Pots reproduir el problema si comparteixes la presentació de la manera que es proposa a la
documentació de Google ??
Sobre el motiu pel qual Firefox consumeix tota la memòria RAM, imagino
que tindràs extensions i/o temes carregats. El primer pas seria
intentar reproduir el mateix problema utilitzant el safe mode (e.g. #
firefox --safe-mode ) ??
Si en safe mode el Firefox es comporta correctament hauries d'anar activant/desactivant extensions fins que trobis quina provoca que el
consum es dispari.
En quant el tema de control de memòria per part del kernel ja has vist
en la teva cerca per Internet que tens diverses opcions disponibles
(ulimit, cgroups, ...). La funció de protecció que busques opino que
la compleix el OOM-killer (out-of-memory killer). Podeu veure com
funciona mirant el codi font [2]. Quan aquest procés s'activa registra
el que ha fet al dmesg. Si realment es va consumir tota la memòria
pots revisar quin o quins processos va matar el OOM-killer mirant els
logs.
[1] https://support.google.com/drive/answer/2494822?hl=en
[2] https://github.com/torvalds/linux/blob/master/mm/oom_kill.c#L195
Salutacions,
Jordi
--
El sáb, 2 oct 2021 a las 13:28, Àlex (<alex@probeta.net>) escribió:
Em crida molt l'atenció que Google Slides faci petar el navegador quan
es comparteix una presentació amb 100 persones.
No és tant quan 100 persones obren el document, com quan un d'ells fa
clic al botó d'iniciar reproducció.
Quan moltes persones tenen el document obert el sistema no tenía més que >> 1 Gb de RAM ocupada entre escriptori i navegador. És quan faig clic al
botó d'iniciar presentació qué de sobte demana tota la RAM i peta. Per
què? No ho sé.
Només ho he reproduit un parell de cops amb Ubuntu 18.04 + Firefox 92.0
No ho he provat amb Chromium . Tampoc ho he provat a Windows ni MacOS.
Fa uns dies que veig que els llocs de Google funcionen millor amb
Chromium que amb Firefox. Potser només passa amb Firefox.
Però de les tres preguntes que sorgeixen ...
(1) Per què passa això a Google Slides ?
(2) Per què els navegadors no controlen quan una pestanya es menja tota
la RAM del sistema per avisar l'usuari si la vol bloquejar ?
(3) Per què un sistema operatiu multiusuari no ve de sortida més
protegit per que el procés d'un usuari no es mengi tota la ram causan
una denegació de servei a la resta ?
... a llarg termini m'interessen més la pregunta (3) ó la (2) que la (1) >>
Hola Jordi,
sembla que això de oom_killer és una cosa que té múltiples
configuracions i que s'ha d'ajustar, però que té uns ajustos genèrics i
no veig gaire raonable per evitar el problema que comenta el company
[0], o estic equivocat.
també he trobat [1] (això ho trobo molt interessant Alex)
i independentment d'això, ja que has apuntat el codi font, si em pots
ajudar a entendre:
què vol dir literalment la variable adj: adjustment?
què vol dir literalment la mm: memory management?, ien aquest context [2] ?
Gràcies!
Pedro
[0]
https://www.percona.com/blog/2019/08/02/out-of-memory-killer-or-savior/ https://www.oracle.com/technical-resources/articles/it-infrastructure/dev-oom-killer.html
que ve de https://juantrucupei.wordpress.com/2017/04/03/desactivar-oom-killer-out-of-memory-killer/
[1] https://dev.to/msugakov/taking-firefox-memory-usage-under-control-on-linux-4b02
[2]
p = find_lock_task_mm(p);
if (!p)
return LONG_MIN;
On 10/2/21 3:02 PM, Jordi Miguel wrote:
Hola,
Sobre el tema del límit d'usuaris per les aplicacions de Google Drive (Docs, Sheets, Slides), Google diu el següent:
Share & collaborate on a file with more than 100 people
Up to 100 people with view, edit, or comment permissions can work on a Google Docs, Sheets, or Slides file at the same time. When more than
100 people are accessing a file, only the owner and some users with
editing permissions can edit the file.
Podeu veure la informació completa aquí[1] amb les solucions que
proposen per compartir amb més de 100 persones. Potser seria
interessant que ens comentessis com vas compartir aquesta presentació: quins permisos tenies tu sobre la presentació? els alumnes tenien el mateix enllaç i, per tant, permisos que tu? o l'enllaç dels alumnes només tenia permisos com a lector ?? Pots reproduir el problema si comparteixes la presentació de la manera que es proposa a la
documentació de Google ??
Sobre el motiu pel qual Firefox consumeix tota la memòria RAM, imagino
que tindràs extensions i/o temes carregats. El primer pas seria
intentar reproduir el mateix problema utilitzant el safe mode (e.g. # firefox --safe-mode ) ??
Si en safe mode el Firefox es comporta correctament hauries d'anar activant/desactivant extensions fins que trobis quina provoca que el
consum es dispari.
En quant el tema de control de memòria per part del kernel ja has vist
en la teva cerca per Internet que tens diverses opcions disponibles (ulimit, cgroups, ...). La funció de protecció que busques opino que
la compleix el OOM-killer (out-of-memory killer). Podeu veure com
funciona mirant el codi font [2]. Quan aquest procés s'activa registra
el que ha fet al dmesg. Si realment es va consumir tota la memòria
pots revisar quin o quins processos va matar el OOM-killer mirant els
logs.
[1] https://support.google.com/drive/answer/2494822?hl=en
[2] https://github.com/torvalds/linux/blob/master/mm/oom_kill.c#L195
Salutacions,
Jordi
--
El sáb, 2 oct 2021 a las 13:28, Àlex (<alex@probeta.net>) escribió:
Em crida molt l'atenció que Google Slides faci petar el navegador quan >>> es comparteix una presentació amb 100 persones.
No és tant quan 100 persones obren el document, com quan un d'ells fa
clic al botó d'iniciar reproducció.
Quan moltes persones tenen el document obert el sistema no tenía més que >> 1 Gb de RAM ocupada entre escriptori i navegador. És quan faig clic al
botó d'iniciar presentació qué de sobte demana tota la RAM i peta. Per >> què? No ho sé.
Només ho he reproduit un parell de cops amb Ubuntu 18.04 + Firefox 92.0 >>
No ho he provat amb Chromium . Tampoc ho he provat a Windows ni MacOS.
Fa uns dies que veig que els llocs de Google funcionen millor amb
Chromium que amb Firefox. Potser només passa amb Firefox.
Però de les tres preguntes que sorgeixen ...
(1) Per què passa això a Google Slides ?
(2) Per què els navegadors no controlen quan una pestanya es menja tota >> la RAM del sistema per avisar l'usuari si la vol bloquejar ?
(3) Per què un sistema operatiu multiusuari no ve de sortida més
protegit per que el procés d'un usuari no es mengi tota la ram causan
una denegació de servei a la resta ?
... a llarg termini m'interessen més la pregunta (3) ó la (2) que la (1) >>
[...]
Si estàs pensant que el oom-killer hauria d'haver matat el Firefox,
segons el que ens expliquen probablement hauria d'haver passat, però
també és possible que no s'hagués exhaurit tota la memòria sinó que
s'ha quedat a prop del límit però sense arribar-hi i per tant no s'ha arribat a cridar el oom-killer. En aquest escenari el Firefox
intentava funcionar amb la RAM+swap, lo qual és molt lent però es algo
que ha decidit l'usuari de la màquina.
Si ests pensant que el oom-killer hauria d'haver matat el Firefox,
segons el que ens expliquen probablement hauria d'haver passat, per
tamb s possible que no s'hagus exhaurit tota la memria sin que
s'ha quedat a prop del lmit per sense arribar-hi i per tant no s'ha
arribat a cridar el oom-killer. En aquest escenari el Firefox
intentava funcionar amb la RAM+swap, lo qual s molt lent per es algo
que ha decidit l'usuari de la mquina.
El problema és quan el sistema es queda sense memòria i comença a fer servir swap el funcionament es s'alenteix tant que el sistema queda inutilitzable, fins al punt que no és possible ni tan sols matar elDesviant-me una mica del tema i entenen que no hi ha una resposta
procés manualment. Suposo que si t'esperes suficientment l'oom-killer l'acabaria matant, però jo mai he tingut tanta paciència. Personalment
he optat per no tenir swap, per evitar aquestes situacions.
Salutacions.
Tot i que se m'escapa algun concepte trobo interessantíssim el que entenc.
El problema és quan el sistema es queda sense memòria i comença a fer
servir swap el funcionament es s'alenteix tant que el sistema queda
inutilitzable, fins al punt que no és possible ni tan sols matar el
procés manualment. Suposo que si t'esperes suficientment l'oom-killer
l'acabaria matant, però jo mai he tingut tanta paciència. Personalment
he optat per no tenir swap, per evitar aquestes situacions.
Salutacions.
Tot i que se m'escapa algun concepte trobo interessantíssim el que
entenc. Desviant-me una mica del tema i entenen que no hi ha una
resposta universal, com bé diu Eloy ni per a un mateix usuari, em
recomaneu per a ordinadors d'alumnes de cicles no posar swap?
A banda de que la swap vagi bé per a la hibernació, he pensat que el dia que decideixi no tenir-la trobaré un programa antic i important de
Murphy amb un if que m'enviarà a l'infern si no troba la swap. Però
potser són paranoies.
Vagi bé
Julio
El 3/10/21 a les 20:57, Julio Amorós ha escrit:
El problema és quan el sistema es queda sense memòria i comença a ferl'oom-killer
servir swap el funcionament es s'alenteix tant que el sistema queda
inutilitzable, fins al punt que no és possible ni tan sols matar el
procés manualment. Suposo que si t'esperes suficientment
l'acabaria matant, però jo mai he tingut tanta paciència.Personalment
he optat per no tenir swap, per evitar aquestes situacions.
Salutacions.
Tot i que se m'escapa algun concepte trobo interessantíssim el que
entenc. Desviant-me una mica del tema i entenen que no hi ha una
resposta universal, com bé diu Eloy ni per a un mateix usuari, em recomaneu per a ordinadors d'alumnes de cicles no posar swap?
A banda de que la swap vagi bé per a la hibernació, he pensat que el dia que decideixi no tenir-la trobaré un programa antic i important de
Murphy amb un if que m'enviarà a l'infern si no troba la swap. Però potser són paranoies.
Vagi bé
Julio
Cap programa no t'hauria de donar mai cap incidència pel fet de no tenir memòria d'intercanvi (Swap) a la unitat interna de l'ordinador. La
pràctica totalitat dels programes deleguen la gestió de memòria al nucli del sistema operatiu, que és el què gestiona la diferència entre memòria real (RAM) i memòria virtual (Swap), però ho presenta tot davant els programes com a «memòria».
Per tant, pots ometre perfectament l'ús d'espai d'intercanvi (swap) si
creus que amb la quantitat disponible de memòria RAM els programes n'han
de fer prou tots els dies.
Pel què fa a la hibernació: https://wiki.debian.org/Hibernation/Hibernate_Without_Swap_Partition
El què no sé és si es pot fer això sense utilitzar el fitxer com a «Swap».
--
__________
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator should fix this against automated addresses collectors.
Cap programa no t'hauria de donar mai cap incidència pel fet de no tenir
memòria d'intercanvi (Swap) a la unitat interna de l'ordinador. La
pràctica totalitat dels programes deleguen la gestió de memòria al nucli >> del sistema operatiu, que és el què gestiona la diferència entre memòria >> real (RAM) i memòria virtual (Swap), però ho presenta tot davant els
programes com a «memòria».
Per tant, pots ometre perfectament l'ús d'espai d'intercanvi (swap) si
creus que amb la quantitat disponible de memòria RAM els programes n'han
de fer prou tots els dies.
Pel què fa a la hibernació:
https://wiki.debian.org/Hibernation/Hibernate_Without_Swap_Partition
El què no sé és si es pot fer això sense utilitzar el fitxer com a «Swap».
Si poseu a /etc/sysctl.conf
vm.swappiness=0
els processos no usaran el swap però sí que es podrà usar per a la hibernació.
Font:
https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-debian-10
em recomaneu per a ordinadors d'alumnes de cicles no posar swap?
he pensat que el dia que decideixi no tenir-la trobaré un
programa antic i important de Murphy amb un if que m'enviarà
a l'infern si no troba la swap.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 76:35:51 |
| Calls: | 6,657 |
| Calls today: | 3 |
| Files: | 12,203 |
| Messages: | 5,332,734 |
| Posted today: | 1 |