qbittorrent no esta en mi root … es una carpeta , donde qbittorrent pondra los torrents acabados de bajar.
qbittorrent esta en su ruta , luego puedes configurarle cosas como donde trabajar los ficheros en bajada “temporales” , y donde moverlos cuando esten descargados …$HOME/Qbittorrent/Descargados , es mejorable, SI… :lol: , pero … no deja de trabajar “DENTRO DENTRO DENTRO” , de su carpeta y no en la “raiz” del HOME…y en ultimo …no deja de ser una opcion ,ya que soyyo , quien decide la configuracion de qbittorrent …y se puede ajustar …en un script eso no suele ser asi , las variables son definidas y no pueden cambiarse sin editar el script.
Joe , lo de las llaves estaba claro , como van a estar en texto plano hombre … pero no dejan de estar alli , si tienes una para el gestor de paquetes y la borras , pues la puedes crear otra vez, no es mucho drama, pero igual pierdes un rato en eso …y un usuario sin experiencia no va a saber ni que le pasa al gestor de paquetes
Las llaves que si estan en texto plano , son las de networkmanager , … algo que no entiendo , y no se si solo root puede ver esos ficheros … dependera de la distro , pero en mi caso…
/etc/NetworkManager/system-connections/
alli un txt por cada conexion , con todos los datos incluida la key … no se por que no se cifra , o soy yo muy nuub , recuedo que la primea vez me pregunto si usar kwallet, pero lo probe una vez y los ficheros estaban exactamente igual … :rolleyes:
La relación entre borrar un directorio escondido .gnupg y tener un fichero creado en root es de lo más retorcido
Y si un usuario no tiene idea de lo que esta haciendo la primera cosa que debe hacer es crear una cuenta de usuario corriente.
Hace todo lo que no se debería hacer y no usa lo más básico de los sistemas UNIX que es la separación de privilegios.
Este tipo de script (hostbase) no es para este tipo de publico.
Es más bien una herramienta de investigación.
Perdéis por completo de vista su objetivo inicial.
Lo digo sin menospreciar a nadie, todos somos el “Kidie” de alguien, pero este tool no es para “scriptkidismo”.
Y me considero como un script kiddie.
No controlo como debería itptbles, hotsapd, apache… No he investigado este tema como la ha hecho koala durante años.
Lo bueno de este script es que si tengo la intención de aprender me va a ser muy útil para guiarme y inspirarme
Y una vez que soy menos script kiddies empieza la diversión porque es un scrirpt que te ayuda a ahorrar tiempo para experimentar y probar cosas nuevas.
¿Para que tener un fluxion (o un linsetcelestial :D) más?
Dicho esto; sin más offtopic, Te entiendo/sigo al 100% cuando dices de usar otro directorio que root… No es el sitio para esto.
Las tengo en el mismo directorio y sera igual en todas las distribuciones.
Sería mejor de otra forma pero es así (con wpa_supplicant tampoco están cifradas).
Este punto ilustra perfectamente la importancia y lo fundamental que es la separación de los privilegios.
Es el único mecanismo de defensa que hay para estas contraseñas en caso de intrusión.
Desde una cuenta de usario es imposible abrirlos, copiarlos, lo que sea.
kcdtv@kalimuX0:/etc/NetworkManager/system-connections$ cat INGOPRINT
cat: INGOPRINT: Permiso denegado
kcdtv@kalimuX0:/etc/NetworkManager/system-connections$ cp INGOPRINT '/home/kcdtv/Escritorio/REAVER'
cp: no se puede abrir 'INGOPRINT' para lectura: Permiso denegado
kcdtv@kalimuX0:/etc/NetworkManager/system-connections$
Con la cuenta root es “buffet libre.”
El usuario de a pie tampoco sabra de primeras crear un usuario distinto , (sin tantos privilegios) , aunque una breve busqueda en google le hara la vida mas facil , pero samebos como acabara … cuando quiera usar tools que esten solo para root y no pueda…pues arrancara la cuenta root y al final dejara de usar la cuenta limitada.
No estoy 100% seguro , pero creo que los ejecutables en
/bin + /sbin
solo son accesibles para root
el usuario de a pie (con permisos) ,podria ejecutar
/usr/bin + /usr/sbin → ejecutables de sistema y aplicaciones
y por supuesto
/usr/local/bin + /usr/local/sbin → aqui van a para los ejecutables compilados por el usuario si no usa argumentos tipicos de empaquetado …como definir
–prefix=/usr
–libdir=/usr/lib
–sysconfdir=/etc
y cosas asi …mas de empaquetadores/administradores de sistema.
En cualquier caso el tema inicial esta mas que claro , tema usuarios limitados y demas es muy extenso :=)
El trabajo del que hablamos aqui solo puede ser usado por root , asi pues , esta bien hablar un poco de todo y ya esta…lo de usar el sistema con tal o cual ,ya va mas a cada uno , segun lo que hagas , ademas sabes bien de lo que hablo , si arrancas kali con una cuenta normal habra cosas que no podras ejecutar o tendras que estar todo el rato con sudo + poner tu pass … contando que estes en la lista sudoers y puedas ejecutar cosas :=)
Planteas mal la cosa.
Con una cuenta root compromertida se puedes hacer absolutamente todo hasta hacer que se queme a computadora jugando con firmwares kernel.
Con una cuenta de usuario comprometido no puedes hacer… casi una mierda. Queda muchísimo camino por recoger para obtener los privilegios de administrador.
Lo dices como si fuera anormal cuando es así en todas las distribuciones linux.
Es asi que vienen configuradas todas las distribuciones gran publico.
y para las distribuciones como arch y debian o seguro incluso slackware, es lo que te explican en la guia para principiante paso uno o dos.
Pasar por la cuenta root es un mal habito y punto y no se debe hacer en un sistema instalado si no es requerido
Pa’ esto está sudo
. No significa que tiene por pasar algo, pero si pasa algo es game over directo.
Sin hablar de une error humano o de un script que hace algo que no debería por estar mal montado.
Al deber entrar una contraseña te hace pensar en lo que estás haciendo y te permite rectificar el tiro en caso de errores…
Hace poco explicaban en un estudio que 90% de los ataques contra windows se podrían evitar si hubiera una contraseña para ejecutar tareas criticas como es el caso con Mac y linux.
El aspecto seguridad prevale y sobre la molestia que es entrar una contraseña…
Cuando entras sudo una vez en una consola no te hace falta entrar las contraseña cada vez, puedes configurar el tiempo que quieres para que siga activa.
Puedes usar sudo su y ni tendrás que entrar sudo.
La cosa es limitar los privilegios root a los procesos que lo necesitan y es el mejor concepto posible.
Lo normal es …o bien que haya por defecto 2 cuentas ya creadas la root + una tipo “invitado”…o bien que al instalar , tengas que crear tu usuario…
Lo que pasa que para segun que uso , es mejor directamente ir con la root , a lo mejor tengo un concepto distinto de todo esto , por que en mi caso , solo puedo trabajar como root , y muy pocas veces estube con un usuario limitado … en cuanto me empiezan a pedir la pass para todo me agovio , estamos de acuerdo que para usuarios noveles, lo mejor es ir con freno , pero … en mi caso , el sistema que desarrollo , se vuelve un agovio usarlo con invitado ,por que todas las guis , scripts y demas, usan por debajo tools del sistema y todo el rato con pass … por que crees que kali , cuando es modo live por defecto arranca con root … otra cosa es al instalarla a un hdd para el dia a dia …tal vez habria que acostumbrarse.
Porque es así con las live basadas en debian (u otro, arch, fedora etc…)
Sino haría falta antes del inicio de la sesión añadir una GUI para configurar unos credenciales…
Se hace en tail pero es una distribución hecha para estar utilizada en modo live de forma segura y para tu anonimato… El enfoque es completamente diferente y te oobliga a usar un sesión de usuario normal.
La cuenta en la mayoría de los instaladores gráficos se configura durante la instalación para que desde el primer arranque del sistema se entra en una sesión de usuario con contraseña.
O por lo menos se hace modificar la contraseña root y luego nada más entrar por primera vez en tu sistema tienes una advertencia diciendo que estás usando la cuenta root y debes crear una cuenta de usuario.
Kali es debian SID (rama “unstable” de debian) y el hecho que el modo live sea por defecto con privilegios de administrador no tiene nada que ver con no obligar el usuario a entrar una contraseña si vas a usar reaver o machanger.
Es que este es el objetivo primario. Específicamente en el caso de kali que está pensado antes de todo para una instalación en disco duro para “desarolló continuo”. Se cambia a menudo de kernel etc… Puedes descargar cada semana la imagen semanal si quieres y montarla pero es un rolló… .
Es lo mejor.
Ahora entiendo que tu caso es muy especifico y que cuando debes trabajar horas y horas seguidas compilando y probando es pesado.
También si se hace una sesión de hacking wifi rápida - sin estar conectado a la red y sin ponernos de repente a arreglar historias de sistema y jugar con ficheros cirticos - no importa.
Pero en cuanto nos conectamos a la red y empezamos a usar el navegador y hacer las cosas que se hacen en un PC… Hay que salir a la calle protegido con sudo
Echando un ojo a la guia de instalación oficial de slackware veo que es igual que en debian SID / Kali:
