Impedisci al programma di passare all'utente senza password

...su -c ... theuser asks for teuser's password which is strange,...

Non c'è nulla di strano in questo, ma questo è esattamente come dovrebbe funzionare su . Potrebbe essere utile rendersi più familiari con i concetti alla base di su e sudo e in che modo differiscono. In breve: su consente all'utente A di eseguire un comando come utente B a condizione che l'utente A possa anche autenticarsi come utente B. In questo caso A può eseguire qualsiasi cosa come B perché A può essere effettivamente B. sudo invece consente all'utente A per eseguire solo i comandi specifici nel contesto / permessi dell'utente B, che ha come root esplicitamente consentito A per essere eseguito in questo contesto. Pertanto l'autenticazione richiede l'utilizzo di A per assicurarsi che questo sia l'utente a cui è consentito eseguire questo specifico comando come B.

Is it safe to assume that it also cannot switch to theuser (without my explicit confirmation), even though it does not have a password set?

No, non è sicuro assumere.
su ha bisogno della password di B e se non ci sono password impostate in modo efficace non puoi accedere come B (nota che nessuna password impostata è diversa da una password vuota impostata) . Ma, sudo richiede solo un'autenticazione corretta di A, che l'utente ha. Se le autorizzazioni sudo sono impostate su un valore troppo ampio, A potrebbe essere in grado di uscire da un comando consentito per eseguire altro codice.
Un esempio classico per questo caso è quando A è consentito con sudo per modificare un file specifico con vi come utente B. Tuttavia, è possibile eseguire comandi esterni arbitrari da vi . Ciò significa che una volta che A sta eseguendo vi nel contesto / permessi di B, può anche eseguire qualsiasi altro comando dalla sessione dell'editor e questi funzioneranno anche come B.

A parte questo ci potrebbero essere altri vettori di attacco che permettono l'escalation dei privilegi per A. In passato c'erano abbastanza errori nel kernel di Linux o nella configurazione del sistema che permetteva tali attacchi. Pertanto, se non stai utilizzando un sistema che è ancora supportato e tienilo sempre aggiornato, ci sono buone probabilità che il tuo sistema sia influenzato da tali bug di sicurezza.

Puoi controllare /etc/shadow per vedere se la password è veramente vuota. passwd -d theuser imposterà l'hash come vuoto mentre passwd -l theuser bloccherà l'account impostando l'hash su ! . Di default la maggior parte delle distribuzioni sono configurate per non consentire l'accesso con una password vuota, ma alcune specificano nullok o nullok_secure per pam_unix.so , che consente l'accesso con una password vuota.

Poiché non è possibile accedere, l'account è bloccato o le password vuote non sono consentite. Per sicurezza, sarebbe meglio bloccarlo.