Bloquer une commande particulière sous Linux pour un utilisateur spécifique


27

Comment bloquer la commande, disons mkdirpour un utilisateur spécifique?

Ce que je viens de créer une fonction en lecture seule et de stocker dans le profil des utilisateurs ~/.bashrc

/bin/mkdir() {
        echo "mkdir command not allow for you"

}

mkdir() {
        echo "mkdir command not allow for you"

}
./mkdir() {

        echo "mkdir command not allow for you"
}

readonly -f /bin/mkdir
readonly -f mkdir
readonly -f ./mkdir

Tester:

rahul@ubuntu:~$ cd /bin/
rahul@ubuntu:/bin$ ./mkdir /home/rahul/ggg
mkdir command not allow for you
rahul@ubuntu:/bin$ cd
rahul@ubuntu:~$ mkdir testing
mkdir command not allow for you
rahul@ubuntu:~$ /bin/mkdir testing
mkdir command not allow for you

Ma question est donc quelle devrait être la manière d'y parvenir? existe-t-il un outil pour cela?

Update 1 # Mais si l'utilisateur est intelligent, il pourrait copier le binaire mkdir et le renommer et l'utiliser. Alors, comment y parvenir?


7
Votre exemple échouera car l'utilisateur pourrait compiler le sien mkdiret le renommer, ou même simplement copier et renommer le binaire existant. En outre, il existe un shell intégré pour remplacer les alias et les fonctions.
strugee

hmm c'est correct, donc y a-t-il quand même?
Rahul Patil

l'utilisateur n'a pas non plus besoin de compiler, il peut facilement le copier cp /bin/mkdir mkdir2puis l'utiliser :(
Rahul Patil

La création d'un répertoire est une tâche si courante / fondamentale qu'il existe plusieurs façons de le faire, et il serait presque impossible de les bloquer tous (sauf en ne permettant pas à l'utilisateur de créer des fichiers, c'est-à-dire en protégeant tous les répertoires contre lui). Par exemple, cp -r /usr/local/lib gggva créer un répertoire appelé ggg(contenant une copie du contenu de /usr/local/lib, le cas échéant, que l'utilisateur peut ensuite simplement supprimer). Vous pouvez utiliser find / -type d -emptypour rechercher un répertoire vide à copier.
G-Man dit `` Réinstalle Monica ''

Réponses:


21

Je ne sais pas comment faire avec bash, mais je connais un autre shell qui restreint l'environnement utilisateur: lshell (shell limité) .

Un aperçu rapide de la configuration

Lshell est configuré via un fichier INI. Par défaut, il contient une liste blanche de commandes autorisées, mais il peut être facilement configuré pour interdire à l'utilisateur d'utiliser une commande spécifique.

Cette configuration (conf par défaut /etc/lshell.conf) interdit à l'utilisateur food'utiliser mkdir:

[foo]
allowed = 'all' - ['mkdir', 'bash', 'sh', 'csh', 'dash', 'env']

Afin de configurer un compte d'utilisateur pour utiliser lshell par défaut, vous devez:

 chsh -s /usr/bin/lshell foo

Lshell peut faire plus, comme:

  • 3 niveaux de granularité: utilisateur, groupe, tout.
  • Peut restreindre l'accès à certains chemins du système.
  • Peut restreindre l'utilisation de certains caractères (comme |).
  • Peut restreindre l'utilisation de certaines commandes uniquement via SSH.

Et plus.

Mise à jour 1 # Résultat de test ajouté:

rahul:~$ which bash
/bin/bash
rahul:~$ dd if=$(which bash) of=my_bash
*** forbidden syntax: dd if=$(which bash) of=my_bash
rahul:~$ bash
*** forbidden command: bash
rahul:~$ cp /bin/bash my_bash
*** forbidden path: /bin/bash
rahul:~$ /bin/bash
*** forbidden command: /bin/bash
rahul:~$ sh
*** forbidden command: sh
rahul:~$ dash
*** forbidden command: dash
rahul:~$ env bash
*** forbidden command: env
rahul:~$ cp /bin/mkdir mycreatedir
*** forbidden path: /bin/mkdir

3
avec allowed = 'all' - ['mkdir'], ne pouvez-vous pas simplement exécuter bashet être à nouveau libre?
dawud

3
Juste être pédant, désolé, mais il y a encore beaucoup de façons de contourner les restrictions imposées par cette liste, par exemple dd if=$(which bash) of=my_bash && chmod u+x my_bash && ./my_bash. Je pense que le problème est l'absence d'une politique par défaut restrictive, c'est-à-dire que dans ce scénario, vous accordez des autorisations par défaut, puis REFUSEZ les autorisations en fonction d'une liste, alors que cela devrait être l'inverse: REFUSER par défaut, puis GRANT en fonction de la politique .
dawud

1
@dawud: Je suis d'accord que maintenir une liste blanche de commandes autorisées est une meilleure approche que d'avoir une liste noire et espérer que l'utilisateur ne la contournera pas en surpassant l'administrateur.
rahmu

2
@Marco, vérifiez l'exemple fourni dans ma réponse. Je fournis une liste blanche de commandes autorisées, et dans ce scénario, l'utilisateur ne peut pas simplement cpun binaire à son PATH ( rootrépertoire appartenant, rxpour l'utilisateur), et rbashempêche l'exécution ./executables. Répond-il à votre question?
dawud

2
@dawud C'est vrai. J'ai raté le répertoire bin en lecture seule.
Marco

15

La façon dont j'implémente habituellement ce type de restrictions nécessite que plusieurs conditions soient remplies, sinon la restriction peut être facilement contournée:

  • L'utilisateur n'appartient pas au wheelgroupe, le seul autorisé à utiliser su(appliqué via PAM).
  • L'utilisateur reçoit un rbashchemin d'accès correctement sécurisé avec un chemin en lecture seule pointant vers un privé ~/bin, ce ~/bin/répertoire contient des liens vers des utilitaires simples:

    $ ll ~/bin
    total 0
    lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 clear -> /usr/bin/clear*
    lrwxrwxrwx. 1 root dawud  7 Sep 17 08:58 df -> /bin/df*
    lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 egrep -> /bin/egrep*
    lrwxrwxrwx. 1 root dawud  8 Sep 17 08:58 env -> /bin/env*
    lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 fgrep -> /bin/fgrep*
    lrwxrwxrwx. 1 root dawud  9 Sep 17 08:58 grep -> /bin/grep*
    lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 rview -> /bin/rview*
    lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 rvim -> /usr/bin/rvim*
    lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 sudo -> /usr/bin/sudo*
    lrwxrwxrwx. 1 root dawud 17 Sep 17 08:58 sudoedit -> /usr/bin/sudoedit*
    lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 tail -> /usr/bin/tail*
    lrwxrwxrwx. 1 root dawud 11 Sep 17 08:58 wc -> /usr/bin/wc*
    
  • l'utilisateur reçoit un environnement restreint, en lecture seule (penser à des choses comme LESSSECURE, TMOUT, HISTFILEvariables).

  • l'utilisateur est mappé à l'utilisateur SELinux staff_uet a le droit d'exécuter des commandes en tant qu'autre utilisateur selon les besoins via sudo.
  • l'utilisateur /home, /tmpet /var/tmpsont éventuellement polyinstanciés via /etc/security/namespace.conf:

    /tmp       /tmp/.inst/tmp.inst-$USER-     tmpdir:create   root
    /var/tmp   /tmp/.inst/var-tmp.inst-$USER- tmpdir:create   root
    $HOME      $HOME/$USER.inst/              tmpdir:create   root
    

    En outre, /etc/security/namespace.initrend tous les fichiers squelettiques en lecture seule pour l'utilisateur et appartient à root.

De cette façon, vous pouvez choisir d' $USERexécuter mkdiren son propre nom (via un lien dans le ~/binrépertoire privé , fourni via /etc/skel, comme expliqué ci-dessus), au nom d'un autre utilisateur (via sudo) ou aucun.


4

Ajoutez un groupe factice, ajoutez l'utilisateur à ce groupe chown root:somegroup /bin/mkdir,, chmod g-x /bin/mkdir. Notez que cela repose sur le fait que l'utilisateur ne peut pas modifier ses groupes. IIRC c'est vrai dans GNU / Linux mais pas dans certains autres Unices.


2
Sur la plupart des systèmes de fichiers, vous pouvez également utiliser des listes de contrôle d'accès étendues pour un contrôle plus fin - le nombre de groupes nécessaires augmenterait exponentiellement avec le nombre d'utilisateurs (en raison de combinaisons possibles), sans parler des problèmes de dénomination.
peterph

2
ajouter un point de plus, supprimer également l'autorisation de lecture des autres utilisateurs 710, afin que l'utilisateur ne puisse pas copier et renommer ce binaire n'est-ce pas?
Rahul Patil

1
@RahulPatil oui, et bien sûr, vous devez également restreindre leur utilisation d'un compilateur.
peterph

1

Le meilleur que j'ai testé est d'utiliser Profile.d de la manière la plus sûre et la plus sûre

Étape # 1 (créer un fichier d'alias)

[root@newrbe ~]# vim /etc/customalias.sh

Ajouter des lignes ci-dessous:

alias rm="echo remove contenet is restricted"
alias poweroff="echo Poweroff is restricted"
alias chmod="echo Change Permission is restristed"

Enregistrer et quitter

Étape # 2 (Créer un chargeur de profil)

/etc/profile.d/ cet emplacement contient des fichiers pour l'achèvement de bash

[root@newrbe ~]# vim /etc/profile.d/customsource.sh

Ajouter des lignes ci-dessous sous les fichiers ces lignes bloqueront les commandes mentionnées pour les utilisateurs ci-dessous

if [ `whoami` == "user1" ] && [ `whoami` == "user2" ]; then
    source /etc/customalias.sh
fi

sauvegarder et quitter

Maintenant, quittez et reconnectez-vous

Cordialement, -Mansur


/etc/profile.d/n'est pas pour l' bashachèvement , c'est où placer les personnalisations de session de connexion pour les utilisateurs utilisant des shells de connexion de type POSIX, donc ce n'est généralement pas où les bashpersonnalisations d'alias (qui préfèrent entrer /etc/bash.bashrc) iraient et il devrait avoir une syntaxe de shell POSIX (donc généralement, à la .place de sourceet =au lieu de ==).
Stéphane Chazelas

-1

installez sudoers et essayez de configurer là dont les utilisateurs et quelle commande.


4
Bienvenue chez SX. Veuillez ajouter des détails à votre réponse; le PO, ou toute autre personne lisant cette question à l'avenir, peut ne pas être au courant sudo.
Joseph R.

Cette réponse est tout simplement fausse
kiltek
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.