Impedire che tutti i comandi vengano definiti come alias

C'è un modo per impedire che tutti i comandi vengano definiti come alias?

Ad esempio un utente non dovrebbe essere in grado di definire rmo qualsiasi altro comando (comandi predefiniti di Ubuntu) come nome alias.

Non è possibile impedire a un utente di definire gli alias che preferisce. Ritenere:

1. Disabiliti gli alias in /etc/bash.bashrc. Lo abilitano ovunque abbiano scelto.
2. Elimina tutte le menzioni di alias in /etc/bash.bashrce tutte ~/.bashrce ~/.bash_aliasestramite uno script. Hanno messo i loro alias in un altro file e lo hanno sorgente.
3. Si esegue un comando PROMPT_COMMANDche disabilita determinati alias. Ridefiniscono o indefiniscono PROMPT_COMMAND.
4. Intrappoli DEBUGe definisci gli alias. Rimuovono la trappola.
5. Chown tutti i file provenienti dall'invocazione alla radice. Usano un altro file e lo generano manualmente come primo comando che eseguono.
6. È possibile disattivare i comandi incorporati unset, builtine enable; fare aliasuna funzione ; declare -rf aliasper impedire agli utenti di modificare la funzione; ed esporta la funzione. Funzionano /bin/bashcon --rcfilee --init-fileper avviare una nuova shell, dove i builtin sono ora abilitati.
7. ...

È possibile disabilitare gli alias al momento della compilazione, quindi spetta a te mantenere bash aggiornato e assicurarsi di non essere influenzato dal prossimo Shellshock. Ovviamente, gli utenti potrebbero costruire la propria bash.

TL; DR

L'unico modo per impedire a un utente di creare alias è fornire loro una shell che non supporti l'aliasing. Questo è generalmente un problema X / Y, in cui X è in realtà un modello di minaccia che dovrebbe essere risolto con controlli o architetture appropriate anziché cercare di risolvere il problema post-facto dopo che a un utente è stata assegnata una shell su un sistema condiviso.

Di seguito, fornisco una risposta tecnicamente corretta, nonché alcune indicazioni su quali problemi questo risolverà e non risolverà. Fornisco anche alcune indicazioni aggiuntive sui controlli alternativi.

Utilizzo di Bash Restricted Shell

È possibile utilizzare la shell con restrizioni di Bash assegnando rbash come shell di accesso dell'utente. Per esempio:

foo:x:2001:2001:restricted user:/home/foo:/bin/rbash

È quindi necessario disabilitare l' alias incorporato per l'utente, preferibilmente senza interrompere anche la shell di tutti gli altri. Ad esempio, è possibile aggiungere quanto segue a un file come /etc/profile.d/rbash.sh :

# Limit effect to users in a specific UID range.
if ((UID >= 2000)) && ((UID < 3000)); then
    # Check shell options; disable alias builtins when shell is restricted.
    if [[ $- =~ r ]]; then
        enable -n alias
        enable -n unalias
    fi
fi

Avvertenze

A meno che tu non abbia inserito l'utente in una prigione chroot o abbia fornito loro un PERCORSO modificato che non include l'accesso ad altre shell, non c'è nulla che impedisce all'utente di digitare semplicemente bashal prompt e ottenere una shell senza restrizioni.

Inoltre, in base alla progettazione, la shell con restrizioni impedisce molte attività comuni come cambiare directory:

$ cd /tmp
rbash: cd: restricted

ma non impedisce ad altri script o programmi nel PERCORSO di farlo. Questo significa che devi creare con cura l'ambiente dell'utente, e in particolare che devi impedire loro di poter modificare il PERCORSO nei loro file di avvio, perché anche se rbash rende PATH di sola lettura, lo fa dopo l' inizializzazione.

Scelte migliori

Anche se usi rbash, devi farlo come parte di un insieme più ampio di controlli. Alcuni esempi possono includere:

• Impedire agli utenti non tecnici di accidentalmente Richiamo dei comandi pericolosi, fornendo gli alias di default come rm -i, mv -ie cp -inel /etc/bash.bashrc di file.

  • Dato il tuo esempio originale, questa è probabilmente la soluzione più sensata.
  • Puoi combinare questo con enable -n aliasse vuoi.
  • Ciò non impedisce agli utenti esperti di modificare gli alias, ma può essere sufficiente per impedire agli utenti non tecnici di fare qualsiasi cosa di cui ti preoccupi.

• Autorizzazioni Unix tradizionali o ACL POSIX per proteggere file e directory.

• Login che eseguono un singolo comando non interattivo. Per esempio:

  foo:x:2001:2001:run foo.sh:/home/foo:/usr/local/bin/foo.sh

• Utilizzare i comandi forzati SSH per tasto. Per esempio:

  # ~foo/.ssh/authorized_keys
  command="/usr/local/bin/foo.sh" [remainder of line]

• Usa l' opzione OpenSSH ForceCommand con un blocco Match condizionale.

• Usa strumenti speciali come gitolite o scponly progettati per il tuo caso d'uso specifico.

• Usa una prigione chroot .

• Utilizzare la virtualizzazione come Xen, OpenVZ, LXC, VMware, VirtualBox o altre tecnologie per fornire un ambiente separato.

Dopo aver definito con precisione il modello di minaccia, è possibile identificare i controlli più appropriati per il proprio caso d'uso. Senza una comprensione più significativa del motivo per cui si desidera impedire l'aliasing (ad es. Quale problema del mondo reale risolve?) Non è possibile selezionare i controlli più appropriati.

Questo è uno sforzo abbastanza inutile, come mostra la risposta di Muru. Ma ci sono alcune opzioni, ma non sono perfette.

Secondo il bashmanuale, le funzioni hanno sempre la precedenza sugli alias, quindi potremmo fare quanto segue:

xieerqi@eagle:~$ function alias { echo "Aliases are no-no" ; }
xieerqi@eagle:~$ alias TEST='rm'
Aliases are no-no

È possibile inserire la definizione della funzione in tutto il sistema .bashrc, tuttavia, come ha sottolineato Muru, gli utenti intelligenti troveranno il modo di ottenere gli alias acquistando un bashrcfile diverso , ad esempio.

Un'altra idea con cui ho giocato è enableintegrata. aliasè una shell integrata e bashha un bel enablecomando che consente di abilitare o disabilitare i builtin. Ad esempio, ecco che sto disabilitando alias.

xieerqi@eagle:~$ enable -n alias
xieerqi@eagle:~$ alias
No command 'alias' found, did you mean:
 Command '0alias' from package 'zeroinstall-injector' (universe)
alias: command not found
xieerqi@eagle:~$ alias TEST='rm'
No command 'alias' found, did you mean:
 Command '0alias' from package 'zeroinstall-injector' (universe)
alias: command not found
xieerqi@eagle:~$ enable alias
xieerqi@eagle:~$ alias
alias egrep='egrep --color=auto'
alias fgrep='fgrep --color=auto'
alias grep='grep --color=auto'
alias l='ls -CF'
alias la='ls -A'
alias ll='ls -alF'
alias ls='ls --color=auto'
xieerqi@eagle:~$ 

Ancora una volta, l'utilizzo di tutto il sistema bashrcè un'opzione qui.

È possibile definire (in /etc/profile) una funzione chiamata aliasche esegue la convalida desiderata (probabilmente utilizzando type -p) (dopo che tutti i "comandi predefiniti di Ubuntu" sono "eseguibili in $PATH") prima di chiamare l'integrato alias, MA, come altri hanno sottolineato, gli utenti potrebbero ottenere intorno a quello. Perché non ottenere un diverso gruppo di utenti o istruirli ("Definire un aliascomando che ignora un comando è un ottimo modo per spararsi nel piede e creare confusione (ad esempio, perché lsrichiede la mia password?))?