Evita que el programa cambie de usuario sin contraseña

  

... su -c ... theuser solicita la contraseña del usuario que es extraña, ...

No hay nada extraño en esto, pero así es exactamente cómo se supone que funciona su . Podría ser útil familiarizarse con los conceptos detrás de su y sudo y en qué se diferencian. En resumen: su permite que el usuario A ejecute un comando como usuario B, siempre que el usuario A también pueda autenticarse como usuario B. En este caso, A puede ejecutar cualquier cosa como B porque A puede ser realmente B. sudo en cambio permite al usuario A para ejecutar solo los comandos específicos en el contexto / permisos del usuario B, cuya raíz permitió explícitamente que A se ejecutara en este contexto. Por lo tanto, la autenticación solicita el uso A para asegurarse de que este es el usuario al que se le permite ejecutar este comando específico como B.

  

¿Es seguro asumir que tampoco puede cambiar al usuario (sin mi confirmación explícita), aunque no tenga una contraseña establecida?

No, no es seguro asumirlo.
su necesita la contraseña de B y, si no hay un conjunto de contraseñas, no puede iniciar sesión como B (tenga en cuenta que no hay un conjunto de contraseñas diferente de un conjunto de contraseñas vacío) . Pero, sudo solo necesita una autenticación exitosa de A, que el usuario tiene. Si los permisos sudo se configuran demasiado amplios, A podría ser capaz de romper un comando permitido para ejecutar otro código.
Un ejemplo clásico para este caso es cuando A se permite con sudo para editar un archivo específico con vi como usuario B. Sin embargo, es posible ejecutar comandos externos arbitrarios desde dentro de vi . Esto significa que una vez que A ejecuta vi dentro del contexto / permisos de B, también puede ejecutar cualquier otro comando desde la sesión del editor y estos también se ejecutarán como B.

Aparte de eso, podría haber otros vectores de ataque que permitan una escalada de privilegios para A. En el pasado hubo suficientes errores en el kernel de Linux o en la configuración del sistema que permitieron tales ataques. Por lo tanto, si no está ejecutando un sistema que aún es compatible y lo mantiene siempre actualizado, existe una gran posibilidad de que su sistema se vea afectado por estos errores de seguridad.

Puede verificar /etc/shadow para ver si la contraseña está realmente vacía. passwd -d theuser establecerá el hash como vacío, mientras que passwd -l theuser bloqueará la cuenta configurando el hash en ! . De manera predeterminada, la mayoría de las distribuciones están configuradas para no permitir el inicio de sesión con una contraseña vacía, pero algunas especifican nullok o nullok_secure para pam_unix.so , lo que permite iniciar sesión con una contraseña vacía.

Dado que no puede iniciar sesión, la cuenta está bloqueada o las contraseñas vacías no están permitidas. Para estar seguro, lo mejor es bloquearlo.