È possibile consentire ad alcuni utenti particolari (ad es. Membri di un gruppo) di montare qualsiasi filesystem senza i privilegi di superutente su Linux?
Un'altra domanda potrebbe essere stata "in che modo un utente può danneggiare un sistema montando filesystem?"
Risposte:
Ci sono un paio di approcci, alcuni per lo più sicuri, altri per niente.
Lascia correre qualsiasi uso mount, ad esempio, tramite sudo. Potresti anche dare loro radice; è la stessa cosa. L'utente può montare un filesystem con una copia root suid di bash—running che fornisce immediatamente root (probabilmente senza alcuna registrazione, oltre al fatto che è mountstato eseguito).
In alternativa, un utente può montare il proprio filesystem sopra /etc, contenente la propria copia di /etc/shadowo /etc/sudoers, quindi ottenere root con suo sudo. O eventualmente bind-mount ( mount --bind) su uno di quei due file. O un nuovo file in /etc/sudoers.d.
Attacchi simili potrebbero essere respinti in /etc/pam.dmolti altri luoghi.
Ricorda che i filesystem non devono nemmeno essere su un dispositivo, -o loopmonteranno un file di proprietà (e quindi modificabile) dell'utente.
I vari ambienti desktop hanno già creato soluzioni per questo, per consentire agli utenti di montare supporti rimovibili. Funzionano montando in una sottodirectory di /mediasolo e disattivando il supporto set-user / group-id tramite le opzioni del kernel. Opzioni qui includono udisks, udisks2, pmount, usbmount,
Se è necessario, potresti scrivere il tuo script per fare qualcosa di simile e invocarlo tramite sudo, ma devi stare molto attento a scrivere questo script per non lasciare exploit root. Se non vuoi che i tuoi utenti debbano ricordare sudo, puoi fare qualcosa del genere in uno script:
#!/bin/bash
if [ $UID -ne 0 ]; then # or `id -u`
exec sudo -- "$0" "$@"
fi
# rest of script goes here
Gli spazi dei nomi di Linux sono una forma di virtualizzazione molto leggera (contenitori, per essere più specifici). In particolare, con gli spazi dei nomi utente, qualsiasi utente sul sistema può creare il proprio ambiente in cui è root. Ciò consentirebbe loro di montare filesystem, ad eccezione del fatto che è stato esplicitamente bloccato, ad eccezione di alcuni filesystem virtuali. Alla fine, i file system FUSE saranno probabilmente consentiti, ma le patch più recenti che ho trovato non coprono i dispositivi a blocchi, ma solo cose come sshfs.
Inoltre, molti kernel di distro hanno (per motivi di sicurezza) il default di non consentire agli utenti non privilegiati di usare spazi dei nomi utente; per esempio Debian ha un kernel.unprivileged_userns_clonevalore predefinito di 0. Altre distribuzioni hanno impostazioni simili, sebbene spesso con nomi leggermente diversi.
La migliore documentazione che conosco sugli spazi dei nomi utente è un articolo LWN Spazi dei nomi in funzione, parte 5: Spazi dei nomi utente .
Per ora, andrei con udisks2.
mountdi poter montare filesystem come fa root? Leggerò il documento degli spazi dei nomi che hai collegato e proverò a implementare questa cosa del gruppo di montaggio, almeno come esercizio.
Puoi farlo, ma devi modificare la voce /etc/fstabcorrispondente al filesystem che vuoi montare, aggiungendo il flag usera questa voce. Gli utenti senza privilegi sarebbero quindi in grado di montarlo.
Vedi man mountper maggiori dettagli.
vfs.usermount). Voglio sth. analogo a quello. Uso molte unità rimovibili con molte partizioni su ciascuna e sarebbe ingombrante aggiungere una dozzina o due voci a fstab per ognuna di esse.
udevgestione delle voci man mano che i nuovi dispositivi appaiono e scompaiono.
Qui è il wiki per la configurazione polkit regole per udisks / udisks2 per montare le partizioni di non-root (ad esempio gli utenti) di gruppo.
Salvare il codice seguente in /etc/polkit-1/rules.d/50-udisks.rules
polkit.addRule(function(action, subject) {
var YES = polkit.Result.YES;
var permission = {
// only required for udisks1:
"org.freedesktop.udisks.filesystem-mount": YES,
"org.freedesktop.udisks.filesystem-mount-system-internal": YES,
"org.freedesktop.udisks.luks-unlock": YES,
"org.freedesktop.udisks.drive-eject": YES,
"org.freedesktop.udisks.drive-detach": YES,
// only required for udisks2:
"org.freedesktop.udisks2.filesystem-mount": YES,
"org.freedesktop.udisks2.filesystem-mount-system": YES,
"org.freedesktop.udisks2.encrypted-unlock": YES,
"org.freedesktop.udisks2.eject-media": YES,
"org.freedesktop.udisks2.power-off-drive": YES,
// required for udisks2 if using udiskie from another seat (e.g. systemd):
"org.freedesktop.udisks2.filesystem-mount-other-seat": YES,
"org.freedesktop.udisks2.encrypted-unlock-other-seat": YES,
"org.freedesktop.udisks2.eject-media-other-seat": YES,
"org.freedesktop.udisks2.power-off-drive-other-seat": YES
};
if (subject.isInGroup("users")) {
return permission[action.id];
}
});
Supponiamo di essere nel gruppo "utenti", usando il comando seguente per montare una partizione (non c'è bisogno di sudo).
# udisks2
udisksctl mount --block-device /dev/sda1
# udisks
udisks --mount /dev/sda1
Su Xubuntu funziona subito per montare ed espellere memoria di massa USB, partizioni del disco rigido, CD / DVD e probabilmente altro.
Supponiamo che la soluzione scelta da Ubuntu, usando policyKit, sia abbastanza sicura.
Su XFCE su Debian 8.3 dovevo consentire all'utente di montare ed espellere filesystem da thunar senza password. Ciò che ha funzionato per me è scegliere un file di autorizzazione da Ubuntu.
L'aggiunta delle righe seguenti come root a un file denominato /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkladovrebbe fare il trucco:
[Mounting, checking, etc. of internal drives]
Identity=unix-group:admin;unix-group:sudo
Action=org.freedesktop.udisks.filesystem-*;org.freedesktop.udisks.drive-ata-smart*;org.freedesktop.udisks2.filesystem-mount-system;org.freedesktop.udisks2.encrypted-unlock-system;org.freedesktop.udisks2.filesystem-fstab;
ResultActive=yes
(Quello che ho effettivamente fatto è stato scegliere un po 'di più dal file con lo stesso nome su Ubuntu 16.04 e ha funzionato per me. Se ne hai bisogno, per lo più sembra il contenuto di https://gist.github.com/kafene/5b4aa4ebbd9229fa2e73 )
È possibile configurare sudoper consentire a un set di utenti di eseguire il mountcomando.
Aggiornamento : su come si può danneggiare un sistema montando? Ad esempio, è possibile creare una shell root setuid su un filesystem che è quindi possibile montare ed eseguire per ottenere i privilegi di root.
sudo? Inoltre, non è l'utente root che monta il file system, solo dietro le quinte, con questo metodo?
mountper sudo mounto utilizzare uno script wrapper.
usera fstab funziona solo perché mountè setuid root. Il kernel sta verificando la presenza di root o CAP_SYS_ADMINfunzionalità, quindi non si può davvero aggirare coinvolgendo root.
Per rispondere alla tua domanda tra parentesi, poiché un filesystem è un segnaposto per i file, un utente può potenzialmente eseguire operazioni dannose su quel filesystem, come eliminare i file.
Riassumendo le altre 2 domande, dirò questo:
fstabè grande per montaggio ad avvio tempo permanente stoccaggio. Non è eccezionale quando si desidera collegare unità USB o montare occasionalmente alcune condivisioni di rete.
sudo mountva bene anche se usi sistemi ubuntu *. Sarà comunque necessario digitare una password.
udev si occuperà di montare cose come chiavette USB, fotocamere e schede flash nei sistemi ubuntu * (ma non in distro meno user friendly come debian, slackware, ecc.)
Aggiungerò che, storicamente, il modo unix per autorizzare alcuni utenti (o gruppi) a fare cose è attraverso il sudoersfile.
Ci sono MOLTE guide per usarlo là fuori, quindi non suggerirò alcun particolare. Dirò che ho usato il sito web del progetto di documentazione Linux per conoscerlo.
Inoltre, è sudoerspossibile montare dispositivi e condivisioni in modo trasparente, anche senza fornire una password se si sceglie di farlo (prestare particolare attenzione).
Quello che faccio di solito in un ambiente di controllo è l'uso del sudoersfile per consentire agli utenti di un determinato gruppo di montare le condivisioni di rete in modo trasparente. Quindi aggiungo i comandi mount.nfse mount.cifsnel file sudoers che consentono operazioni come "montare la cartella home dell'utente da un file server di rete, quando l'utente accede a un terminale client" e studiare in questo modo.
autofsda solo per montare il /home/$USERdal file server, alla posizione /home/$USER/fromFS/sul PC client.
guestmount inganno libguestfs
sudo apt-get install libguestfs-tools
# Workarounds for Ubuntu 18.04 bugs.
# https://serverfault.com/questions/246835/convert-directory-to-qemu-kvm-virtual-disk-image/916697#916697
sudo rm -rf /var/cache/.guestfs-*
echo dash | sudo tee /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/zz-dash-packages
sudo chmod +r /boot/vmlinuz-*
# Create a test image.
mkdir sysroot
dd if=/dev/urandom of=sysroot/myfile bs=1024 count=1024
virt-make-fs --format=raw --type=ext2 sysroot sysroot.ext2
# Mount it, have fun, unmount!
mkdir -p mnt
# /dev/sda becuase we have a raw filesystem.
guestmount -a sysroot.ext2.qcow2 -m /dev/sda mnt
cmp sysroot/myfile mnt/myfile
guestunmount mnt
Si affida a:
Documenti: http://libguestfs.org/guestmount.1.html
Testato su Ubuntu 18.04, libguestfs-tools 1: 1.36.13-1ubuntu3.
gvfs-mount-d /dev/sdX