¿Qué quieres decir exactamente? ¿Estás buscando algo así como un "bloque suave" para evitar que lo hagas accidentalmente?
kos
44
No estoy seguro de qué sentido tiene hacerlo, incluso si fuera posible.
Muru
44
¿Cuál sería la lógica para esto? No evita que un usuario escriba el comando real ... ¿así que no veo ninguna razón para que alguien necesite bloquear alias?
Rinzwind el
2
Como muru y Rinzwind dijeron, ¿qué sentido tiene? Los alias no pueden hacer cosas más desagradables que las cosas que un usuario ya puede hacer, bloquear los alias solo hace que la vida del usuario sea más difícil. Además, sea cual sea la solución (p. Ej., Usar un alias / función para anular el incorporado), no puedo pensar en una forma de que los propios usuarios no puedan evitarlo, a menos que los bloqueen ~/.bashrc.
kos
No bloquea todos los alias, solo evita que no use el nombre de comando predeterminado como nombre de alias. Sé que podemos escapar de los alias de muchas maneras, como usar \ con el mismo comando con alias para ejecutar el comando real. Eso es todo
αғsнιη
Respuestas:
24
No hay forma de evitar que un usuario defina los alias que prefiera. Considerar:
Deshabilita los alias en /etc/bash.bashrc. Lo habilitan donde lo elijan.
Elimina todas las menciones de alias en /etc/bash.bashrc, y todo ~/.bashrcy a ~/.bash_aliasestravés de un script. Ponen sus alias en otro archivo y lo obtienen.
Ejecutas un comando en PROMPT_COMMANDque deshabilita ciertos alias. Redefinen o indefinen PROMPT_COMMAND.
Atrapa DEBUGy no define alias. Quitan la trampa.
Usted chown todos los archivos originados en la invocación a la raíz. Usan otro archivo y lo obtienen manualmente como el primer comando que ejecutan.
Deshabilita las órdenes internas unset, builtiny enable; hacer aliasuna función ; declare -rf aliaspara evitar que los usuarios modifiquen la función; y exportar la función. Se ejecutan /bin/bashcon --rcfiley --init-filepara iniciar un nuevo shell, donde dichas incorporaciones ahora están habilitadas.
...
Puede deshabilitar los alias en el momento de la compilación, entonces dependerá de usted mantener actualizado el bash y asegurarse de que no se vea afectado por el próximo Shellshock. Por supuesto, los usuarios podrían construir su propio bash.
Sin embargo, tuve una idea un poco divertida: puedes alias alias: =)
Rinzwind
44
Y ellos unalias alias.
Muru
44
@muru seguro, pero también puedes alias unalias: +
Rinzwind
8
@Rinzwind y corren \unalias unalias.
Muru
10
TL; DR
La única forma de evitar que un usuario cree alias es proporcionarle un shell que no sea compatible con alias. Este es generalmente un problema X / Y, donde X es realmente un modelo de amenaza que debe resolverse con controles o arquitecturas apropiadas en lugar de tratar de resolver el problema post facto después de que un usuario recibe un shell en un sistema compartido.
A continuación, proporciono una respuesta técnicamente correcta, así como una guía sobre qué problemas resolverá y no resolverá. También proporciono alguna orientación adicional sobre controles alternativos.
Uso del shell restringido de Bash
Puede usar el shell restringido de Bash asignando rbash como el shell de inicio de sesión del usuario. Por ejemplo:
Luego debe deshabilitar el alias integrado para el usuario, preferiblemente sin romper el shell de todos los demás. Como ejemplo, puede agregar lo siguiente a un archivo como /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 unaliasfifi
Advertencias
A menos que haya colocado al usuario en una cárcel chroot o le haya proporcionado una RUTA modificada que no incluya el acceso a otros shells, no hay nada que impida que el usuario simplemente escriba bashen el indicador y obtenga un shell sin restricciones.
Además, por diseño, el shell restringido evita muchas actividades comunes, como cambiar directorios:
$ cd /tmp
rbash: cd: restricted
pero no impide que otros scripts o programas en PATH lo hagan. Esto significa que debe crear cuidadosamente el entorno del usuario, y específicamente que debe evitar que puedan modificar la RUTA en sus archivos de inicio, porque aunque rbash hace que la RUTA sea de solo lectura, lo hace después de la inicialización.
Mejores opciones
Incluso si usa rbash, debe hacerlo como parte de un conjunto más amplio de controles. Algunos ejemplos pueden incluir:
Evitar que los usuarios no técnicos de forma accidental que invocan los comandos peligrosas por proporcionar alias predeterminados, tales como rm -i, mv -iy cp -ien el /etc/bash.bashrc archivo.
Dado su ejemplo original, esta es probablemente la solución más sensata.
Puedes combinar esto enable -n aliassi quieres.
Esto no evitará que los usuarios expertos cambien los alias, pero puede ser suficiente para evitar que los usuarios no técnicos hagan lo que sea que le preocupe.
Permisos Unix tradicionales o ACL POSIX para proteger archivos y directorios.
Inicios de sesión que realizan un solo comando no interactivo. Por ejemplo:
Utilice la virtualización como Xen, OpenVZ, LXC, VMware, VirtualBox u otras tecnologías para proporcionar un entorno segregado.
Una vez que haya definido con precisión su modelo de amenaza, puede identificar los controles más apropiados para su caso de uso. Sin una comprensión más significativa de por qué desea evitar el aliasing (por ejemplo, ¿qué problema del mundo real resuelve?) No puede seleccionar los controles más apropiados.
+1 en general, pero también específicamente para clasificar esto como un problema X / Y.
Joe
5
Este es un esfuerzo bastante inútil, como lo muestra la respuesta de muru. Pero hay algunas opciones, pero no son perfectas.
Según el bashmanual, las funciones siempre tienen prioridad sobre los alias, por lo que podríamos hacer lo siguiente:
xieerqi@eagle:~$ function alias { echo "Aliases are no-no";}
xieerqi@eagle:~$ alias TEST='rm'Aliases are no-no
Podría colocar la definición de función en todo el sistema .bashrc, sin embargo, como señaló Muru, los usuarios inteligentes encontrarán la forma de obtener alias al obtener un bashrcarchivo diferente , por ejemplo.
Otra idea con la que he jugado es enableincorporada.
aliases un shell integrado y bashtiene un enablecomando agradable que permite habilitar o deshabilitar los builtins. Por ejemplo, aquí estoy yo deshabilitándome alias.
xieerqi@eagle:~$ enable -n alias
xieerqi@eagle:~$ aliasNo 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:~$
Nuevamente, usar todo el sistema bashrces una opción aquí.
No bloquea todos los alias, solo los comandos integrados, no el alias en sí :)
αғsнιη
@ Afshin.Hamedi Bueno, ¿qué es un comando predeterminado? ¿El que viene con ubuntu? Eso significa que tendría que tener una lista de todos los comandos (archivos binarios) que venían con la instalación predeterminada. Luego, cada vez que el usuario carga el shell o intenta alias algo rm, verifica la lista. Teniendo en cuenta que las listas serían bastante grandes, tomaría mucho tiempo comenzar, sus usuarios se quejarán mucho y lo odiarán como administrador del sistema :)
Sergiy Kolodyazhnyy
Es una pregunta divertida e increíble que tienes, ¡me gusta! El alias selectivo sería bueno. Pero dudo que sea posible, a menos que los desarrolladores de shell encuentren la necesidad de implementarlo :)
Sergiy Kolodyazhnyy
La idea de la función fue agradable. Se acercó más.
Muru
0
Usted podría definir (en /etc/profile) una función llamada aliasque realiza la validación desea (probablemente usando type -p) (después de todos los "comandos por defecto de Ubuntu" son "ejecutables en $PATH") antes de llamar a la orden interna alias, pero, como otros tienen cabo en punta, los usuarios podrían obtener Alrededor de eso. ¿Por qué no obtener un conjunto diferente de usuarios o educarlos ("Definir un aliascomando que anula un comando es una muy buena manera de dispararse en el pie y causar confusión (por ejemplo, ¿por qué lssolicita mi contraseña?))?
~/.bashrc
.Respuestas:
No hay forma de evitar que un usuario defina los alias que prefiera. Considerar:
/etc/bash.bashrc
. Lo habilitan donde lo elijan./etc/bash.bashrc
, y todo~/.bashrc
y a~/.bash_aliases
través de un script. Ponen sus alias en otro archivo y lo obtienen.PROMPT_COMMAND
que deshabilita ciertos alias. Redefinen o indefinenPROMPT_COMMAND
.DEBUG
y no define alias. Quitan la trampa.unset
,builtin
yenable
; haceralias
una función ;declare -rf alias
para evitar que los usuarios modifiquen la función; y exportar la función. Se ejecutan/bin/bash
con--rcfile
y--init-file
para iniciar un nuevo shell, donde dichas incorporaciones ahora están habilitadas.Puede deshabilitar los alias en el momento de la compilación, entonces dependerá de usted mantener actualizado el bash y asegurarse de que no se vea afectado por el próximo Shellshock. Por supuesto, los usuarios podrían construir su propio bash.
fuente
unalias alias
.\unalias unalias
.TL; DR
La única forma de evitar que un usuario cree alias es proporcionarle un shell que no sea compatible con alias. Este es generalmente un problema X / Y, donde X es realmente un modelo de amenaza que debe resolverse con controles o arquitecturas apropiadas en lugar de tratar de resolver el problema post facto después de que un usuario recibe un shell en un sistema compartido.
A continuación, proporciono una respuesta técnicamente correcta, así como una guía sobre qué problemas resolverá y no resolverá. También proporciono alguna orientación adicional sobre controles alternativos.
Uso del shell restringido de Bash
Puede usar el shell restringido de Bash asignando rbash como el shell de inicio de sesión del usuario. Por ejemplo:
Luego debe deshabilitar el alias integrado para el usuario, preferiblemente sin romper el shell de todos los demás. Como ejemplo, puede agregar lo siguiente a un archivo como /etc/profile.d/rbash.sh :
Advertencias
A menos que haya colocado al usuario en una cárcel chroot o le haya proporcionado una RUTA modificada que no incluya el acceso a otros shells, no hay nada que impida que el usuario simplemente escriba
bash
en el indicador y obtenga un shell sin restricciones.Además, por diseño, el shell restringido evita muchas actividades comunes, como cambiar directorios:
pero no impide que otros scripts o programas en PATH lo hagan. Esto significa que debe crear cuidadosamente el entorno del usuario, y específicamente que debe evitar que puedan modificar la RUTA en sus archivos de inicio, porque aunque rbash hace que la RUTA sea de solo lectura, lo hace después de la inicialización.
Mejores opciones
Incluso si usa rbash, debe hacerlo como parte de un conjunto más amplio de controles. Algunos ejemplos pueden incluir:
Evitar que los usuarios no técnicos de forma accidental que invocan los comandos peligrosas por proporcionar alias predeterminados, tales como
rm -i
,mv -i
ycp -i
en el /etc/bash.bashrc archivo.enable -n alias
si quieres.Permisos Unix tradicionales o ACL POSIX para proteger archivos y directorios.
Inicios de sesión que realizan un solo comando no interactivo. Por ejemplo:
Utilice comandos forzados SSH por tecla. Por ejemplo:
Use la opción OpenSSH ForceCommand con un bloque Match condicional.
Use herramientas especiales como gitolita o scponly diseñadas para su caso de uso específico.
Usa una cárcel chroot .
Utilice la virtualización como Xen, OpenVZ, LXC, VMware, VirtualBox u otras tecnologías para proporcionar un entorno segregado.
Una vez que haya definido con precisión su modelo de amenaza, puede identificar los controles más apropiados para su caso de uso. Sin una comprensión más significativa de por qué desea evitar el aliasing (por ejemplo, ¿qué problema del mundo real resuelve?) No puede seleccionar los controles más apropiados.
fuente
Este es un esfuerzo bastante inútil, como lo muestra la respuesta de muru. Pero hay algunas opciones, pero no son perfectas.
Según el
bash
manual, las funciones siempre tienen prioridad sobre los alias, por lo que podríamos hacer lo siguiente:Podría colocar la definición de función en todo el sistema
.bashrc
, sin embargo, como señaló Muru, los usuarios inteligentes encontrarán la forma de obtener alias al obtener unbashrc
archivo diferente , por ejemplo.Otra idea con la que he jugado es
enable
incorporada.alias
es un shell integrado ybash
tiene unenable
comando agradable que permite habilitar o deshabilitar los builtins. Por ejemplo, aquí estoy yo deshabilitándomealias
.Nuevamente, usar todo el sistema
bashrc
es una opción aquí.fuente
rm
, verifica la lista. Teniendo en cuenta que las listas serían bastante grandes, tomaría mucho tiempo comenzar, sus usuarios se quejarán mucho y lo odiarán como administrador del sistema :)Usted podría definir (en
/etc/profile
) una función llamadaalias
que realiza la validación desea (probablemente usandotype -p
) (después de todos los "comandos por defecto de Ubuntu" son "ejecutables en$PATH
") antes de llamar a la orden internaalias
, pero, como otros tienen cabo en punta, los usuarios podrían obtener Alrededor de eso. ¿Por qué no obtener un conjunto diferente de usuarios o educarlos ("Definir unalias
comando que anula un comando es una muy buena manera de dispararse en el pie y causar confusión (por ejemplo, ¿por quéls
solicita mi contraseña?))?fuente