* audispd audit-remote plugin and uid, gid, euid, suid, fsuid, egid, sgid, fsgid
@ 2014-11-13 14:51 Wojtczak Arkadiusz
2014-11-13 15:01 ` Steve Grubb
0 siblings, 1 reply; 3+ messages in thread
From: Wojtczak Arkadiusz @ 2014-11-13 14:51 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1.1: Type: text/plain, Size: 2764 bytes --]
Hello,
Lets assume that *id = uid or gid or euid or suid or fsuid or egid or sgid or fsgid.
Audispd audit-remote (au-remote.conf) plugin sends native (numeric) uid, gid, euid, suid, fsuid, egid, sgid, fsgid.
I want to correlate logs from many Linux boxes so I need to have *ids resolved to user/group names, similar to ausearch witch option "-interpret". Is there any way to enrich events with user/group names in au-remote or even earlier - in auditd or audit?
I've considered forking audit-remote to use auparse (injecting additional code somewhere near line 412 of audisp-remote.c) or doing something like "tail ... --follow audit.log | ausearch ... -i". Am I correct that to be 100% sure that user or group corresponds to appropriate *id the mapping process has to be done in the kernel? Otherwise there is low probability that during the time gap between actual event and "ausearch -i" someone could change *id or user/group name.
Any help would be appreciated.
Best regards,
Arkadiusz Wojtczak
Mainframe Security Expert
[cid:image001.png@01CFFF57.9D84FDD0]
PKO Bank Polski
Departament Bezpieczeństwa
Biuro Bezpieczeństwa Informatycznego
02-515 Warszawa, ul. Puławska 15
t: 22 521 68 80
k: 666 824 168
Nie drukuj tej wiadomości, ani innych dokumentów, jeśli nie jest to konieczne.
Powszechna Kasa Oszczędności Bank Polski Spółka Akcyjna z siedzibą w Warszawie przy ul. Puławskiej 15, 02-515 Warszawa, zarejestrowana w Sądzie Rejonowym dla m.st. Warszawy w Warszawie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 0000026438; NIP: 525-000-77-38 REGON: 016298263; kapitał zakładowy (kapitał wpłacony) 1 250 000 000 PLN / Powszechna Kasa Oszczędności Bank Polski S.A. registered in the District Court for the Capital City of Warsaw, 13th Commercial Division of the National Court Register under KRS number 0000026438, Tax Identification Number (NIP): 525-000-77-38, REGON: 016298263, share capital 1,250,000,000 PLN.
Niniejsza wiadomość może zawierać poufną i prawnie zastrzeżoną korespondencję między naszą Firmą i Klientem. Jeżeli nie jesteście Państwo jej adresatem informujemy, że otrzymali ją Państwo omyłkowo oraz, że przeglądanie, rozpowszechnianie lub kopiowanie jest zabronione. W przypadku omyłkowego otrzymania niniejszej wiadomości, prosimy o niezwłoczne powiadomienie o tym nadawcy i wykasowanie oryginału. / This message may contain a confidential and privileged our Company and Client communication. If you are not the intended recipient, you are hereby notified that you have received this message in error - any review, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete the original.
[-- Attachment #1.1.2: Type: text/html, Size: 9385 bytes --]
[-- Attachment #1.2: image001.png --]
[-- Type: image/png, Size: 10129 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: audispd audit-remote plugin and uid, gid, euid, suid, fsuid, egid, sgid, fsgid
2014-11-13 14:51 audispd audit-remote plugin and uid, gid, euid, suid, fsuid, egid, sgid, fsgid Wojtczak Arkadiusz
@ 2014-11-13 15:01 ` Steve Grubb
2014-11-13 15:32 ` LC Bruzenak
0 siblings, 1 reply; 3+ messages in thread
From: Steve Grubb @ 2014-11-13 15:01 UTC (permalink / raw)
To: linux-audit; +Cc: Wojtczak Arkadiusz
On Thursday, November 13, 2014 02:51:28 PM Wojtczak Arkadiusz wrote:
> Hello,
> Lets assume that *id = uid or gid or euid or suid or fsuid or egid or sgid
> or fsgid. Audispd audit-remote (au-remote.conf) plugin sends native
> (numeric) uid, gid, euid, suid, fsuid, egid, sgid, fsgid. I want to
> correlate logs from many Linux boxes so I need to have *ids resolved to
> user/group names, similar to ausearch witch option "-interpret". Is there
> any way to enrich events with user/group names in au-remote or even earlier
> - in auditd or audit?
Not yet. I have been thinking about this and think I am settled on how to do
this. (You can look at the auformat utility for some hints.) Just haven't
tackled it yet due to other priorities. If you have a central uid database and
use sssd or nscd rather than /etc/passwd, then you can probably achieve this.
> I've considered forking audit-remote to use auparse
> (injecting additional code somewhere near line 412 of audisp-remote.c) or
> doing something like "tail ... --follow audit.log | ausearch ... -i". Am I
> correct that to be 100% sure that user or group corresponds to appropriate
> *id the mapping process has to be done in the kernel?
No, but rather on the local machine. User name mappings is a user space
phenomenon. The kernel only understands numbers. All interprettation is done
in user space with trusted databases.
> Otherwise there is low probability that during the time gap between actual
> event and "ausearch -i" someone could change *id or user/group name. Any
> help would be appreciated.
They could unless use of those utilities are restricted. You could also setup
a centralized user name management system to help things. But if you want to
tackle this yourself, I think the uids, gids, and hostnames are the main
things that need interpreting locally. Everything else can be done after the
fact.
-Steve
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: audispd audit-remote plugin and uid, gid, euid, suid, fsuid, egid, sgid, fsgid
2014-11-13 15:01 ` Steve Grubb
@ 2014-11-13 15:32 ` LC Bruzenak
0 siblings, 0 replies; 3+ messages in thread
From: LC Bruzenak @ 2014-11-13 15:32 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 1480 bytes --]
On 11/13/2014 09:01 AM, Steve Grubb wrote:
> They could unless use of those utilities are restricted. You could also setup
> a centralized user name management system to help things. But if you want to
> tackle this yourself, I think the uids, gids, and hostnames are the main
> things that need interpreting locally. Everything else can be done after the
> fact.
This subject is one I I've griped before. I'm amazed that more people
haven't mentioned this.
From an assurance perspective, having the human-understandable names of
the accounts is important.
If auditing systems aggregate records from multiple sources, this is
pretty big.
Until we can easily do something like the following, this isn't dire:
machine: local aggregator enterprise aggregator
--------------- ---------------------
-----------------------------
finance sys1 ->
finance sys2 -> fin. aggr \
finance sys3 -> ->
engineering1 ->
engineering2 -> eng. aggr -> enterprise aggregator
engineering3 ->
marketing1 -> ->
marketing2 -> mark. aggr /
marketing3 ->
In fact, to me, the ultimate assurance architecture would be to have the
username management system reside on the local auditing aggregator with
a very controlled/audited/secure interface.
Then I'd interpret the uids, gids and hns there.
My $0.02 FWIW,
LCB
--
LC (Lenny) Bruzenak
lenny@magitekltd.com
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-11-13 15:32 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-13 14:51 audispd audit-remote plugin and uid, gid, euid, suid, fsuid, egid, sgid, fsgid Wojtczak Arkadiusz
2014-11-13 15:01 ` Steve Grubb
2014-11-13 15:32 ` LC Bruzenak
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox