En resumen: sí, estar en una cuenta con pocos privilegios lo ayuda a protegerse contra el malware, pero no lo hace inmune. Como cualquier medida de seguridad, ninguna cosa lo mantendrá al 100% seguro.

TL; DR: Se ejecuta en una cuenta de bajo privilegio (también conocido como " principio de privilegio mínimo ") debe ser parte de un desayuno equilibrado que también incluya buenas configuraciones de cortafuegos; herramientas para monitorear procesos, recursos del sistema, puertos abiertos, tráfico de red, etc., para detectar actividades sospechosas; una política para ejecutar solo ejecutables firmados, la configuración del mod de kernel seguro SELinux, mantener el sistema operativo y la aplicación actualizados con parches de seguridad, y otras cosas.

Tu pregunta es muy amplia para responder directamente. En su lugar, lo dividiré en varios casos según la configuración del sistema y lo que el atacante busca:

Caso # 1: computadora personal

Digamos que la computadora Linux en cuestión es mi computadora portátil personal. De hecho, uso esto como un sistema de usuario único y escribo sudo con bastante regularidad, por lo que se aplican todas las cosas que usted mencionó. Además, si el atacante intenta robar mi información personal, como números de tarjetas de crédito, documentos fiscales, etc., todo está en mi directorio de inicio, donde este usuario tiene acceso a él. Si es un ransomware y quiere cifrar mis archivos personales, lo mismo. Quieren instalar un proceso en segundo plano para hacer que mi computadora sea parte de una red de bots, que no necesita ningún permiso especial.

Caso # 2: Servidor, cuenta de administrador

El daño de obtener malware en la cuenta de un administrador es menor que en el caso del usuario final, ya que es probable que la cuenta de administrador no contenga datos valiosos. pero aún así, un atacante probablemente puede hacer algo de daño al tener un rastreador de paquetes dentro de la red, o al abrir un puerto que le permita realizar pruebas de lápiz desde dentro de la red. Aquí confiaría en la configuración de su firewall para protegerse contra algo de esto y, con suerte, notificarle la actividad sospechosa para que pueda limpiarla.

Si el administrador escribe sudo regularmente, entonces sí, probablemente estés en problemas.

Caso # 3: Servidor, cuenta no administradora

Imagine que el uso en cuestión es tomcat , un usuario con muy pocos privilegios que ejecuta las aplicaciones de servidor web. Este es el caso en el que la gente suele pensar cuando habla del " principio de privilegio mínimo ", y la introducción de malware en esta cuenta será El menos peligroso de los tres casos que he mencionado.

También considere que existen Escalación de privilegios para Linux que permitiría a un usuario con pocos privilegios eludir la seguridad del sistema operativo y volverse ellos mismos en la raíz. En términos generales, mantenerse al día con los parches de seguridad lo protege contra esto, pero los actores lo suficientemente ricos como para comprar exploits en el mercado negro sabrán sobre los exploits de día cero que no se conocen públicamente y que no han sido parcheados.

  

Siempre escuchamos ...

¿Nosotros? Yo no.

Instalar algún programa que no sea de confianza como usuario normal es una mala idea con Linux, igual que con Windows o Mac: este programa tiene acceso a todos sus datos y puede eliminar estos datos, enviarlos a otra persona, etc. Además, puede hacer capturas de pantalla, controlar otras aplicaciones que se ejecutan en la misma pantalla de X windows (incluso si se ejecutan como un usuario diferente), puede agarrar teclas (es decir, keylogger), ... Para obtener más información, consulte Linux Security Circus: en aislamiento de GUI .

Aparte de eso, regularmente tenemos errores de escalamiento de privilegios incluso en errores de Linux que pueden ser utilizados por un usuario sin privilegios para obtener permisos de nivel raíz o incluso de kernel.

Por lo tanto, no instale ningún programa que no sea de confianza en ningún tipo de sistema a menos que esté dispuesto a comprometer este sistema o los datos almacenados en él.

Este es un caso horrible de Security Theatre

  

Security Theatre es la práctica o creencia de algo que parece mejorar la seguridad, pero en realidad no le hace mucho daño.

Esta falsa creencia ha existido tanto tiempo como el siguiente rumor

  

Linux no tiene virus debido a su sistema de permisos

Eso es casi tan bueno como decir

  

No tengo un virus en mi computadora porque no veo nada parpadeando

Solo porque no lo veas, no significa que sea verdad. Cerrar los ojos no te protege del intruso.

En toda realidad, Linux, Mac OS, Windows, Android, Xbox, todo tiene vulnerabilidades que permitirían escalar a un nivel de control del sistema.

SIN EMBARGO solo porque el ataque no se incremente al nivel del sistema no significa que no sea EXTREMADAMENTE peligroso. ¡Estas aplicaciones con solo acceso de nivel de usuario aún pueden robar su información, registrar cada movimiento y retener sus datos para obtener un rescate! Todo sin NUNCA se escala, porque estos son los datos a los que tiene acceso como solo su usuario.

Estos hechos son verdaderos de CUALQUIER SO, independientemente del dispositivo. Si tiene acceso a la memoria, tiene acceso a la memoria. Eso significa que incluso si no puedes verlo, todavía tiene acceso a él.

La Buena Nueva

Debido a que usted es un usuario habitual, significa que el ataque no es ya en los privilegios de nivel raíz, lo que significa que el acceso al mismo está limitado al acceso de los usuarios, y ayuda a proteger a otros usuarios en el sistema. Por supuesto, esto no significa que la escalada no pueda ocurrir, simplemente significa que es mucho más difícil.

El sistema en sí está a salvo de las cuentas que no son equivalentes a la raíz, pero eso no ayuda mucho en un escritorio donde la mayoría de lo que le importa son sus propios datos, y se autentica regularmente para convertirse en root desde su cuenta .

Si alguien tiene una cuenta en un sistema multiusuario correctamente configurado, y no tiene los privilegios sudo o la contraseña de root, a continuación, si no hay errores en el software privilegiado, no hay nada que el usuario pueda hacer que pueda dar. El control de la máquina. Una cuenta de usuario que pueda haber instalado software malicioso debe considerarse un posible atacante por el resto del sistema.

En mi escritorio, agregué una cuenta sin privilegios a la que puedo sudo , pero no puede sudo a la raíz. A veces ejecuto un software en el que confío un poco, pero no del todo, bajo esa cuenta, especialmente. si utiliza redes.

En teoría, dado que le doy acceso a esa cuenta a mi servidor X, podría aumentar sus privilegios con ataques de simulación de portapapeles / pulsaciones de teclas. Está en el mismo grupo de Unix que mi cuenta regular, y estoy seguro de que no he eliminado completamente el permiso de escritura de grupo de algunos archivos importantes, pero hice chmod 0644 ~/.bash{rc,_profile} y algunos otros archivos importantes. Por lo tanto, es un obstáculo adicional que algunos programas maliciosos podrían no haber previsto.

La receta aquí, aunque no es para nada infalible, está incompleta o incorrecta.

La instalación de software no confiable en su cuenta sin privilegios es un desastre.

¿Instalarlo en una cuenta sin privilegios otra cuidadosamente preparada? Menos riesgoso, pero de ninguna manera garantiza que sea seguro.

Si:

• está seguro de que su sistema está configurado como un sistema multiusuario seguro (no hay bits aleatorios de acceso de escritura a los directorios del sistema, probablemente SE Linux completo)
• Crea una cuenta que no comparte grupos con su cuenta.
• Ha establecido cuidadosamente el acceso a todos sus datos para que sea algo así como 0770, sin acceso a 'otro' -

entonces usted está tan seguro como cualquier entorno que dependa de la seguridad multiusuario en un sistema Linux compartido. Sin embargo, esas balas representan bastante trabajo. ¿No sería más fácil arrancar un CD o una máquina virtual?

  

¿no es posible que un usuario de bajo nivel instale un script con un keylogger, por ejemplo, que espere una llamada su o sudo y tome el control del sistema desde allí?

No, y ya ha dado la respuesta, porque eso está "fuera del alcance de su permiso". Linux siempre ha sido un sistema multiusuario y (casi) todo lo que se puede implementar fuera del kernel se se implementa fuera del kernel y, por lo tanto, está sujeto a las restricciones del sistema de permisos.

Un usuario puede instalar / ejecutar código que destruye sus propios datos, pero la única forma de hacer un daño adicional es explotando una vulnerabilidad en la implementación.

Sí, si ese usuario tiene acceso 'su' o sudo, entonces es posible que el malware pueda cambiar la ruta para que apunte a su propio código en lugar de su / sudo y, por lo tanto, MITM la interacción. pero esto es un poco más difícil de hacer en la práctica, ya que su o sudo debería invocarse desde el árbol de procesos que ya contiene el malware en ejecución.