Repositorio "fantasma" aparece sin estar presente en sources.list [Solucionado]
Muy buenas.
¿Esto es mosqueante o me estoy volviendo paranoico? Veréis, hace una semana instalé Google Chrome para ver si era verdad que va tan ligero y tal. Lo instlé bajándome el paquete .deb de la web de Google y la instalación fue la típica dpkg -i. No recuerdo que hiciese nada más ni que se me preguntara nada.
Lo que me mosquea bastante es que hoy al ir a actualizar, entre los repositorios desde los que aptitude ha empezado a bajar las listas de paquetes se encontraba dl.google.com, y entre los paquetes a actualizar, Google Chrome. He revisado mi sources.list y no hay ningún repositorio maś que los que yo he añadido; ni rastro de ningún repo en un servidor de Google. ¿Cómo es posible que haya aparecido ese repo pasando olímpicamente de mi sources.list? ¿Es un agujero (gordísimo) de seguridad, un abuso absoluto por parte de Google (usando un agujero de seguridad, obviamente) o tal vez en la letra pequeña de las condiciones de instalación de Chrome, esas que nadie lee, viene explicada la historia? Aún tratándose de lo último me seguiría pareciéndome un "socavón" de seguridad que un programa cualquiera pueda decidir añadir nuevos repositorios pasando de la configuración que tenga hecha el usuario.
Saludos.
- Inicie sesión o regístrese para enviar comentarios
- 966 lecturas


Revisa dentro de
/etc/apt/sources.list.d/... me parece recordar que en las condiciones de uso se indica que se configurará el sistema para que Chrome se actualice automáticamente aún cuando tú lo hayas descargado y no hayas modificado el sources.listSaludos,
Sidd.
Efectivamente es como dices, Siddharta: en /etc/apt/sources.list.d hay un "bonito regalo" de Chrome llamado google-chrome.list que apunta al repositorio de marras. Algún día deberé empezar a leerme los terminos y condiciones de los programas que instale... Qué fatiga me da sólo de pensarlo, jeje.
No se me había ocurrido mirar dentro de /etc/apt/sources.list.d; pensaba que ese directorio era para programas de terceros que el usuario conscientemente quisiera agregar para no embarullar el sources.list, no que cualquier programa pudiera meter ahí lo que le diese la gana...
Además es extraño que parece que Chrome debe de haberme instalado por su cuenta la clave para su repositorio, porque yo no he instalado ninguna ni cuando he accedido a actualizar Chrome me ha salido ningún aviso de que el paquete estuviera sin firmar.
La madre que trajo a los de Google... cada día se toman más libertades con los usuarios de sus productos :-/.
En fin, muchas gracias por tu tranquilizadora aclaración, y espero que este hilo sirva si alguien más se lleva un "susto" como el mío, aunque no me gusta nada esa permisividad de Debian.
Saludos.
No es permisividad de Debian... el solo hace aquello que tu le mandas. Has instalado chrome que modifica esos archivos, cuando instalas lo haces como root y logicamente tienes control total del sistema... y puedes hacer con el lo que quieras, por lo tanto es permisividad del usuario.
Y una última cosa... estas instalando cosas fuera de los repositorios oficiales, si te mantienes en estos no te pasan estas cosas.
Saludos
PD: Hace tiempo aparecio un tema de gnome en gnome-look.org que instalaba un script no deseado, ese es el riesgo de confiar en repositorios y/o software de teceros.
Ya encontré lo que buscaba, está en la página de descarga de Google Chrome, arriba del botón Accept and Install:
Note: Installing Google Chrome will add the Google repository so your system will automatically keep Google Chrome up to date. If you don't want Google's repository, do "sudo touch /etc/default/google-chrome" before installing the package
http://www.google.com/chrome/eula.html
Saludos,
Sidd.
Opera también tiene esta bonita costumbre, por si alguien se lo pregunta.
Yo creo que ese es el precio que hay que pagar por la facilidad de uso:
Que el sistema hace lo que quiere y sin dar explicaciones de ningún tipo.
Después vienen los problemas y a ti se te pone cara de tonto porque no
sabes qué cojones pasa.
Aunque pienso que el asunto "facilidad" es algo bastante subjetivo,
este tipo de mierd.s son más bien... ¿comodidad?
Es el viejo axioma informático: seguridad vs. comodidad o como el aumento de una acaba afectando a la otra.
Qué bien! ¿para qué preguntar la usuario durante la instalación? Menudos zorros están hechos...
En fin, lo que yo decía, a partir de ahora va a tocar leerse todos los "EULAs" y similares...
Gracias de nuevo y saludos.
EDITO
Creo que me he equivocado al publicar. Esto iba como respuesta al mensaje de Sidd.
Hombre, pero yo no le he mandado que me hurge en /etc/apt/sources.list.d; quiero decir que el permiso del usuario a un instalador no significa carta blanca para hacer lo que le dé la gana, o no debería significarlo; no sé si me explico. Los directorios en los que se guardan los archivos binarios, las bibliotecas, enlaces... en fin, lo necesario para que funcionen los programas, ya sean directorios predefinidos o indicados conscientemente por el usuario, deberían ser los únicos en los que un instalador pudiera escribir; tampoco debería poder autorizar tal o cual repositorio, y mucho menos instalar las firmas que autorizan cualquier paquete que provenga de ese repositorio, y todo ello sin intervención del usuario, simplemente por una cláusula en las condiciones de uso que Google es perfectamente consciente de que nadie lee.
Que yo sepa /etc/apt/sources.list.d es exclusivo de Debian y sus derivados (corregidme si estoy equivocado, que no niego que pueda estarlo); un desarrollador puede escribir guiones de instalación que hagan cualquier cosa, pero el SO no debería permitirlo. A eso me refería con lo de la permisividad; en Gentoo no pasa, y creo que en Arch tampoco (tengo poca experiencia con Arch, la verdad, quizá me equivoque).
Es que si no, ¿qué será lo próximo, que tal programa no sólo me meta un repositorio "de estrangis", su firma, y luego me haga un "aptitude install loquesea", proque yo lo he ejecutado como root ergo le he dado permiso para hacerse con el control de mi máquina?
Sé que no conviene recurrir a repositorios no oficiales, es una norma recomendabilísima que sigo a rajatabla salvo con unos pocos programas que no están en los repositorios, como Chrome, Firefox 3.6 y un par más, pero en este caso no estamos hablando de cualquier fuente, sino de Google, o, como dice otro compañero forista, también de Ópera en su caso, que se supone que deberían ser fiables (la vida no para de sorprender, jeje), y evidentemente mi "problema" es una trivialidad segruamente hecha con buena intención para facilitar la actualización de Chrome, lo malo es que si se permite esa intromisión de un programa qué otras cosas se están permitiendo, o se podrían permitir, que quizá n osean tan visibles ni inocuas?.
En mi opinión hay dos problemas:
1) Google se toma unas libertades que no debería (el Virtualbox de Sun no lo hace; si uno quiere actualizar tiene que agregar los repos a mano o bajarse los .deb de las versiones nuevas). Eso es ajeno a Linux, pero Debian y Ubuntu podrían presionar para que esa desagradable constumbre desapareciera (y si ocurre en más distros pues también).
2) La arquitectura de Debian lo permite. En mi opinión debería o bloquear que un programa que ha sido lanzado por un guión de instalación acceda a directorios "delicados" que nada tienen que ver con una simple instalación o bien que avise al usuario de la acción que el instalador en cuestión está intentando llevar a cabo y que pida autorización. Esta me parece mucho más importante que mi primera objeción porque no dpendería de que tal o cual desarrollador fuese ético. Para hacer lo que le dé la gana con mi ordenador ya está Windows.
Sí, me enteré de lo de gnome-look, auqnue creo recordar que afectaba, y sigue afectando, tanto a Gnome como a KDE. Los ficheros .desktop pueden ser un arma de doble filo.
Yo no trasteo mucho con guiones para el escritorio, pero seamos sinceros: en Debian no está práticamente nada de lo que hay al menos en kde-look; a quien quiera algo de ahí no le queda más remedio que bajárselos "extrarrepositorialmente". Algunas cosas de los repos de Ubuntu funcionan sin "dar por saco", plasmoides, guiones, etc, pero siempre va a haber una gran cantidad que no va a haber sido revisada por nadie.
Supongo que como dicen otros foristas todo esto es el precio a pagar por la comodidad, pero no sé, esas vulnerabilidades quizá no fuesen tan difíciles de solventar, o sí, si la gente del equipo de seguridad de Debian no ha hecho nada al respecto quizá es que no es tan fácil (hablo desde la ignorancia absoluta en el campo de la ingeniería de sofware).
En todo caso una cosa me queda clara: sean mejorables ciertos aspectos de Debian o no, mi conclusión es que, en la medida de lo posible, NUNCA instalar software de empresas privadas, por mucho que se anuncien bajo la bandera del software libre; lo malo es que algunos de sus productos funcionan mucho mejor que los hechos por la comunidad y a veces no queda otra que rendirse...
jaja.
Como alguien me diga ahora que GNU, Mozilla, KDE, Gnome, etc, hacen cosas parecidas me da algo,
Saludos y bien finde a tod@s.
Me encanta tu avatar. Amén.
Vamos a trollear un rato:
Hombre, pero yo no le he mandado que me hurge en /etc/apt/sources.list.d; quiero decir que el permiso del usuario a un instalador no significa carta blanca para hacer lo que le dé la gana, o no debería significarlo
No es lo que le dé la gana. Es lo que has autorizado en la EULA (Condiciones de Uso). ¿Que éticamente es repugnante? Cierto. Pero es lo que has aceptado en la instalación, y mucho me temo que el concepto de "cláusula abusiva" no llegue a estos extremos.
Que yo sepa /etc/apt/sources.list.d es exclusivo de Debian y sus derivados (corregidme si estoy equivocado, que no niego que pueda estarlo); un desarrollador puede escribir guiones de instalación que hagan cualquier cosa, pero el SO no debería permitirlo. A eso me refería con lo de la permisividad; en Gentoo no pasa, y creo que en Arch tampoco (tengo poca experiencia con Arch, la verdad, quizá me equivoque).
Con permisos de superusuario, puede pasar perfectamente con URPMIS, con EMERGEs y con PACMANs. Es decir, con cualquier sistema que maneje repositorios. Supongo que con Slackware quizá lo tuviera algo más complicado.
De hecho, apostaría un menú de 10 euros en la nacional-232 (café incluido) a que el binario de instalación también mete mano en los directorios de las distros que manejan RPMs. Con las demás ya tengo mis dudas, más que nada porque no son tan frecuentes.
pero en este caso no estamos hablando de cualquier fuente, sino de Google
La gran G ya acumula un amplio historial de invasiones en la privacidad de sus usuarios, algunas conspiranoicas y otras muy reales. Así que yo, personalmente, la pongo a un nivel de confianza similar al de Microsoft (y aquí es donde en algunos sitios muy tolerantes los Gfanboys me fundirían a negativos).
2) La arquitectura de Debian lo permite. En mi opinión debería o bloquear que un programa que ha sido lanzado por un guión de instalación acceda a directorios "delicados" que nada tienen que ver con una simple instalación o bien que avise al usuario de la acción que el instalador en cuestión está intentando llevar a cabo y que pida autorización. Esta me parece mucho más importante que mi primera objeción porque no dpendería de que tal o cual desarrollador fuese ético. Para hacer lo que le dé la gana con mi ordenador ya está Windows.
# chmod 444 /etc/apt/sources.list.d
O incluso programar un script que sustituya al comando dpkg, que retire permisos de ciertos directorios mientras se instala el paquete (se supone que externo a los repositorios) y, finalizado el proceso, los vuelva a restaurar.
Y aquí ya sería tirarme un farol, pero creo que con SELinux se podría aplicar una política de seguridad mucho más estricta. Una política que todo el que tire de repositorios no oficiales y tenga las mismas inquietudes que tú (totalmente legítimas), debería comenzar a estudiar.