Qual è il modo più sicuro per consentire a un utente l'accesso in lettura a un file di registro?

21

La mia applicazione richiede l'accesso in lettura a /var/log/messages, che appartiene all'utente e al gruppo root. Qual è il livello minimo di esposizione richiesto /var/log/messagesaffinché la mia applicazione possa leggerlo?

Attualmente, il mio piano è quello di cambiare la proprietà del gruppo /var/log/messagesin un nuovo gruppo e aggiungere l'utente root e il mio utente dell'applicazione, ma ciò darebbe anche i privilegi di scrittura dell'applicazione /var/log/messages.

Sistema operativo: Centos 5.5

— gAMBOOKa
fonte

7

Non è necessario aggiungere il root al gruppo in quanto avrà comunque accesso tramite i privilegi dell'utente, dai la lettura del gruppo a qualsiasi gruppo tu decida. Ricorda di apportare le modifiche anche con logrotate o le modifiche del gruppo verranno cancellate ogni notte.

— rfelsburg
fonte

Dove si trovano gli script logrotate?

— GAMBOOKa,

1

/etc/logrotate.d/ è la cartella per gli script logrotate non funzionanti. / var / log / messages è in /etc/logrotate.d/syslog. Dovresti spostare / var / log / messages nel suo file all'interno di /etc/logrotate.conf e quindi usando qualcosa come 'create 0640 root new_group' digli di creare il file correttamente.

— rfelsburg,

Dovresti spostare / var / log / messages nel suo file all'interno di /etc/logrotate.d/

— Massimo

17

Solo per espandere un po 'le risposte sopra qui è un caso d'uso reale. Eseguo l'applicazione di analisi del registro aziendale Splunk su una scatola Redhat. Funziona sotto l'utente splunk e il gruppo splunk. Questo impedisce agli splunk di accedere ai log in / var / log in quanto sono accessibili solo da root (o da un amministratore sudo)

Al fine di consentire l'accesso in sola lettura solo per splunk ho usato alcuni ACL e modificato logrotate per persistere.

È possibile impostare manualmente l'ACL con

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

Questo non persisterà poiché logrotate non applicherà nuovamente l'impostazione ACL, quindi per una soluzione più permanente ho aggiunto una regola per logrotate per ripristinare l'ACL. Ho aggiunto il file ..

/etc/logrotate.d/Splunk_ACLs

con

{
    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
}

Controllare lo stato ACL di un file con

$ getfacl /var/log/messages

Per maggiori informazioni sugli ACL, consultare https://help.ubuntu.com/community/FilePermissionsACLs http://bencane.com/2012/05/27/acl-using-access-control-lists-on-linux/

— nick fox
fonte

pubblicato anche su splunk risponde risposte.splunk.com/answers/4253/…

— nick fox

1

Si noti che splunk non richiede l'autorizzazione di esecuzione sui file di registro, basta leggere.

— rojs,

@nickfox È l'intero contenuto /etc/logrotate.d/Splunk_ACLsche hai pubblicato lì? In realtà non è necessario specificare alcun percorso per logrotate per elaborare il bit postrotate?

— Dale Anderson,

hmmm Non la penso così. Non volevo modificare le configurazioni logrotate esistenti per i log di sistema e non volevo sostituirle con le mie. In questo modo la modifica personalizzata per splunk esiste in modo indipendente. Consentire di distribuire con un pacchetto o un pupazzo ecc. Ecco a cosa servono le directory /app.d/. Ovviamente potrei sbagliarmi, è stato più di un anno fa da quando l'ho fatto

— nick fox,

1

Solo una nota che suggerisce che se si utilizza l'opzione X (come nella maiuscola X anziché in x) verrà aggiunta l'esecuzione solo se il file è una directory o ha già il permesso di esecuzione per alcuni utenti

— steoleary

5

Il tuo piano è accettabile e nello schema di autorizzazioni Unix "tradizionale" è il modo migliore di procedere.
Un'altra opzione è fare in modo che syslog devia i messaggi di interesse su un altro file (il che evita di dare all'utente dell'app l'accesso a qualsiasi cosa sensibile che potrebbe trovarsi /var/log/messages).

Se non hai voglia di essere vincolato dal tradizionale schema di autorizzazioni di Utente / Gruppo / Altro, puoi anche utilizzare gli ACL POSIX (altri, eventualmente howtos / informazioni migliori disponibili tramite Google) per dare l'accesso in sola lettura all'utente della tua app /var/log/messages- questo è un po 'più preciso e non rischia di mettere accidentalmente qualcun altro nel gruppo dell'applicazione e dare loro l'accesso a cose che non dovrebbero essere in grado di vedere.

— voretaq7
fonte

2

Sì, ho usato setfaclquesto per dare accesso al mail.logfile per un cliente, non dovrai anche inserire un comando nel logrotate.conffile per reimpostare l'ACL dopo che i log sono stati ruotati, ad esempio:

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

Nota: ho appena impostato questo, e non ho testato, ma anche se tornerebbe qui, non riesco a capire perché non funzioni, qualcuno mi correggerà se sbaglio.

— opaco
fonte

0

È possibile utilizzare ACL per questo. Consente di impostare regole di accesso aggiuntive specifiche per utenti e file specifici.

— landonz
fonte

-1

una volta configurato ACL come hanno detto altre persone, invece di mettere tutte le regole acl nella configurazione postrotate, è possibile swith logrotate per usare copytruncate invece di creare un nuovo file di registro ogni volta

— Skullone
fonte