8:51 a.m.
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.
9:01 a.m.
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
9:32 a.m.
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(a)magitekltd.com
3691
days inactive
3691
days old
linux-audit@lists.linux-audit.osci.io
2 comments
3 participants
participants (3)
-
LC Bruzenak -
Steve Grubb -
Wojtczak Arkadiusz