Necesito ejecutar algunos comandos con sudo. Estos comandos se encuentran en .bashrco ~/biny se almacenan en un repositorio git (es decir, archivos de puntos).
He colocado enlaces simbólicos que ~rootapuntan a mi usuario $HOME, pero creo que no es bueno desde el punto de vista de la seguridad, así que los eliminé.
Mi preocupación es que si unsin raizSi el usuario tiene permisos de escritura para estos archivos, un programa malicioso podría lograr realizar una escalada de privilegios. Sin embargo, en mi libro encuentro muchos repositorios de archivos de puntos que no son seguros.
En .bashrclos comandos sudopoderContinúe /etc/sudoerscon NOPASSWD. En bin/*.shlos scripts, estaba pensando en omitir sudo de los comandos y asignarlos al root, pero esto puede ser un problema ya que git no almacena la propiedad. (Casi) todos los comandos individuales requieren sudo de todos modos, así que supongo que técnicamente es lo mismo, excepto que asignar scripts a la raíz debería ser más seguro. Git causaría algunos problemas, supongo.
Una idea: si concediera todos los comandos /etc/sudoerscon NOPASSWD, si se solicitara la contraseña de root, olería que algo andaba mal.
Información adicional:
- Esto es para un par de máquinas locales de un solo usuario;
- El acceso no autorizado a mi computadora de escritorio no es un problema, por lo que configuré el inicio de sesión automático;
- Mi computadora portátil requiere una contraseña para iniciar una sesión.
Si la pregunta aún no está clara, pregunto: ¿cómo puedo organizar estos scripts/comandos de forma segura? ¿Podría la escalada de privilegios con root ser más dañina que un programa malicioso en los datos de mi propio usuario? ¿Quizás simplemente lo estoy pensando demasiado?
Respuesta1
Un script que se puede escribir puede ser reemplazado por algo nefasto mientras no estás mirando, y si root lo ejecuta, se acabó el juego.
Es cierto que si usted es el único usuario de la máquina, el riesgo es bajo. Pero a menudo es más fácil descifrar la cuenta de un usuario normal (leer correos electrónicos con malware, conectarse a un sitio web malicioso, compilar y ejecutar de cualquier manera una fuente aleatoria "para ver qué hace",...), y esto permitir escalar al privilegio de root.
Respuesta2
Teniendo en cuenta todas las opciones que conocía ( /usr/local/bin, raíz del propietario, eliminación del permiso de escritura), opté por el indicador inmutable en cada archivo versionado:
sudo chattr +i filename
Los usuarios que no sean root, ni siquiera el propietario, no pueden restablecer la bandera. Tampoco se puede eliminar ni reemplazar el archivo ni el directorio principal.
Para editar el archivo, agregué la siguiente función a .bashrc:
editrc () {
sudo chattr -i $1
nano $1
sudo chattr +i $1
}
En otras computadoras tengo que extraer los archivos de puntos, la bandera debe eliminarse antes git pully luego volver a aplicarse. Se creó una función auxiliar que toma la bandera como argumento.
protect-config () {
FLAG=$1
FILES=$(git ls-files | xargs -I @ -- find @ -type f | xargs echo)
lsattr $FILES
if [ "$FLAG" ]; then
sudo chattr $FLAG $FILES
fi
}
Dicho esto, sí, lo estoy pensando demasiado. Aún así, ya está vigente. Principalmente por buena costumbre.
EDITAR: Ya no uso esto, ya que era más inconveniente que la sensación de seguridad que agregaba.