Skip to contentSkip to conversation

Which userspace packages modified for audit

DISCUSSION Tony Jones 6 participants 16 messages Feb 22, 2007 – Feb 26, 2007

lore
Share & tools
lore

Tony Jones

author
#0 lore raw

Is there a list of which userspace packages have been modified in Fedora to add calls to the audit system? I thought I had them all but I didn't :-)

Thanks!

Tony

#1 lore raw

SUSE ELS and Audit

Hi guys,

I'm really struggling to get an understanding of what kernel and audit version I need to be able to use file system watches on my SLES 10 box.

Quoted 1 line

From what I've managed to read and understand, we need kernel 2.6.18 and

audit version 1.2.x ? Is that correct ? At the moment I'm struggling to install 1.2.x, but I've managed to get the kernel up and running.

Also worth a note here ... by default, SLES 10 does not show system calls. It's disabled in /etc/sysconfig/auditd. Edit AUDITD_DISABLE_CONTEXTS, and make it ="no"

Cheers
Mark

This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address below) immediately. O2 (UK) Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 1743099. VAT number: GB 778 6037 85

#2 lore raw

Re: SUSE ELS and Audit

Quoted 5 lines · Johnston Mark (UK)

Hi guys,

I'm really struggling to get an understanding of what kernel and audit version I need to be able to use file system watches on my SLES 10 box.

Quoted 7 lines
Quoted 1 line

From what I've managed to read and understand, we need kernel 2.6.18 and

audit version 1.2.x ? Is that correct ? At the moment I'm struggling to install 1.2.x, but I've managed to get the kernel up and running.

Also worth a note here ... by default, SLES 10 does not show system calls. It's disabled in /etc/sysconfig/auditd. Edit AUDITD_DISABLE_CONTEXTS, and make it ="no"

SLES 10 Service Pack 1 will have the necessary functionality, filewatches are not in the SLES 10 GA version.

Ciao, Marcus

#3 lore raw

Re: SUSE ELS and Audit

In reply to Johnston Mark (UK)

Mark,

Quoted 6 lines

Hi guys,

I'm really struggling to get an understanding of what kernel and audit version I need to be able to use file system watches on my SLES 10 box.

Quoted 8 lines
Quoted 1 line

From what I've managed to read and understand, we need kernel 2.6.18 and

audit version 1.2.x ? Is that correct ? At the moment I'm struggling to install 1.2.x, but I've managed to get the kernel up and running.

Also worth a note here ... by default, SLES 10 does not show system calls. It's disabled in /etc/sysconfig/auditd. Edit AUDITD_DISABLE_CONTEXTS, and make it ="no"

SLES10 doesn't have file-watch until Service Pack 1, which is work-in-progress. I can make updated audit packages available for you to spare you the package building. The same accounts for the kernel package as well as pwdutils-plugin-audit. I'd be glad to know the results of your testing, in case. Contact me off-list to get the packages.

Quoted 2 lines

Cheers
Mark

Thanks,
Roman.

#4 lore raw

RE: SUSE ELS and Audit

Any ideas on when SP1 will be released?

Thanks
Mark

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Roman Drahtmueller
Sent: 23 February 2007 10:27
To: Johnston Mark (UK)
Cc: [email protected]
Subject: Re: SUSE ELS and Audit

Mark,

Quoted 5 lines

Hi guys,

I'm really struggling to get an understanding of what kernel and audit version I need to be able to use file system watches on my SLES 10

box.

Quoted 2 lines
Quoted 2 lines

From what I've managed to read and understand, we need kernel 2.6.18

and

Quoted 1 line

audit version 1.2.x ? Is that correct ? At the moment I'm struggling

to

Quoted 6 lines

install 1.2.x, but I've managed to get the kernel up and running.

Also worth a note here ... by default, SLES 10 does not show system calls. It's disabled in /etc/sysconfig/auditd. Edit AUDITD_DISABLE_CONTEXTS, and make it ="no"

SLES10 doesn't have file-watch until Service Pack 1, which is work-in-progress. I can make updated audit packages available for you to

spare you the package building. The same accounts for the kernel package

as well as pwdutils-plugin-audit. I'd be glad to know the results of your
testing, in case. Contact me off-list to get the packages.

Quoted 2 lines

Cheers
Mark

Thanks,
Roman.

--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit

This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address below) immediately. O2 (UK) Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 1743099. VAT number: GB 778 6037 85

#5 lore raw
In reply to Tony Jones
Quoted 2 lines · On Thursday 22 February 2007 18:03:40 Tony Jones wrote:

s there a list of which userspace packages have been modified in Fedora to add calls to the audit system?

passwd-0.73-1
vixie-cron-4.1-64.fc6
openssh-4.3p2-14.fc6
shadow-utils-4.0.17-12.fc6
util-linux-2.13-0.46.fc6
gdm-2.16.5-1.fc6
pam-0.99.6.2-3.15.fc6
aide-0.13-1
dbus-1.0.1-9.fc6
policycoreutils-1.34.1-4.fc6
cups-1.2.7-1.8.fc6
frysk-0.0.1.2007.02.07.rh1-1.fc6

I also think glibc's nscd is there too. But nscd & dbus are for SE Linux support.

-Steve

#6 lore raw

Steve,

If you get a minute, can you add a 1 line summary of what the modification does wrt auditing?

Thanks,

Matt

Quoted 26 lines · Steve Grubb
Quoted 2 lines · On Thursday 22 February 2007 18:03:40 Tony Jones wrote:

s there a list of which userspace packages have been modified in Fedora to add calls to the audit system?

passwd-0.73-1
vixie-cron-4.1-64.fc6
openssh-4.3p2-14.fc6
shadow-utils-4.0.17-12.fc6
util-linux-2.13-0.46.fc6
gdm-2.16.5-1.fc6
pam-0.99.6.2-3.15.fc6
aide-0.13-1
dbus-1.0.1-9.fc6
policycoreutils-1.34.1-4.fc6
cups-1.2.7-1.8.fc6
frysk-0.0.1.2007.02.07.rh1-1.fc6

I also think glibc's nscd is there too. But nscd & dbus are for SE Linux support.

-Steve

--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit

Signature · 5 lines
Red Hat, Global Professional Services

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
#7 lore raw
Quoted 2 lines · On Friday 23 February 2007 09:22:42 Matthew Booth wrote:

If you get a minute, can you add a 1 line summary of what the modification does wrt auditing?

I don't have time to document this for a while. They are generally all logging something.

-Steve

#8 lore raw
Quoted 6 lines · Steve Grubb
Quoted 2 lines · On Friday 23 February 2007 09:22:42 Matthew Booth wrote:

If you get a minute, can you add a 1 line summary of what the modification does wrt auditing?

I don't have time to document this for a while. They are generally all logging something.

Most of them have just support for emitting USER_LOGIN audit records.

Are these necessary, because PAM emits USER_START / USER_END records anyway...

Ciao, Marcus

#9 lore raw
Quoted 4 lines · On Sunday 25 February 2007 13:41:56 Marcus Meissner wrote:

Most of them have just support for emitting USER_LOGIN audit records.

Are these necessary, because PAM emits USER_START / USER_END records anyway...

Yes. NISPOM is concerned about tracking login/logout. How do you distinguish an actual login/logout vs the start of a session with the pam records? su and cron, for example, do not do an actual login yet they create those records.

-Steve

#10 lore raw
Quoted 9 lines · Steve Grubb
Quoted 4 lines · On Sunday 25 February 2007 13:41:56 Marcus Meissner wrote:

Most of them have just support for emitting USER_LOGIN audit records.

Are these necessary, because PAM emits USER_START / USER_END records anyway...

Yes. NISPOM is concerned about tracking login/logout. How do you distinguish an actual login/logout vs the start of a session with the pam records? su and cron, for example, do not do an actual login yet they create those records.

We could really handle this together with the loginuid tracking, right?

The pam_loginuid module could also generate the USER_LOGIN messages for instance?

Ciao, Marcus

#11 lore raw
Quoted 6 lines · Marcus Meissner
Quoted 4 lines

Yes. NISPOM is concerned about tracking login/logout. How do you distinguish an actual login/logout vs the start of a session with the pam records? su and cron, for example, do not do an actual login yet they create those records.

We could really handle this together with the loginuid tracking, right?

No, cron sets the loginuid because the action performed by the scripts is on a certain user's behalf.

Everything is the way it is for a reason.

-Steve

#12 lore raw
In reply to Steve Grubb

On a related note, what's the api for injecting an arbitrary audit event from userspace in 1.0.15? There doesn't appear to be anything obvious in the man pages.

Thanks,

Matt

Quoted 8 lines · Steve Grubb
Quoted 2 lines · On Friday 23 February 2007 09:22:42 Matthew Booth wrote:

If you get a minute, can you add a 1 line summary of what the modification does wrt auditing?

I don't have time to document this for a while. They are generally all logging something.

-Steve

Signature · 5 lines
Red Hat, Global Professional Services

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
#13 lore raw
Quoted 2 lines · On Sunday 25 February 2007 17:15:23 Matthew Booth wrote:

On a related note, what's the api for injecting an arbitrary audit event from userspace in 1.0.15?

audit_log_user_message().

Quoted 1 line

There doesn't appear to be anything obvious in the man pages.

There are several APIs to enforce consistent messages depending on the purpose. They all start with audit_log_ .

-Steve

#14 lore raw
Quoted 10 lines · Steve Grubb
Quoted 2 lines · On Sunday 25 February 2007 17:15:23 Matthew Booth wrote:

On a related note, what's the api for injecting an arbitrary audit event from userspace in 1.0.15?

audit_log_user_message().

Quoted 1 line

There doesn't appear to be anything obvious in the man pages.

There are several APIs to enforce consistent messages depending on the purpose. They all start with audit_log_ .

That's a lot of choices. I specifically want to log a message in my ausetauid utility containing the fully command line executed under a different auid. To make sure it turns up in searches, I want it to have the same audit event ID as the LOGIN message it generates. Is this achievable, and which function should I read the source for ;) ?

Thanks,

Matt

Signature · 5 lines
Red Hat, Global Professional Services

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
#15 lore raw
Quoted 6 lines · On Sunday 25 February 2007 17:35:08 Matthew Booth wrote:
Quoted 2 lines

There are several APIs to enforce consistent messages depending on the purpose. They all start with audit_log_ .

That's a lot of choices. I specifically want to log a message in my ausetauid utility containing the fully command line executed under a different auid.

You would need to build your message in a buffer and pass it to audit_log_user_message() as the message param since an API has not been built for the purpose you described in 1.0.15. You will also want to follow naming conventions laid out in the parsing spec.

Quoted 2 lines

To make sure it turns up in searches, I want it to have the same audit event ID as the LOGIN message it generates.

No can do.

Quoted 1 line

Is this achievable, and which function should I read the source for ;) ?

Nope. Setting the loginuid is a discrete event seen from the kernel's perspective.

-Steve