Quelle est la manière la plus sécurisée d'autoriser un utilisateur à accéder en lecture à un fichier journal?

21

Mon application nécessite un accès en lecture à /var/log/messages, qui appartient à l'utilisateur et au groupe root. Quel est le niveau d'exposition minimal requis pour /var/log/messagesque mon application puisse le lire?

Actuellement, mon plan est de changer la propriété du groupe /var/log/messagesen un nouveau groupe, et d'y ajouter root et mon utilisateur d'application, mais cela donnerait également des privilèges d'écriture à l'application /var/log/messages.

Système d'exploitation: Centos 5.5

— gAMBOOKa
source

7

Pas besoin d'ajouter root au groupe car il aura accès via les privilèges de l'utilisateur de toute façon, donnez simplement au groupe la lecture de ce que vous décidez. N'oubliez pas d'effectuer également les modifications avec logrotate, sinon les modifications de groupe seront effacées tous les soirs.

— rfelsburg
source

Où se trouvent les scripts logrotate?

— gAMBOOKa

1

/etc/logrotate.d/ est le dossier des scripts logrotate éclatés. / var / log / messages se trouve dans /etc/logrotate.d/syslog. Vous devrez déplacer / var / log / messages vers son propre fichier dans /etc/logrotate.conf, puis en utilisant quelque chose comme 'create 0640 root new_group' lui dire de créer le fichier correctement.

— rfelsburg

Vous devez déplacer / var / log / messages vers son propre fichier dans /etc/logrotate.d/

— Massimo

17

Juste pour développer un peu les réponses ci-dessus, voici un cas d'utilisation réel. J'exécute l'application d'analyse de journal d'entreprise Splunk sur une boîte Redhat. Il s'exécute sous l'utilisateur splunk et le groupe splunk. Cela empêche Splunk d'accéder aux journaux dans / var / log car ils ne sont accessibles que par root (ou un administrateur sudo)

Afin d'autoriser l'accès en lecture seule pour Splunk uniquement, j'ai utilisé des ACL et modifié logrotate pour le conserver.

Vous pouvez définir manuellement l'ACL avec

sudo setfacl -m g:splunk:rx /var/log/messages

Cela ne persistera pas car logrotate ne réappliquera pas le paramètre ACL, donc pour une solution plus permanente, j'ai ajouté une règle à logrotate pour réinitialiser l'ACL. J'ai ajouté le fichier ..

/etc/logrotate.d/Splunk_ACLs

avec

{
    postrotate
        /usr/bin/setfacl -m g:splunk:rx /var/log/cron
        /usr/bin/setfacl -m g:splunk:rx /var/log/maillog
        /usr/bin/setfacl -m g:splunk:rx /var/log/messages
        /usr/bin/setfacl -m g:splunk:rx /var/log/secure
        /usr/bin/setfacl -m g:splunk:rx /var/log/spooler
    endscript
}

Vérifiez l'état ACL d'un fichier avec

$ getfacl /var/log/messages

Pour plus d'informations sur les ACL, voir https://help.ubuntu.com/community/FilePermissionsACLs http://bencane.com/2012/05/27/acl-using-access-control-lists-on-linux/

— Nick Fox
source

également posté sur splunk answers answers.splunk.com/answers/4253/…

— nick fox

1

Notez que splunk ne nécessite pas d'autorisation d'exécution sur les fichiers journaux, lisez simplement.

— rojs

@nickfox Est-ce tout le contenu de ce /etc/logrotate.d/Splunk_ACLsque vous avez publié là-bas? Vous n'avez en fait pas besoin de spécifier de chemin pour que logrotate traite le bit postrotate?

— Dale Anderson

hmmm Ne pense pas. Je ne voulais pas modifier les configurations logrotate existantes pour les journaux système et je ne voulais pas non plus les remplacer par les miennes. De cette façon, la modification personnalisée pour splunk existe indépendamment. Vous permettre de déployer avec un package ou une marionnette, etc. c'est à cela que servent les répertoires /app.d/. Bien sûr, je peux me tromper, cela fait plus d'un an que j'ai fait ça

— nick fox

1

Juste une note suggérant que si vous utilisez l'option X (comme dans X majuscule plutôt que x), elle ajoutera exécution uniquement si le fichier est un répertoire ou a déjà la permission d'exécution pour certains utilisateurs

— steoleary

5

Votre plan est acceptable et dans le schéma d'autorisations Unix "traditionnel" est la meilleure façon de procéder.
Une autre option consiste à demander à syslog de détourner les messages d'intérêt vers un autre fichier (ce qui évite de donner à l'utilisateur de l'application l'accès à tout ce qui peut être sensible /var/log/messages).

Si vous n'avez pas envie d'être lié par le schéma d'autorisations traditionnel de l'utilisateur / groupe / autre, vous pouvez également utiliser les listes de contrôle d'accès POSIX (autre, peut-être de meilleurs conseils / informations disponibles via Google) pour donner à l'utilisateur de votre application un accès en lecture seule à /var/log/messages- c'est un peu plus fin et ne risque pas de mettre accidentellement quelqu'un d'autre dans le groupe de l'application et de lui donner accès à des choses qu'il ne devrait pas voir.

— voretaq7
source

2

Oui, je l'ai utilisé setfaclpour donner accès au mail.logfichier à un client, vous n'aurez pas non plus besoin de coller une commande dans le logrotate.conffichier pour réinitialiser l'ACL après la rotation des journaux, par exemple:

postrotate
         /usr/bin/setfacl -m o::r /var/log/mail.log  
endscript

Notez que je viens de configurer cela et que je n'ai pas testé, mais bien qu'il soit affiché ici, je ne peux pas voir pourquoi cela ne fonctionnerait pas, quelqu'un me corrige si je me trompe.

— Mat
source

0

Vous pouvez utiliser ACL pour cela. Il vous permet de définir des règles d'accès supplémentaires spécifiques pour des utilisateurs et des fichiers spécifiques.

— Landonz
source

-1

une fois que vous avez configuré votre ACL comme d'autres l'ont dit, au lieu de mettre toutes vos règles acl dans la configuration postrotate, vous pouvez utiliser logrotate pour utiliser copytruncate au lieu de créer un nouveau fichier journal à chaque fois

— Skullone
source