* ausearch checkpoint question
From: LC Bruzenak @ 2016-09-29 19:30 UTC (permalink / raw)
To: linux-audit@redhat.com
I'm using the 2.4.5-3 audit rpm set and I tried using the ausearch
"checkpoint" option a couple weeks ago.
This was on a moderately busy system (judging by my own
systems/experience) generating say 300-400MB of data/day.
I tried the checkpoint option in a 5-minute cron job, and I noticed that
in comparison to the "-ts recent" option, it took far longer to complete.
The "recent" option result was less than a second, whereas the
checkpoint version took ~20 seconds every 5 minutes.
It's possible there were other factors at play; e.g. it was used on a
mls-policy machine, and although I saw no AVCs, it's possible there were
some access issues I didn't have time to investigate.
On my intended application, I'll be on a standard targeted-policy
machine so this won't be a potential factor.
I need to test this again, as I'm considering using the ausearch
checkpoint capability for some new requirements, I was wondering if
perhaps there were any timing results done or if there are any tips and
tricks to getting the most out of it. Also - the man page section
describing this is a little confusing to me so if anyone has a script
segment that would be very helpful.
Thanks in advance,
LCB
--
LC Bruzenak
magitekltd.com
^ permalink raw reply
* Re: [PATCH] audit: add exclude filter extension to feature bitmap
From: Paul Moore @ 2016-09-29 17:37 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit, linux-kernel
In-Reply-To: <d8623526ac43cfb6eaa3fec2887c904cd9829e7b.1471065260.git.rgb@redhat.com>
On Thu, Aug 18, 2016 at 12:05 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> Add to the audit feature bitmap to indicate availability of the
> extension of the exclude filter to include PID, UID, AUID, GID, SUBJ_*.
>
> RFE: add additional fields for use in audit filter exclude rules
> https://github.com/linux-audit/audit-kernel/issues/5
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> include/uapi/linux/audit.h | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
Somehow this fell through the cracks - merged into the audit next branch.
> diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> index d820aa9..76c5e7e 100644
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@ -327,9 +327,11 @@ enum {
> #define AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT 0x00000001
> #define AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME 0x00000002
> #define AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH 0x00000004
> +#define AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND 0x00000008
> #define AUDIT_FEATURE_BITMAP_ALL (AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT | \
> AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME | \
> - AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH)
> + AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH | \
> + AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND)
>
> /* deprecated: AUDIT_VERSION_* */
> #define AUDIT_VERSION_LATEST AUDIT_FEATURE_BITMAP_ALL
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: Possible bug while setting syscall="all"
From: Steve Grubb @ 2016-09-28 13:05 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <CAHikZs55WRQfCTCwtABdO-5A2M8nMgMqx=udWsanN_CreiKVbg@mail.gmail.com>
On Tuesday, September 27, 2016 6:35:28 PM EDT Nathan Brown wrote:
> I am trying to fully understand the ruledata struct. I've got most of it
> figured out but I can't find a reason for the final 32 bits (last index) of
> mask to not be flipped on when selecting all syscalls. In general it
> appears that the final 32 bits are never used.
>
> https://github.com/linux-audit/audit-userspace/blob/f588248775b4f8180b846bbc
> 1681bc54e07871ed/lib/libaudit.c#L907
Yes, this is a bug. Since there are nowhere near 2016 syscalls on any arch, it
hadn't really posed a problem. Fixed in svn commit 1397. Thanks for reporting
this.
-Steve
^ permalink raw reply
* Re: Question regarding ntpd
From: Sullivan, Daniel [CRI] @ 2016-09-28 1:45 UTC (permalink / raw)
To: Ryan Sawhill; +Cc: Jarsulic, Michael [CRI], linux-audit@redhat.com
In-Reply-To: <CAEkAO+xK=XTahKPK2WNkzriFOB3aQY0-U17AawqTa7=J+sjPnA@mail.gmail.com>
Thank you for chiming in, Ryan. I saw a thread describing a similar strategy out there, what was confusing me was really two fold;
1) the entries being generated every second (i.e. outside of whatever perceived polling interval was configured).
2) the entries apparently not having any meaningful information (if presumably some sort of adjustment was being made); perhaps the -i switch Steve provided will account for this.
I think the responses provided are enough to point me in the right direction. Thank you for your help.
Dan
On Sep 27, 2016, at 7:21 PM, Ryan Sawhill <rsawhill@redhat.com<mailto:rsawhill@redhat.com>> wrote:
To say the thing that Steve knows but didn't explicitly point out:
The "time-change" key is used in the standard STIG rules. If you can get the clearance from the powers-that-be in your org, note that the auditctl rule format allows you to exclude time-change events generated by something that you want to trust, e.g., ntpd. I wrote an article for this exact issue recently on the Red Hat Customer Portal. See: How to exclude specific users, groups, or services when using auditd to audit syscalls<https://access.redhat.com/solutions/2477471>
--
Linux-audit mailing list
Linux-audit@redhat.com<mailto:Linux-audit@redhat.com>
https://www.redhat.com/mailman/listinfo/linux-audit
********************************************************************************
This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please
notify the sender and destroy all copies of the transmittal.
Thank you
University of Chicago Medicine and Biological Sciences
********************************************************************************
^ permalink raw reply
* Re: Question regarding ntpd
From: Sullivan, Daniel [CRI] @ 2016-09-28 1:21 UTC (permalink / raw)
To: John Jasen; +Cc: linux-audit@redhat.com
In-Reply-To: <17354e80-2d5a-c268-dfe5-ae1d0e812eb7@gmail.com>
Actually this is kind of where my head was at too. It just didn’t look like there was any meaningful data in the audit entry (i.e. actual time values). I appreciate you taking the time to get back to me.
Also, FWIW I am completely new to auditd.
Dan
> On Sep 27, 2016, at 7:06 PM, John Jasen <jjasen@gmail.com> wrote:
>
> Reading this, my first thought was ntpd trying to adjust time drift on
> the client.
>
>
> On 09/27/2016 07:16 PM, Steve Grubb wrote:
>> On Tuesday, September 27, 2016 10:05:31 PM EDT Sullivan, Daniel [CRI] wrote:
>>> type=SYSCALL msg=audit(1475012495.972:5327): arch=c000003e syscall=159
>>> success=yes exit=0 a0=7ffd7498eb00 a1=861 a2=0 a3=1 items=0 ppid=1 pid=5357
>>> auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38
>>> fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd"
>>> key="time-change”
>>>
>>> This is generating large amounts of log data.
>> Yep.
>>
>>> I am not an expert in auditd log analysis. Is this expected behavior?
>> Unfortunately for that syscall yes. Your best option is to not audit that
>> syscall.
>>
>>
>>> I am unsure of what the key time-change value of this log data is, and am
>>> wondering if this indicates some sort of misconfiguration or problem with
>>> ntpd.
>> Keys are used for reporting. You can run
>> aureport --start today --key --summary
>> to get an idea of what kinds of events you are getting. You can also use keys
>> with ausearch to extract events that trigger on a specific rule and then feed
>> that to aureport.
>>
>>
>>> From looking at the output of tcpdump it does not look like I am polling
>>> every second, so I am wondering why this activity is occurring. If anybody
>>> could advise on how to decipher these log entries I would appreciate it.
>>> Thank you for your help and advisement.
>> Well, using the -i option to ausearch gives more meaning:
>>
>> type=SYSCALL msg=audit(09/27/2016 17:41:35.972:5327) : arch=x86_64
>> syscall=adjtimex success=yes exit=0 a0=0x7ffd7498eb00 a1=0x861 a2=0x0 a3=0x1
>> items=0 ppid=1 pid=5357 auid=unset uid=ntp gid=ntp euid=ntp suid=ntp fsuid=ntp
>> egid=ntp sgid=ntp fsgid=ntp tty=(none) ses=unset comm=ntpd exe=/usr/sbin/ntpd
>> key=time-change
>>
>> But the syscall uses a single data struct and we have no visibility into that
>> so we cannot tell any more what its doing.
>>
>> The whole point of monitoring the time settings is that someone could tamper
>> with logs or cause something to appear like it occurred at a different time
>> than it really did. So, the idea is to collect this info "in case". But ntpd
>> overwhelms logs but chronyd might be marginally better. See bz
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=918127
>>
>> for some discussion.
>>
>> -Steve
>>
>> --
>> Linux-audit mailing list
>> Linux-audit@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-audit
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
********************************************************************************
This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please
notify the sender and destroy all copies of the transmittal.
Thank you
University of Chicago Medicine and Biological Sciences
********************************************************************************
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Possible bug while setting syscall="all"
From: Nathan Brown @ 2016-09-28 1:35 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 379 bytes --]
I am trying to fully understand the ruledata struct. I've got most of it
figured out but I can't find a reason for the final 32 bits (last index) of
mask to not be flipped on when selecting all syscalls. In general it
appears that the final 32 bits are never used.
https://github.com/linux-audit/audit-userspace/blob/f588248775b4f8180b846bbc1681bc54e07871ed/lib/libaudit.c#L907
[-- Attachment #1.2: Type: text/html, Size: 564 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Question regarding ntpd
From: Sullivan, Daniel [CRI] @ 2016-09-28 1:17 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com, Jarsulic, Michael [CRI]
In-Reply-To: <6969452.IzX1pIz0vM@x2>
Ok, this is bring clarity to the confusion. I appreciate you taking the time to provide a thoughtful and detailed reply.
Dan
> On Sep 27, 2016, at 6:16 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>
> On Tuesday, September 27, 2016 10:05:31 PM EDT Sullivan, Daniel [CRI] wrote:
>> type=SYSCALL msg=audit(1475012495.972:5327): arch=c000003e syscall=159
>> success=yes exit=0 a0=7ffd7498eb00 a1=861 a2=0 a3=1 items=0 ppid=1 pid=5357
>> auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38
>> fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd"
>> key="time-change”
>>
>> This is generating large amounts of log data.
>
> Yep.
>
>> I am not an expert in auditd log analysis. Is this expected behavior?
>
> Unfortunately for that syscall yes. Your best option is to not audit that
> syscall.
>
>
>> I am unsure of what the key time-change value of this log data is, and am
>> wondering if this indicates some sort of misconfiguration or problem with
>> ntpd.
>
> Keys are used for reporting. You can run
> aureport --start today --key --summary
> to get an idea of what kinds of events you are getting. You can also use keys
> with ausearch to extract events that trigger on a specific rule and then feed
> that to aureport.
>
>
>> From looking at the output of tcpdump it does not look like I am polling
>> every second, so I am wondering why this activity is occurring. If anybody
>> could advise on how to decipher these log entries I would appreciate it.
>> Thank you for your help and advisement.
>
> Well, using the -i option to ausearch gives more meaning:
>
> type=SYSCALL msg=audit(09/27/2016 17:41:35.972:5327) : arch=x86_64
> syscall=adjtimex success=yes exit=0 a0=0x7ffd7498eb00 a1=0x861 a2=0x0 a3=0x1
> items=0 ppid=1 pid=5357 auid=unset uid=ntp gid=ntp euid=ntp suid=ntp fsuid=ntp
> egid=ntp sgid=ntp fsgid=ntp tty=(none) ses=unset comm=ntpd exe=/usr/sbin/ntpd
> key=time-change
>
> But the syscall uses a single data struct and we have no visibility into that
> so we cannot tell any more what its doing.
>
> The whole point of monitoring the time settings is that someone could tamper
> with logs or cause something to appear like it occurred at a different time
> than it really did. So, the idea is to collect this info "in case". But ntpd
> overwhelms logs but chronyd might be marginally better. See bz
>
> https://bugzilla.redhat.com/show_bug.cgi?id=918127
>
> for some discussion.
>
> -Steve
********************************************************************************
This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please
notify the sender and destroy all copies of the transmittal.
Thank you
University of Chicago Medicine and Biological Sciences
********************************************************************************
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Question regarding ntpd
From: Ryan Sawhill @ 2016-09-28 0:21 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit, Jarsulic, Michael [CRI]
In-Reply-To: <6969452.IzX1pIz0vM@x2>
[-- Attachment #1.1: Type: text/plain, Size: 546 bytes --]
To say the thing that Steve knows but didn't explicitly point out:
The "time-change" key is used in the standard STIG rules. If you can get
the clearance from the powers-that-be in your org, note that the auditctl
rule format allows you to exclude time-change events generated by something
that you want to trust, e.g., ntpd. I wrote an article for this exact issue
recently on the Red Hat Customer Portal. See: How to exclude specific
users, groups, or services when using auditd to audit syscalls
<https://access.redhat.com/solutions/2477471>
[-- Attachment #1.2: Type: text/html, Size: 615 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Question regarding ntpd
From: John Jasen @ 2016-09-28 0:06 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <6969452.IzX1pIz0vM@x2>
Reading this, my first thought was ntpd trying to adjust time drift on
the client.
On 09/27/2016 07:16 PM, Steve Grubb wrote:
> On Tuesday, September 27, 2016 10:05:31 PM EDT Sullivan, Daniel [CRI] wrote:
>> type=SYSCALL msg=audit(1475012495.972:5327): arch=c000003e syscall=159
>> success=yes exit=0 a0=7ffd7498eb00 a1=861 a2=0 a3=1 items=0 ppid=1 pid=5357
>> auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38
>> fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd"
>> key="time-change”
>>
>> This is generating large amounts of log data.
> Yep.
>
>> I am not an expert in auditd log analysis. Is this expected behavior?
> Unfortunately for that syscall yes. Your best option is to not audit that
> syscall.
>
>
>> I am unsure of what the key time-change value of this log data is, and am
>> wondering if this indicates some sort of misconfiguration or problem with
>> ntpd.
> Keys are used for reporting. You can run
> aureport --start today --key --summary
> to get an idea of what kinds of events you are getting. You can also use keys
> with ausearch to extract events that trigger on a specific rule and then feed
> that to aureport.
>
>
>> From looking at the output of tcpdump it does not look like I am polling
>> every second, so I am wondering why this activity is occurring. If anybody
>> could advise on how to decipher these log entries I would appreciate it.
>> Thank you for your help and advisement.
> Well, using the -i option to ausearch gives more meaning:
>
> type=SYSCALL msg=audit(09/27/2016 17:41:35.972:5327) : arch=x86_64
> syscall=adjtimex success=yes exit=0 a0=0x7ffd7498eb00 a1=0x861 a2=0x0 a3=0x1
> items=0 ppid=1 pid=5357 auid=unset uid=ntp gid=ntp euid=ntp suid=ntp fsuid=ntp
> egid=ntp sgid=ntp fsgid=ntp tty=(none) ses=unset comm=ntpd exe=/usr/sbin/ntpd
> key=time-change
>
> But the syscall uses a single data struct and we have no visibility into that
> so we cannot tell any more what its doing.
>
> The whole point of monitoring the time settings is that someone could tamper
> with logs or cause something to appear like it occurred at a different time
> than it really did. So, the idea is to collect this info "in case". But ntpd
> overwhelms logs but chronyd might be marginally better. See bz
>
> https://bugzilla.redhat.com/show_bug.cgi?id=918127
>
> for some discussion.
>
> -Steve
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Question regarding ntpd
From: Steve Grubb @ 2016-09-27 23:16 UTC (permalink / raw)
To: linux-audit; +Cc: Jarsulic, Michael [CRI]
In-Reply-To: <AEC3559A-2C25-4408-A7A0-68379792DE66@bsd.uchicago.edu>
On Tuesday, September 27, 2016 10:05:31 PM EDT Sullivan, Daniel [CRI] wrote:
> type=SYSCALL msg=audit(1475012495.972:5327): arch=c000003e syscall=159
> success=yes exit=0 a0=7ffd7498eb00 a1=861 a2=0 a3=1 items=0 ppid=1 pid=5357
> auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38
> fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd"
> key="time-change”
>
> This is generating large amounts of log data.
Yep.
> I am not an expert in auditd log analysis. Is this expected behavior?
Unfortunately for that syscall yes. Your best option is to not audit that
syscall.
> I am unsure of what the key time-change value of this log data is, and am
> wondering if this indicates some sort of misconfiguration or problem with
> ntpd.
Keys are used for reporting. You can run
aureport --start today --key --summary
to get an idea of what kinds of events you are getting. You can also use keys
with ausearch to extract events that trigger on a specific rule and then feed
that to aureport.
> From looking at the output of tcpdump it does not look like I am polling
> every second, so I am wondering why this activity is occurring. If anybody
> could advise on how to decipher these log entries I would appreciate it.
> Thank you for your help and advisement.
Well, using the -i option to ausearch gives more meaning:
type=SYSCALL msg=audit(09/27/2016 17:41:35.972:5327) : arch=x86_64
syscall=adjtimex success=yes exit=0 a0=0x7ffd7498eb00 a1=0x861 a2=0x0 a3=0x1
items=0 ppid=1 pid=5357 auid=unset uid=ntp gid=ntp euid=ntp suid=ntp fsuid=ntp
egid=ntp sgid=ntp fsgid=ntp tty=(none) ses=unset comm=ntpd exe=/usr/sbin/ntpd
key=time-change
But the syscall uses a single data struct and we have no visibility into that
so we cannot tell any more what its doing.
The whole point of monitoring the time settings is that someone could tamper
with logs or cause something to appear like it occurred at a different time
than it really did. So, the idea is to collect this info "in case". But ntpd
overwhelms logs but chronyd might be marginally better. See bz
https://bugzilla.redhat.com/show_bug.cgi?id=918127
for some discussion.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Question regarding ntpd
From: Sullivan, Daniel [CRI] @ 2016-09-27 22:05 UTC (permalink / raw)
To: linux-audit@redhat.com; +Cc: Jarsulic, Michael [CRI]
Hi,
I have what I hope to be a quick question regarding auditing ntpd. I am looking at my auditd log file and I see this same entry being repeated every second:
type=SYSCALL msg=audit(1475012493.972:5325): arch=c000003e syscall=159 success=yes exit=0 a0=7ffd7498eb00 a1=861 a2=0 a3=1 items=0 ppid=1 pid=5357 auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38 fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd" key="time-change"
type=SYSCALL msg=audit(1475012494.971:5326): arch=c000003e syscall=159 success=yes exit=0 a0=7ffd7498eb00 a1=861 a2=0 a3=1 items=0 ppid=1 pid=5357 auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38 fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd" key="time-change"
type=SYSCALL msg=audit(1475012495.972:5327): arch=c000003e syscall=159 success=yes exit=0 a0=7ffd7498eb00 a1=861 a2=0 a3=1 items=0 ppid=1 pid=5357 auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38 fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd" key="time-change”
This is generating large amounts of log data. I am not an expert in auditd log analysis. Is this expected behavior? I am unsure of what the key time-change value of this log data is, and am wondering if this indicates some sort of misconfiguration or problem with ntpd. From looking at the output of tcpdump it does not look like I am polling every second, so I am wondering why this activity is occurring. If anybody could advise on how to decipher these log entries I would appreciate it. Thank you for your help and advisement.
Best,
Dan Sullivan
********************************************************************************
This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please
notify the sender and destroy all copies of the transmittal.
Thank you
University of Chicago Medicine and Biological Sciences
********************************************************************************
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: undefined reference to `capng_save_state' - linkink e4rat-collect
From: Steve Grubb @ 2016-09-26 19:50 UTC (permalink / raw)
To: linux-audit
Cc: Александр Демидов
In-Reply-To: <fbf5d55e86089f990d55a8118884cc36@dimti.ru>
On Monday, September 26, 2016 4:17:24 PM EDT Александр Демидов wrote:
> Hello
>
> I try to use new applications for me - e4rat
>
> My OS: ArchLinux
>
> I install audit with static libs for resolve building e4rat application
>
> But, in building e4rat-collect, i fetched error:
>
> [ 52%] Linking CXX executable ../e4rat-collect
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib/libaudit.a(libaudit.o
> ): In function `audit_can_control':
> (.text+0x25f6): undefined reference to `capng_save_state'
>
> I see in https://svn.fedorahosted.org/svn/audit/trunk/lib/libaudit.c the
> code
>
> int audit_can_control(void)
> {
> #ifdef HAVE_LIBCAP_NG
> void *state = capng_save_state();
>
> But i dont understand, where error. In audit or in e4rat?
> If that error - bug in e4rat
> (https://wiki.archlinux.org/index.php/E4rat), please tell and i wrote to
> developers e4rat, if autdi is clean.
I think that you'll need static libcap-ng libraries to link against also. Or
you can compile audit without libcap-ng support.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* undefined reference to `capng_save_state' - linkink e4rat-collect
From: Александр Демидов @ 2016-09-26 13:17 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 849 bytes --]
Hello
I try to use new applications for me - e4rat
My OS: ArchLinux
I install audit with static libs for resolve building e4rat application
But, in building e4rat-collect, i fetched error:
[ 52%] Linking CXX executable ../e4rat-collect
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib/libaudit.a(libaudit.o):
In function `audit_can_control':
(.text+0x25f6): undefined reference to `capng_save_state'
I see in https://svn.fedorahosted.org/svn/audit/trunk/lib/libaudit.c the
code
int audit_can_control(void)
{
#ifdef HAVE_LIBCAP_NG
void *state = capng_save_state();
But i dont understand, where error. In audit or in e4rat?
If that error - bug in e4rat
(https://wiki.archlinux.org/index.php/E4rat), please tell and i wrote to
developers e4rat, if autdi is clean.
--
С уважением,
Александр Демидов
[-- Attachment #1.2: Type: text/html, Size: 1133 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* audit 2.6.7 released
From: Steve Grubb @ 2016-09-11 16:01 UTC (permalink / raw)
To: linux-audit
Hello,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit. It will also be in rawhide
soon. The ChangeLog is:
- Non-active log files should be read only
- In augenrules, restore the selinux context if restorecon is installed
- Update gitignore file and remove ltmain.sh (Richard Guy Briggs)
- Replace Group Separator with whitespace in syslog audispd plugin
- In auditd, check for euid rather than capabilities when local_events = no
- If events are piped from ausearch to audisp-remote, flush queue when done
- In auditctl, correct handling of -F key so that key is not part of value
- In auparse, move static variables to auparse_state_t
This update is probably the last of the 2.6 series. New development will begin
aiming new features towards a future 2.7 release.
This update fixes the file permissions on non-active logs. Augenrules now
restores the selinux context of the rules file. This is only an issue for MLS
systems. The Group Separator used in enriched events has been replaced by a
whitespace character for syslog.
When auditd is run from some containers that does not support audit
collection, it also runs auditd unprivileged. This makes auditd fail so it
switches to doing euid checks for this scenario.
It was also found that the very last record was not being sent when a file was
cat'ed into audisp-remote for remote collection. It now handles this
correctly.
And it was found that a bug was introduced in the 2.6.6 release where support
for multi-keys was fixed. It was also sending the field name into the kernel
when doing syscall rules with keys.
Please let me know if you run across any problems with this release.
-Steve
^ permalink raw reply
* Re: adding rules after setting rules immutable
From: Richard Guy Briggs @ 2016-09-08 16:16 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <1606226.BHdsqEiX8T@x2>
On 2016-09-08 09:52, Steve Grubb wrote:
> On Thursday, September 8, 2016 9:42:09 AM EDT warron.french wrote:
> > While working with RHEL-6 and RHEL-7 systems, and understanding that you
> > can set rules to immutable by adding *-e 2* to the end of the audit.rules
> > file(s) I realized something.
> >
> > If I want to add rules to a system due to new IT Governance, I might have
> > to reboot every machine that gets the newly added rules.
>
> Yes, you need to reboot. This is what immutable means - no changes allowed
> during runtime.
>
> > Is this true, or can I get away with simply executing, on both versions of
> > RHEL (6 and 7):
> > augenrules --check
> > augenrules --load
>
> These will fail.
Warron, it isn't userspace that is gating this. Once immutable is set,
the kernel simply stops listening to any changes requested. Once
userspace invokes this command, it is powerless to change it until the
next boot.
> > I ask, because I want to write some puppet code that is smart enough to
> > ensure the rules are put into place. Do I really have to reboot a server
> > in the middle of a work day or can I work around it with the use of the
> > *augenrules* commands as listed above?
>
> This is what immutable does. If you need flexibility to change rules at will,
> then you should comment out or delete the -e 2 at the end.
>
> -Steve
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: adding rules after setting rules immutable
From: Steve Grubb @ 2016-09-08 13:52 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <CAJdJdQ=xVMoN_s+03vkYJKbqVGF_mzZ+6BnbgrOM2bXDp12VAQ@mail.gmail.com>
On Thursday, September 8, 2016 9:42:09 AM EDT warron.french wrote:
> While working with RHEL-6 and RHEL-7 systems, and understanding that you
> can set rules to immutable by adding *-e 2* to the end of the audit.rules
> file(s) I realized something.
>
> If I want to add rules to a system due to new IT Governance, I might have
> to reboot every machine that gets the newly added rules.
Yes, you need to reboot. This is what immutable means - no changes allowed
during runtime.
> Is this true, or can I get away with simply executing, on both versions of
> RHEL (6 and 7):
> augenrules --check
> augenrules --load
These will fail.
> I ask, because I want to write some puppet code that is smart enough to
> ensure the rules are put into place. Do I really have to reboot a server
> in the middle of a work day or can I work around it with the use of the
> *augenrules* commands as listed above?
This is what immutable does. If you need flexibility to change rules at will,
then you should comment out or delete the -e 2 at the end.
-Steve
^ permalink raw reply
* adding rules after setting rules immutable
From: warron.french @ 2016-09-08 13:42 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 762 bytes --]
While working with RHEL-6 and RHEL-7 systems, and understanding that you
can set rules to immutable by adding *-e 2* to the end of the audit.rules
file(s) I realized something.
If I want to add rules to a system due to new IT Governance, I might have
to reboot every machine that gets the newly added rules.
Is this true, or can I get away with simply executing, on both versions of
RHEL (6 and 7):
augenrules --check
augenrules --load
I ask, because I want to write some puppet code that is smart enough to
ensure the rules are put into place. Do I really have to reboot a server
in the middle of a work day or can I work around it with the use of the
*augenrules* commands as listed above?
Thanks in advance,
--------------------------
Warron French
[-- Attachment #1.2: Type: text/html, Size: 1225 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [GIT PULL] Audit fixes for v4.8
From: Paul Moore @ 2016-09-01 18:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-audit, linux-kernel
Hi Linus,
Two small patches to fix some bugs with the audit-by-executable
functionality we introduced back in v4.3 (both patches are marked for
the stable folks). Please consider these fixes for v4.8.
Thanks,
-Paul
---
The following changes since commit 43761473c254b45883a64441dd0bc85a42f3645c:
audit: fix a double fetch in audit_log_single_execve_arg()
(2016-07-20 14:15:46 -0400)
are available in the git repository at:
git://git.infradead.org/users/pcmoore/audit stable-4.8
for you to fetch changes up to 5efc244346f9f338765da3d592f7947b0afdc4b5:
audit: fix exe_file access in audit_exe_compare (2016-08-31 16:16:35 -0400)
----------------------------------------------------------------
Mateusz Guzik (2):
mm: introduce get_task_exe_file
audit: fix exe_file access in audit_exe_compare
fs/proc/base.c | 7 +------
include/linux/mm.h | 1 +
kernel/audit_watch.c | 8 +++++---
kernel/fork.c | 23 +++++++++++++++++++++++
4 files changed, 30 insertions(+), 9 deletions(-)
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [PATCHv2 0/2] introduce get_task_exe_file and use it to fix audit_exe_compare
From: Paul Moore @ 2016-08-31 20:22 UTC (permalink / raw)
To: Mateusz Guzik, linux-kernel
Cc: Konstantin Khlebnikov, Richard Guy Briggs, oleg, luto,
linux-audit, ebiederm, Al Viro
In-Reply-To: <CAHC9VhTBfqYH1m-eKjSXtiyvLSjjdoVHbNVZquJHv55jx04WAQ@mail.gmail.com>
On Mon, Aug 29, 2016 at 6:50 PM, Paul Moore <paul@paul-moore.com> wrote:
> On Tue, Aug 23, 2016 at 10:20 AM, Mateusz Guzik <mguzik@redhat.com> wrote:
>> audit_exe_compare directly accesses mm->exe_file without making sure the
>> object is stable. Fixing it using current primitives results in
>> partially duplicating what proc_exe_link is doing.
>>
>> As such, introduce a trivial helper which can be used in both places and
>> fix the func.
>>
>> Changes since v1:
>> * removed an unused 'out' label which crept in
>>
>> Mateusz Guzik (2):
>> mm: introduce get_task_exe_file
>> audit: fix exe_file access in audit_exe_compare
>>
>> fs/proc/base.c | 7 +------
>> include/linux/mm.h | 1 +
>> kernel/audit_watch.c | 8 +++++---
>> kernel/fork.c | 23 +++++++++++++++++++++++
>> 4 files changed, 30 insertions(+), 9 deletions(-)
>
> Thanks for doing this.
>
> Both patches look fine to me, does anyone in the mm area have any
> objections? If not, I'll merge these into the audit tree and mark
> them for stable.
I just merged these patches into audit#stable-4.8 and have a kernel
building now, as soon as it finishes I'll do some quick sanity tests
and send them off to Linus.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] audit: consistently record PIDs with task_tgid_nr()
From: Paul Moore @ 2016-08-31 20:04 UTC (permalink / raw)
To: Paul Moore; +Cc: Jeff Vander Stoep, linux-audit, linux-security-module, selinux
In-Reply-To: <CAGH-KgtOQx6XLStD++n8kBMKNky1t8or7KC2UyYxdaRXjQMhbA@mail.gmail.com>
On Tue, Aug 30, 2016 at 5:15 PM, Paul Moore <pmoore@redhat.com> wrote:
> On Tue, Aug 30, 2016 at 5:13 PM, Paul Moore <pmoore@redhat.com> wrote:
>> From: Paul Moore <paul@paul-moore.com>
>>
>> Unfortunately we record PIDs in audit records using a variety of
>> methods despite the correct way being the use of task_tgid_nr().
>> This patch converts all of these callers, except for the case of
>> AUDIT_SET in audit_receive_msg() (see the comment in the code).
>>
>> Reported-by: Jeff Vander Stoep <jeffv@google.com>
>> Signed-off-by: Paul Moore <paul@paul-moore.com>
>> ---
>> kernel/audit.c | 8 +++++++-
>> kernel/auditsc.c | 12 ++++++------
>> security/lsm_audit.c | 4 ++--
>> 3 files changed, 15 insertions(+), 9 deletions(-)
>
> I forgot to tag this with "RFC". This patch compiles but I haven't
> had a chance to test it yet so it isn't going into audit#next just
> yet; if you have any concerns, now is the time to voice them.
This patch passes our meager testsuite and I haven't heard any
objections so I'm pushing this to the audit#next branch.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] audit: consistently record PIDs with task_tgid_nr()
From: Paul Moore @ 2016-08-30 22:04 UTC (permalink / raw)
To: Jeffrey Vander Stoep; +Cc: linux-audit, LSM List, SELinux
In-Reply-To: <CABXk95Dkm-8zsThUJsVCLJ3k5vD+1nc_6j4uR_MRKZLzQn-=eQ@mail.gmail.com>
On Tue, Aug 30, 2016 at 5:58 PM, Jeffrey Vander Stoep <jeffv@google.com> wrote:
> Can you add tid while you're at it?
Let's do that in a different patch. This patch is about fixing a bug,
the TID patch is about adding new functionality.
If you want to submit a TID patch on top of this that would be fine.
> We're already looking for it on Android:
> https://android-review.googlesource.com/#/c/236952
>
> On Tue, Aug 30, 2016 at 2:15 PM Paul Moore <pmoore@redhat.com> wrote:
>>
>> On Tue, Aug 30, 2016 at 5:13 PM, Paul Moore <pmoore@redhat.com> wrote:
>> > From: Paul Moore <paul@paul-moore.com>
>> >
>> > Unfortunately we record PIDs in audit records using a variety of
>> > methods despite the correct way being the use of task_tgid_nr().
>> > This patch converts all of these callers, except for the case of
>> > AUDIT_SET in audit_receive_msg() (see the comment in the code).
>> >
>> > Reported-by: Jeff Vander Stoep <jeffv@google.com>
>> > Signed-off-by: Paul Moore <paul@paul-moore.com>
>> > ---
>> > kernel/audit.c | 8 +++++++-
>> > kernel/auditsc.c | 12 ++++++------
>> > security/lsm_audit.c | 4 ++--
>> > 3 files changed, 15 insertions(+), 9 deletions(-)
>>
>> I forgot to tag this with "RFC". This patch compiles but I haven't
>> had a chance to test it yet so it isn't going into audit#next just
>> yet; if you have any concerns, now is the time to voice them.
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [PATCH] audit: consistently record PIDs with task_tgid_nr()
From: Jeffrey Vander Stoep @ 2016-08-30 21:58 UTC (permalink / raw)
To: Paul Moore, linux-audit-H+wXaHxf7aLQT0dZR+AlfA; +Cc: LSM List, SELinux
In-Reply-To: <CAGH-KgtOQx6XLStD++n8kBMKNky1t8or7KC2UyYxdaRXjQMhbA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1279 bytes --]
Can you add tid while you're at it?
We're already looking for it on Android:
https://android-review.googlesource.com/#/c/236952
On Tue, Aug 30, 2016 at 2:15 PM Paul Moore <pmoore-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, Aug 30, 2016 at 5:13 PM, Paul Moore <pmoore-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > From: Paul Moore <paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org>
> >
> > Unfortunately we record PIDs in audit records using a variety of
> > methods despite the correct way being the use of task_tgid_nr().
> > This patch converts all of these callers, except for the case of
> > AUDIT_SET in audit_receive_msg() (see the comment in the code).
> >
> > Reported-by: Jeff Vander Stoep <jeffv-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> > Signed-off-by: Paul Moore <paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org>
> > ---
> > kernel/audit.c | 8 +++++++-
> > kernel/auditsc.c | 12 ++++++------
> > security/lsm_audit.c | 4 ++--
> > 3 files changed, 15 insertions(+), 9 deletions(-)
>
> I forgot to tag this with "RFC". This patch compiles but I haven't
> had a chance to test it yet so it isn't going into audit#next just
> yet; if you have any concerns, now is the time to voice them.
>
> --
> paul moore
> security @ redhat
>
[-- Attachment #1.2: Type: text/html, Size: 2181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 304 bytes --]
_______________________________________________
Selinux mailing list
Selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org
To unsubscribe, send email to Selinux-leave-+05T5uksL2pAGbPMOrvdOA@public.gmane.org
To get help, send an email containing "help" to Selinux-request-+05T5uksL2pAGbPMOrvdOA@public.gmane.org
^ permalink raw reply
* Re: [PATCH] audit: consistently record PIDs with task_tgid_nr()
From: Paul Moore @ 2016-08-30 21:15 UTC (permalink / raw)
To: Jeff Vander Stoep, linux-audit; +Cc: linux-security-module, selinux
In-Reply-To: <147259160184.15526.16504125805093739705.stgit@localhost>
On Tue, Aug 30, 2016 at 5:13 PM, Paul Moore <pmoore@redhat.com> wrote:
> From: Paul Moore <paul@paul-moore.com>
>
> Unfortunately we record PIDs in audit records using a variety of
> methods despite the correct way being the use of task_tgid_nr().
> This patch converts all of these callers, except for the case of
> AUDIT_SET in audit_receive_msg() (see the comment in the code).
>
> Reported-by: Jeff Vander Stoep <jeffv@google.com>
> Signed-off-by: Paul Moore <paul@paul-moore.com>
> ---
> kernel/audit.c | 8 +++++++-
> kernel/auditsc.c | 12 ++++++------
> security/lsm_audit.c | 4 ++--
> 3 files changed, 15 insertions(+), 9 deletions(-)
I forgot to tag this with "RFC". This patch compiles but I haven't
had a chance to test it yet so it isn't going into audit#next just
yet; if you have any concerns, now is the time to voice them.
--
paul moore
security @ redhat
^ permalink raw reply
* [PATCH] audit: consistently record PIDs with task_tgid_nr()
From: Paul Moore @ 2016-08-30 21:13 UTC (permalink / raw)
To: Jeff Vander Stoep, linux-audit; +Cc: linux-security-module, selinux
From: Paul Moore <paul@paul-moore.com>
Unfortunately we record PIDs in audit records using a variety of
methods despite the correct way being the use of task_tgid_nr().
This patch converts all of these callers, except for the case of
AUDIT_SET in audit_receive_msg() (see the comment in the code).
Reported-by: Jeff Vander Stoep <jeffv@google.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
---
kernel/audit.c | 8 +++++++-
kernel/auditsc.c | 12 ++++++------
security/lsm_audit.c | 4 ++--
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 8d528f9..02bde12 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -877,6 +877,12 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
return err;
}
if (s.mask & AUDIT_STATUS_PID) {
+ /* NOTE: we are using task_tgid_vnr() below because
+ * the s.pid value is relative to the namespace
+ * of the caller; at present this doesn't matter
+ * much since you can really only run auditd
+ * from the initial pid namespace, but something
+ * to keep in mind if this changes */
int new_pid = s.pid;
pid_t requesting_pid = task_tgid_vnr(current);
@@ -1917,7 +1923,7 @@ void audit_log_task_info(struct audit_buffer *ab, struct task_struct *tsk)
" euid=%u suid=%u fsuid=%u"
" egid=%u sgid=%u fsgid=%u tty=%s ses=%u",
task_ppid_nr(tsk),
- task_pid_nr(tsk),
+ task_tgid_nr(tsk),
from_kuid(&init_user_ns, audit_get_loginuid(tsk)),
from_kuid(&init_user_ns, cred->uid),
from_kgid(&init_user_ns, cred->gid),
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 2672d10..3824b1b 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -455,7 +455,7 @@ static int audit_filter_rules(struct task_struct *tsk,
switch (f->type) {
case AUDIT_PID:
- pid = task_pid_nr(tsk);
+ pid = task_tgid_nr(tsk);
result = audit_comparator(pid, f->op, f->val);
break;
case AUDIT_PPID:
@@ -1993,7 +1993,7 @@ static void audit_log_set_loginuid(kuid_t koldloginuid, kuid_t kloginuid,
loginuid = from_kuid(&init_user_ns, kloginuid),
tty = audit_get_tty(current);
- audit_log_format(ab, "pid=%d uid=%u", task_pid_nr(current), uid);
+ audit_log_format(ab, "pid=%d uid=%u", task_tgid_nr(current), uid);
audit_log_task_context(ab);
audit_log_format(ab, " old-auid=%u auid=%u tty=%s old-ses=%u ses=%u res=%d",
oldloginuid, loginuid, tty ? tty_name(tty) : "(none)",
@@ -2220,7 +2220,7 @@ void __audit_ptrace(struct task_struct *t)
{
struct audit_context *context = current->audit_context;
- context->target_pid = task_pid_nr(t);
+ context->target_pid = task_tgid_nr(t);
context->target_auid = audit_get_loginuid(t);
context->target_uid = task_uid(t);
context->target_sessionid = audit_get_sessionid(t);
@@ -2245,7 +2245,7 @@ int __audit_signal_info(int sig, struct task_struct *t)
if (audit_pid && t->tgid == audit_pid) {
if (sig == SIGTERM || sig == SIGHUP || sig == SIGUSR1 || sig == SIGUSR2) {
- audit_sig_pid = task_pid_nr(tsk);
+ audit_sig_pid = task_tgid_nr(tsk);
if (uid_valid(tsk->loginuid))
audit_sig_uid = tsk->loginuid;
else
@@ -2345,7 +2345,7 @@ int __audit_log_bprm_fcaps(struct linux_binprm *bprm,
void __audit_log_capset(const struct cred *new, const struct cred *old)
{
struct audit_context *context = current->audit_context;
- context->capset.pid = task_pid_nr(current);
+ context->capset.pid = task_tgid_nr(current);
context->capset.cap.effective = new->cap_effective;
context->capset.cap.inheritable = new->cap_effective;
context->capset.cap.permitted = new->cap_permitted;
@@ -2377,7 +2377,7 @@ static void audit_log_task(struct audit_buffer *ab)
from_kgid(&init_user_ns, gid),
sessionid);
audit_log_task_context(ab);
- audit_log_format(ab, " pid=%d comm=", task_pid_nr(current));
+ audit_log_format(ab, " pid=%d comm=", task_tgid_nr(current));
audit_log_untrustedstring(ab, get_task_comm(comm, current));
audit_log_d_path_exe(ab, current->mm);
}
diff --git a/security/lsm_audit.c b/security/lsm_audit.c
index cccbf30..45d927a 100644
--- a/security/lsm_audit.c
+++ b/security/lsm_audit.c
@@ -220,7 +220,7 @@ static void dump_common_audit_data(struct audit_buffer *ab,
*/
BUILD_BUG_ON(sizeof(a->u) > sizeof(void *)*2);
- audit_log_format(ab, " pid=%d comm=", task_pid_nr(current));
+ audit_log_format(ab, " pid=%d comm=", task_tgid_nr(current));
audit_log_untrustedstring(ab, memcpy(comm, current->comm, sizeof(comm)));
switch (a->type) {
@@ -294,7 +294,7 @@ static void dump_common_audit_data(struct audit_buffer *ab,
case LSM_AUDIT_DATA_TASK: {
struct task_struct *tsk = a->u.tsk;
if (tsk) {
- pid_t pid = task_pid_nr(tsk);
+ pid_t pid = task_tgid_nr(tsk);
if (pid) {
char comm[sizeof(tsk->comm)];
audit_log_format(ab, " opid=%d ocomm=", pid);
^ permalink raw reply related
* Re: [PATCH] security: lsm_audit: print pid and tid
From: Paul Moore @ 2016-08-30 20:56 UTC (permalink / raw)
To: Jeff Vander Stoep
Cc: linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
selinux-+05T5uksL2qpZYMLLGbcSA
In-Reply-To: <1469544870-11574-1-git-send-email-jeffv-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Tue, Jul 26, 2016 at 10:54 AM, Jeff Vander Stoep <jeffv-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> dump_common_audit_data() currently contains a field for pid, but the
> value printed is actually the thread ID, tid. Update this value to
> return the task group ID. Add a new field for tid. With this change
> the values printed by audit now match the values returned by the
> getpid() and gettid() syscalls.
>
> Signed-off-by: Jeff Vander Stoep <jeffv-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> ---
> security/lsm_audit.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
Unfortunately while reviewing this code I realized that the problem
extends far beyond just lsm_audit.c, kernel/audit*.c is affected as
well. It's actually much worse in kernel/audit*.c as it is very
inconsistent.
I was going to ask you to fix the other code too while you were at it,
but I realized what it was easy enough to fix it while I was going
through the code anyway ... expect a patch shortly.
> diff --git a/security/lsm_audit.c b/security/lsm_audit.c
> index cccbf30..57f26c1 100644
> --- a/security/lsm_audit.c
> +++ b/security/lsm_audit.c
> @@ -220,7 +220,8 @@ static void dump_common_audit_data(struct audit_buffer *ab,
> */
> BUILD_BUG_ON(sizeof(a->u) > sizeof(void *)*2);
>
> - audit_log_format(ab, " pid=%d comm=", task_pid_nr(current));
> + audit_log_format(ab, " pid=%d tid=%d comm=", task_tgid_vnr(tsk),
> + task_pid_vnr(tsk));
> audit_log_untrustedstring(ab, memcpy(comm, current->comm, sizeof(comm)));
>
> switch (a->type) {
> @@ -294,10 +295,12 @@ static void dump_common_audit_data(struct audit_buffer *ab,
> case LSM_AUDIT_DATA_TASK: {
> struct task_struct *tsk = a->u.tsk;
> if (tsk) {
> - pid_t pid = task_pid_nr(tsk);
> + pid_t pid = task_tgid_vnr(tsk);
> if (pid) {
> char comm[sizeof(tsk->comm)];
> audit_log_format(ab, " opid=%d ocomm=", pid);
> + audit_log_format(ab, " opid=%d otid=%d ocomm=",
> + pid, task_pid_vnr(tsk));
> audit_log_untrustedstring(ab,
> memcpy(comm, tsk->comm, sizeof(comm)));
> }
> --
> 2.8.0.rc3.226.g39d4020
--
paul moore
www.paul-moore.com
_______________________________________________
Selinux mailing list
Selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org
To unsubscribe, send email to Selinux-leave-+05T5uksL2pAGbPMOrvdOA@public.gmane.org
To get help, send an email containing "help" to Selinux-request-+05T5uksL2pAGbPMOrvdOA@public.gmane.org
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox