* [PATCH] audit-userspace: add GitHub issue template
From: Paul Moore @ 2016-10-04 20:55 UTC (permalink / raw)
To: linux-audit
This patch should be a harmless addition to the subversion repository
but it will add an issue template for the GitHub mirror.
* GitHub audit userspace mirror
-> https://github.com/linux-audit/audit-userspace
Signed-off-by: Paul Moore <paul@paul-moore.com>
---
.github/ISSUE_TEMPLATE.md | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 .github/ISSUE_TEMPLATE.md
diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md
new file mode 100644
index 0000000..c2f93e9
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE.md
@@ -0,0 +1,2 @@
+**NOTE:** Please refer to the [Reporting Bug and Requesting Features](https://github.com/linux-audit/audit-documentation/wiki/Reporting-Bugs-and-Requesting-Features) wiki page before creating any new GitHub issues.
+
^ permalink raw reply related
* Re: commands in hex vs ASCII
From: Burn Alting @ 2016-10-04 21:16 UTC (permalink / raw)
To: Kevin Brown; +Cc: linux-audit@redhat.com
In-Reply-To: <CABSg6BwaPuX=sHBa5+JLQ0n+Awm4OMNY9N3bAqOn-gho9gSL2w@mail.gmail.com>
Kevin,
Have you thought of locally processing the logs using ausearch -i (which
does the conversion you want) and then transmitting the locally
interpreted logs to your SIEM?
On Tue, 2016-10-04 at 10:13 -0400, Kevin Brown wrote:
> Thanks for the responses so far
>
^ permalink raw reply
* Re: commands in hex vs ASCII
From: F Rafi @ 2016-10-04 21:59 UTC (permalink / raw)
To: burn; +Cc: linux-audit@redhat.com, Kevin Brown
In-Reply-To: <1475615765.3342.26.camel@swtf.swtf.dyndns.org>
[-- Attachment #1.1: Type: text/plain, Size: 650 bytes --]
We're using the hex to ascii function in our hosted log aggregation
solution. It's something that we had to open a feature request for
initially but, it works well.
-Farhan
On Tue, Oct 4, 2016 at 5:16 PM, Burn Alting <burn@swtf.dyndns.org> wrote:
> Kevin,
>
> Have you thought of locally processing the logs using ausearch -i (which
> does the conversion you want) and then transmitting the locally
> interpreted logs to your SIEM?
>
> On Tue, 2016-10-04 at 10:13 -0400, Kevin Brown wrote:
> > Thanks for the responses so far
> >
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
[-- Attachment #1.2: Type: text/html, Size: 1257 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Problem running auditd on Raspberry Pi (fedora-server-24)
From: C.y @ 2016-10-05 10:06 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <2398954.Mz8eQUs4sm@x2>
[-- Attachment #1.1: Type: text/plain, Size: 9467 bytes --]
On Tue, Oct 4, 2016 at 11:10 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Tuesday, October 4, 2016 11:35:46 AM EDT C.y wrote:
> > On Tue, Oct 4, 2016 at 4:06 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > > On Sunday, October 2, 2016 11:00:16 AM EDT C.y wrote:
> > > > On Sun, Oct 2, 2016 at 12:20 AM, Steve Grubb <sgrubb@redhat.com>
> wrote:
> > > > > On Saturday, October 1, 2016 5:47:47 PM EDT C.y wrote:
> > > > > > Hi all,
> > > > > >
> > > > > >
> > > > > > I have fedora-server-24 installed on my raspberry-pi-3, following
> > > > > > the
> > > > > > guide https://fedoraproject.org/wiki/Raspberry_Pi.
> > > > > >
> > > > > > Once I get my raspberry pi boot up, there were error mentioning
> that
> > > > > > "audit not support not in kernel", which I believed were then
> > >
> > > resolved after I
> > >
> > > > > > rebuild my kernel.
> > > > > >
> > > > > > However, I got stuck when I tried to add rule using `auditctl`
> > >
> > > command
> > >
> > > > > > as below:
> > > > > > `# auditctl -w /etc/passwd -p wa -k passwd_changes`
> > > > > > Error sending add rule data request (Invalid argument)
> > > > >
> > > > > Hmm. I wonder if 'ausyscall open' gives you syscalls.
> > > >
> > > > `# ausyscall open` returns as below. So I suppose the answer is
> > > > yes?(correct me if I'm wrong)
> > > > open 5
> > > > mq_open 274
> > > > openat 322
> > > > perf_event_open 364
> > > > open_by_handle_at 371
> > >
> > > This means user space is doing the right thing. I am thinking this
> sounds
> > > like a kernel issue.
> > >
> > > Have you tried a few other simple commands?
> > >
> > > auditctl -e 1
> > > auditctl -s
> > > auditctl -always,exit -F arch=b64 -S open
> > >
> > > -Steve
> >
> > `# auditctl -e 1` returns:
> > enabled 1
> > failure 1
> > pid 293
> > rate_limit 0
> > backlog_limit 64
> > lost 11
> > backlog 0
> > backlog_wait_time 6000
> >
> > `# auditctl -s` returns:
> > enabled 1
> > failure 1
> > pid 293
> > rate_limit 0
> > backlog_limit 64
> > lost 11
> > backlog 0
> > backlog_wait_time 6000
>
> OK. So, this sounds like it can communicate with the kernel and part of the
> audit system is compiled in.
>
> > `# auditctl -a always,exit -F arch=b64 -S open` returns:
> > arch elf mapping not found
>
> OK. Maybe its not 64 bit.
>
> > `# auditctl -a always,exit -S open` returns:
> > Error sending add rule data request (Invalid argument)
>
> If it were 32 bit, then the above would have selected -F arch=b32
> automatically. The error message means the kernel rejected a field in the
> audit
> rule. Which field, I don't know.
It turns out that all these problem occurs because I missed out including
some of the config when building the kernel.
auditd works well on kernel compiled with `CONFIG_AUDITSYSCALL = y`.
p/s: option AUDITSYSCALL wasn't presented defaultly on raspi due to lacking
dependency of `! OABI_COMPAT`,
which its discussion can be found at
https://github.com/raspberrypi/firmware/issues/652
Thanks for spending time on my issues!
> > I also noticed that auditd is having difficulty in parsing
> > `/etc/auditd/auditd.rules`
> > on the booting stage,
> > `# journalctl -u auditd.service --this-boot` returns:
> > -- Logs begin at Fri 2016-02-12 00:28:01 CST, end at Tue 2016-10-04
> > 10:53:05 CST. --
> > Feb 12 00:28:06 raspi3.lab systemd[1]: Starting Security Auditing
> Service...
> > Feb 12 00:28:06 raspi3.lab auditd[287]: Started dispatcher: /sbin/audispd
> > pid: 301
> > Feb 12 00:28:06 raspi3.lab audispd[301]: priority_boost_parser called
> with:
> > 4
> > Feb 12 00:28:06 raspi3.lab augenrules[288]: /sbin/augenrules: No change
> > Feb 12 00:28:06 raspi3.lab audispd[301]: max_restarts_parser called
> with: 10
> > Feb 12 00:28:06 raspi3.lab augenrules[288]: Error sending add rule data
> > request (Invalid argument)
> > Feb 12 00:28:06 raspi3.lab augenrules[288]: There was an error in line 5
> of
> > /etc/audit/audit.rules
>
> I believe this is just saying that the rule in line 5 was rejected by the
> kernel. This is systemd induced. The Error sending rule message went to
> stderr, auditctl also logs to syslog that it had a problem. Systemd grabs
> both
> and logs them. So, this is really 2 messages for the same thing. Its not a
> parsing problem per se.
>
> -Steve
>
> > Feb 12 00:28:06 raspi3.lab augenrules[288]: No rules
> > Feb 12 00:28:06 raspi3.lab systemd[1]: Started Security Auditing Service.
> > Feb 12 00:28:06 raspi3.lab auditd[287]: Init complete, auditd 2.5.2
> > listening for events (startup state
> >
> > while `# cat /etc/audit/rules.d` returns:
> > -----
> > ## This file is automatically generated from /etc/audit/rules.d
> > -D
> >
> >
> > -a task,never
> > -----
> >
> > p/s: On the log above, RaspberryPi is showing the wrong time due to a
> > reboot,
> > the time will be corrected once the chronyd start functioning.
> >
> >
> > Regards,
> > CHING YI.
> >
> > > > > > I tried to search for solution but it lead me to a bug that were
> > >
> > > already
> > >
> > > > > > been solved like years ago. Can anyone tell me if I am in the
> right
> > >
> > > way
> > >
> > > > > > of getting auditd works on raspberry pi? Were the problem I've
> faced
> > >
> > > were
> > >
> > > > > > already a known issue?
> > > > > >
> > > > > > Below are my system information and some logs/details when I
> tried
> > > > > > to
> > > > > > diagnosis the problem and thanks a lot for your help in advance!
> > > > > >
> > > > > > `# uname -a`
> > > > > > Linux raspi3.lab 4.4.23-v7+ #2 SMP Sat Oct 1 15:24:41 CST 2016
> > > > > > armv7l
> > > > > > armv7l armv7l GNU/Linux
> > > > >
> > > > > I also wonder if we have a mismatch here. Is that armv seventy one
> or
> > >
> > > armv
> > >
> > > > > seven-el? Its coded in audit as seventy one.
> > > >
> > > > It's 7-el.
> > > > `# uname -a | grep 7l` (7-el) returns
> > > > Linux raspi3.lab 4.4.23-v7+ #2 SMP Sat Oct 1 15:24:41 CST 2016 armv7l
> > > > armv7l armv7l GNU/Linux
> > > >
> > > >
> > > > Sincerly,
> > > > CHING YI.
> > > >
> > > > > -Steve
> > > > >
> > > > > > `# modprobe configs ; gunzip -dc /proc/config.gz | grep AUDIT`
> > > > > > CONFIG_AUDIT=y
> > > > > > CONFIG_NETFILTER_XT_TARGET_AUDIT=m
> > > > > > CONFIG_AUDIT_GENERIC=y
> > > > > > # CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set
> > > > > >
> > > > > > `# systemctl status auditd.service`
> > > > > > ● auditd.service - Security Auditing Service
> > > > > >
> > > > > > Loaded: loaded (/usr/lib/systemd/system/auditd.service;
> enabled;
> > > > > >
> > > > > > vendor preset: enabled)
> > > > > >
> > > > > > Active: active (running) since Fri 2016-02-12 00:28:07 CST; 7
> > >
> > > months
> > >
> > > > > > 19 days ago
> > > > > >
> > > > > > Process: 1553 ExecReload=/bin/kill -HUP $MAINPID (code=exited,
> > > > > >
> > > > > > status=0/SUCCESS)
> > > > > >
> > > > > > Process: 279 ExecStartPost=/sbin/augenrules --load
> (code=exited,
> > > > > >
> > > > > > status=1/FAILURE)
> > > > > > Main PID: 278 (auditd)
> > > > > >
> > > > > > CGroup: /system.slice/auditd.service
> > > > > >
> > > > > > └─278 /sbin/auditd -n
> > > > > >
> > > > > > Oct 01 16:36:53 raspi3.lab auditd[278]:
> audit(1475311013.356:8458)
> > > > > > op=reconfigure state=changed auid=4294967295 pid=-1 subj=?
> > >
> > > res=success
> > >
> > > > > > Oct 01 16:36:53 raspi3.lab systemd[1]: Reloaded Security Auditing
> > > > > > Service.
> > > > > > Oct 01 16:37:28 raspi3.lab systemd[1]: Reloading Security
> Auditing
> > > > > > Service.
> > > > > > Oct 01 16:37:28 raspi3.lab auditd[278]: config change requested
> by
> > > > > > pid=-1
> > > > > > auid=4294967295 subj=?
> > > > > > Oct 01 16:37:28 raspi3.lab auditd[278]: audit(1475311048.046:257)
> > > > > > op=reconfigure state=changed auid=4294967295 pid=-1 subj=?
> > >
> > > res=success
> > >
> > > > > > Oct 01 16:37:28 raspi3.lab systemd[1]: Reloaded Security Auditing
> > > > > > Service.
> > > > > > Oct 01 16:38:18 raspi3.lab systemd[1]: Reloading Security
> Auditing
> > > > > > Service.
> > > > > > Oct 01 16:38:18 raspi3.lab auditd[278]: config change requested
> by
> > > > > > pid=-1
> > > > > > auid=4294967295 subj=?
> > > > > > Oct 01 16:38:18 raspi3.lab auditd[278]:
> audit(1475311098.716:2108)
> > > > > > op=reconfigure state=changed auid=4294967295 pid=-1 subj=?
> > >
> > > res=success
> > >
> > > > > > Oct 01 16:38:18 raspi3.lab systemd[1]: Reloaded Security Auditing
> > > > > > Service.
> > > > > >
> > > > > > While my `/var/log/audit/audit.log` was full with lines of
> > > > > > "SERVICE_START" & "SERVICE_STOP":
> > > > > > type=SERVICE_START msg=audit(1475313700.696:276): pid=1 uid=0
> > > > > > auid=4294967295 ses=4294967295 msg='unit=NetworkManager-
> dispatcher
> > > > > > comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?
> > > > > > terminal=? res=success'
> > > > > > type=SERVICE_STOP msg=audit(1475313710.836:277): pid=1 uid=0
> > > > > > auid=4294967295 ses=4294967295 msg='unit=NetworkManager-
> dispatcher
> > > > > > comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?
> > > > > > terminal=? res=success'
> > > > > >
> > > > > >
> > > > > > Sincerly,
> > > > > > CHING YI.
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 13403 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Steve Grubb @ 2016-10-10 17:24 UTC (permalink / raw)
To: Richard Guy Briggs, Paul Moore; +Cc: linux-audit
In-Reply-To: <1471544337-3108-1-git-send-email-rgb@redhat.com>
On Thursday, August 18, 2016 2:18:55 PM EDT Richard Guy Briggs wrote:
> loginuid_set support should have been added to userspace when it was
> added to the kernel around v3.10. Add it before we do similar for
> sessionID and sessionID_set.
If this were accepted, how would this change writing rules? IOW, can you give
an example rule so we can see what this looks like?
Thanks,
-Steve
> There will be a number of users of features_bitmap within the same
> function (exclude filter extension, sessionID filter), so refactor
> audit_rule_fieldpair_data() to put audit_get_features earlier in the
> function.
>
> Richard Guy Briggs (2):
> get feature list only once
> Add user filter option loginuid_set from uapi macro
> AUDIT_LOGINUID_SET
>
> trunk/lib/errormsg.h | 2 ++
> trunk/lib/fieldtab.h | 2 ++
> trunk/lib/libaudit.c | 17 ++++++++++++++++-
> trunk/lib/libaudit.h | 6 ++++++
> 4 files changed, 26 insertions(+), 1 deletions(-)
^ permalink raw reply
* Re: [userspace PATCH v2 2/2] Check exclude filter cred extension fields available in kernel
From: Steve Grubb @ 2016-10-10 17:47 UTC (permalink / raw)
To: Richard Guy Briggs, Paul Moore; +Cc: linux-audit
In-Reply-To: <1471545200-3742-3-git-send-email-rgb@redhat.com>
On Thursday, August 18, 2016 2:33:20 PM EDT Richard Guy Briggs wrote:
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> trunk/lib/errormsg.h | 2 +-
> trunk/lib/libaudit.c | 39 ++++++++++++++++++++++-----------------
> trunk/lib/libaudit.h | 3 +++
> 3 files changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/trunk/lib/errormsg.h b/trunk/lib/errormsg.h
> index 84bfdb3..4a897be 100644
> --- a/trunk/lib/errormsg.h
> +++ b/trunk/lib/errormsg.h
> @@ -47,7 +47,7 @@ static const struct msg_tab err_msgtab[] = {
> { -9, 0, "msgtype field can only be used with exclude filter
> list" }, { -10, 0, "Failed upgrading rule" },
> { -11, 0, "String value too long" },
> - { -12, 0, "Only msgtype field can be used with exclude filter" },
> + { -12, 0, "Only msgtype, uid, gid, auid*, subj* fields can be
> used with exclude filter" }, { -13, 1, "only takes = or != operators"
> },
> { -14, 0, "Permission can only contain \'rwxa\'" },
> { -15, 2, "-F unknown errno -"},
> diff --git a/trunk/lib/libaudit.c b/trunk/lib/libaudit.c
> index 798b3c8..5ffc38c 100644
> --- a/trunk/lib/libaudit.c
> +++ b/trunk/lib/libaudit.c
> @@ -1401,23 +1401,28 @@ int audit_rule_fieldpair_data(struct audit_rule_data
> **rulep, const char *pair, return -2;
>
> /* Exclude filter can be used only with MSGTYPE and cred fields */
> - if (flags == AUDIT_FILTER_EXCLUDE)
> - switch(field) {
> - case AUDIT_PID:
> - case AUDIT_UID:
> - case AUDIT_GID:
> - case AUDIT_LOGINUID:
> - case AUDIT_LOGINUID_SET:
> - case AUDIT_MSGTYPE:
> - case AUDIT_SUBJ_USER:
> - case AUDIT_SUBJ_ROLE:
> - case AUDIT_SUBJ_TYPE:
> - case AUDIT_SUBJ_SEN:
> - case AUDIT_SUBJ_CLR:
> - break;
> - default:
> - return -12;
> - }
> + if (flags == AUDIT_FILTER_EXCLUDE) {
> + if ((features & AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND) == 0) {
One question, why is this being and'ed directly? I was told that we have to go
through AUDIT_FEATURE_TO_MASK() to convert the value to a mask which can then
be and'ed. Is this macro now deprecated?
-Steve
> + if (field != AUDIT_MSGTYPE)
> + return -30;
> + } else
> + switch(field) {
> + case AUDIT_PID:
> + case AUDIT_UID:
> + case AUDIT_GID:
> + case AUDIT_LOGINUID:
> + case AUDIT_LOGINUID_SET:
> + case AUDIT_MSGTYPE:
> + case AUDIT_SUBJ_USER:
> + case AUDIT_SUBJ_ROLE:
> + case AUDIT_SUBJ_TYPE:
> + case AUDIT_SUBJ_SEN:
> + case AUDIT_SUBJ_CLR:
> + break;
> + default:
> + return -12;
> + }
> + }
>
> rule->fields[rule->field_count] = field;
> rule->fieldflags[rule->field_count] = op;
> diff --git a/trunk/lib/libaudit.h b/trunk/lib/libaudit.h
> index 0852bcc..f77691f 100644
> --- a/trunk/lib/libaudit.h
> +++ b/trunk/lib/libaudit.h
> @@ -278,6 +278,9 @@ extern "C" {
> #ifndef AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH
> #define AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH 0x00000004
> #endif
> +#ifndef AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND
> +#define AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND 0x00000008
> +#endif
>
> /* Defines for interfield comparison update */
> #ifndef AUDIT_OBJ_UID
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Paul Moore @ 2016-10-10 21:10 UTC (permalink / raw)
To: Steve Grubb, Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <3382475.po8Up8mjF7@x2>
On Mon, Oct 10, 2016 at 1:24 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Thursday, August 18, 2016 2:18:55 PM EDT Richard Guy Briggs wrote:
>> loginuid_set support should have been added to userspace when it was
>> added to the kernel around v3.10. Add it before we do similar for
>> sessionID and sessionID_set.
>
> If this were accepted, how would this change writing rules? IOW, can you give
> an example rule so we can see what this looks like?
We have a RFE feature page which documents some rule examples:
* https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-User-Filter
--
paul moore
security @ redhat
^ permalink raw reply
* Re: Question regarding ntpd
From: L. A. Walsh @ 2016-10-10 21:48 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit, Jarsulic, Michael [CRI]
In-Reply-To: <6969452.IzX1pIz0vM@x2>
Steve Grubb wrote:
> But ntpd overwhelms logs but chronyd might be marginally better. See bz
> https://bugzilla.redhat.com/show_bug.cgi?id=918127
>
---
I took a gander at said bugzilla num, and found a minor surprise in that
there
Miroslav Lichvar said:
"You can use ntpd from the ntp package instead of chrony, it
shouldn't call adjtimex as often as chronyd does."
---
I.e. the exact opposite of your (Steve)'s statement. Wondered if that was
a misread or newer information...<*idle curiosity*>.
Either way sounds like it would be "nice" to differentiate a "read" from
a "write" in this syscall if it is to be useful.
-l
^ permalink raw reply
* Syscalls to use
From: warron.french @ 2016-10-11 14:58 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 1854 bytes --]
I apologize, but I am not sure how to go about determining the appropriate
syscalls to use for various audit goals.
I know that recently I learned to use the ausyscall --dump command to list
the ausyscalls; but apparently I mis-understood/interpreted the purpose of
1 or 2 of the syscalls and had to be corrected (thanks Steve).
Anyway, my organization has a goal to audit several things; of which I know
how to manage most, for examples:
1. File & Object
- Creation (Success/Failure) | w
- Access (Success/Failure) | r
- Deletion (Success/Failure) | w
- Content Modification (Success/Failure) | a
- Permission Modification (Success/Failure) | a
- Ownership Modification (Success/Failure) | a
For these I would have used a watch (*-w*) rule and set the -p flags to *r,
w* or *a* as shown above. From what I understand though, correct me if I
am wrong Steve, we should be getting away from the watch rules and move
towards Syscalls and using *-F path=/path/to/file*, or
*-F path=/path/to/several_files/* -- is this correct, both for RHEL6 and
RHEL7?
Also, I need to audit (Success/Failure) for the following sort of things:
*Authentications*
Logons
Logoffs
*Writes/downloads to external devices/media*
*Uploads from external devices/media *(
*such as DvD, thumbdrive, etc)*
*User & Group* *events*
User: Creation, deletion, Modification, suspending/locking
Group/Role: Creation, deletion, modification
*Use of Privileged/Special Rights events* (
*such as sudo, su, etc..)*
*Printing to a print-device*
*Printing to a file*
Thanks in advance for any steering someone could provide to get me moving
in the correct direction.
--------------------------
Warron French
[-- Attachment #1.2: Type: text/html, Size: 3556 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Question regarding ntpd
From: Steve Grubb @ 2016-10-11 16:07 UTC (permalink / raw)
To: L. A. Walsh; +Cc: linux-audit, Jarsulic, Michael [CRI]
In-Reply-To: <57FC0CA7.4000404@tlinx.org>
On Monday, October 10, 2016 2:48:23 PM EDT L. A. Walsh wrote:
> Steve Grubb wrote:
> > But ntpd overwhelms logs but chronyd might be marginally better. See bz
> > https://bugzilla.redhat.com/show_bug.cgi?id=918127
>
> ---
> I took a gander at said bugzilla num, and found a minor surprise in that
> there
> Miroslav Lichvar said:
>
> "You can use ntpd from the ntp package instead of chrony, it
> shouldn't call adjtimex as often as chronyd does."
> ---
>
> I.e. the exact opposite of your (Steve)'s statement. Wondered if that was
> a misread or newer information...<*idle curiosity*>.
>
> Either way sounds like it would be "nice" to differentiate a "read" from
> a "write" in this syscall if it is to be useful.
I agree. But the problem with this syscall is that the operation is part of a
data structure that is passed by address to the kernel. There currently is no
good way to filter its uses because the audit subsystem can only look at the
actual argument passed. I think there may be an issue opened for this on
github.
-Steve
^ permalink raw reply
* Re: Syscalls to use
From: Ryan Sawhill @ 2016-10-11 16:27 UTC (permalink / raw)
To: warron.french; +Cc: linux-audit
In-Reply-To: <CAJdJdQkE_TiJNVyecYfCT819gWANDNYQpr3wT0UHs16MQWOd+w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 5427 bytes --]
warron.french <warron.french@gmail.com> wrote:
> Anyway, my organization has a goal to audit several things; of which I
> know how to manage most, for examples:
> ...
>
Hi Warron. Have you looked at the various *.rules files that are shipped
with the audit package? In RHEL/CentOS, you'll see:
~]# ls -1 /usr/share/doc/audit-2.4.1/*rules
> /usr/share/doc/audit-2.4.1/capp.rules
> /usr/share/doc/audit-2.4.1/lspp.rules
> /usr/share/doc/audit-2.4.1/nispom.rules
> /usr/share/doc/audit-2.4.1/stig.rules
>
These files already have example rules to do probably everything you're
trying to do.
In newer versions, e.g., in Fedora, it gets even fancier:
~]# ls /usr/share/doc/audit/rules/
> 10-base-config.rules 32-power-abuse.rules
> 10-no-audit.rules 40-local.rules
> 11-loginuid.rules 41-containers.rules
> 12-cont-fail.rules 42-injection.rules
> 12-ignore-error.rules 43-module-load.rules
> 20-dont-audit.rules 70-einval.rules
> 21-no32bit.rules 71-networking.rules
> 22-ignore-chrony.rules 99-finalize.rules
> 30-nispom.rules Makefile
> 30-pci-dss-v31.rules Makefile.am
> 30-stig.rules Makefile.in
> 31-privileged.rules README-rules
>
These are also all well-documented examples. I think if you look through
those, you'll find everything you're looking for.
warron.french <warron.french@gmail.com> wrote:
> For these I would have used a watch (*-w*) rule and set the -p flags to *r,
> w* or *a* as shown above. From what I understand though, correct me if I
> am wrong Steve, we should be getting away from the watch rules and move
> towards Syscalls and using *-F path=/path/to/file*, or
> *-F path=/path/to/several_files/* -- is this correct, both for RHEL6
> and RHEL7?
>
No. The simple -w syntax isn't going anywhere. My understanding: there's no
performance hit for adding additional simple -w rules; whereas, you DO take
a performance hit for each additional syscall-auditing rule line. Use
watches if you can get away with the restrictive simplicity they offer; use
syscall-rules when you need to.
warron.french <warron.french@gmail.com> wrote:
> Also, I need to audit (Success/Failure) for the following sort of things:
>
> *Authentications*
> Logons
> Logoffs
>
You can see examples of how to handle that in the rules the audit package
ships with, e.g., from nispom:
## Audit 1, 1(b) Successful and unsuccessful logons and logoffs.
> ## This is covered by patches to login, gdm, and openssh
> ## Might also want to watch these files if needing extra information
> #-w /var/log/tallylog -p wa -k logins
> #-w /var/run/faillock/ -p wa -k logins
> #-w /var/log/lastlog -p wa -k logins
> #-w /var/log/btmp -p wa -k logins
> #-w /var/run/utmp -p wa -k logins
>
Or from stig:
## (GEN002720-GEN002840: CAT II) (Previously – G100-G106) The SA will
> ## configure the auditing system to audit the following events for all
> ## users and root:
> ##
> ## - Logon (unsuccessful and successful) and logout (successful)
> ##
> ## Handled by pam, sshd, login, and gdm
> ## Might also want to watch these files if needing extra information
> #-w /var/log/tallylog -p wa -k logins
> #-w /var/run/faillock/ -p wa -k logins
> #-w /var/log/lastlog -p wa -k logins
>
> ##- Process and session initiation (unsuccessful and successful)
> ##
> ## The session initiation is audited by pam without any rules needed.
> ## Might also want to watch this file if needing extra information
> #-w /var/run/utmp -p wa -k session
> #-w /var/log/btmp -p wa -k session
> #-w /var/log/wtmp -p wa -k session
>
warron.french <warron.french@gmail.com> wrote:
>
> *Writes/downloads to external devices/media*
> *Uploads from external devices/media *(
> *such as DvD, thumbdrive, etc)*
>
You can audit mount syscalls, but that's not exactly fun on a modern
system. In any case, in stig rules:
##- Export to media (successful)
> ## You have to mount media before using it. You must disable all
> automounting
> ## so that its done manually in order to get the correct user requesting
> the
> ## export
> -a always,exit -F arch=b32 -S mount -F auid>=1000 -F auid!=4294967295 -F
> key=export
> -a always,exit -F arch=b64 -S mount -F auid>=1000 -F auid!=4294967295 -F
> key=export
>
That said, the above example is assuming root login is disabled (requiring
people login as their own user and su/sudo to root) ... but it's something.
There was some discussion back in April cross-posted between the
linux-audit, linux-usb, and linux-kernel mailing lists (subj: "[RFC] Create
an audit record of USB specific details"). I think the usual approach is to
just disable stuff from BIOS. I could imagine (as a band-aid) adding udev
rules that generate audit events as well but I've never done it.
warron.french <warron.french@gmail.com> wrote:
> *User & Group* *events*
> User: Creation, deletion, Modification, suspending/locking
> Group/Role: Creation, deletion, modification
>
> *Use of Privileged/Special Rights events* (*such as sudo, su, etc..)*
>
Yep you'll find that in stig, nispom, etc.
warron.french <warron.french@gmail.com> wrote:
>
> *Printing to a print-device*
> *Printing to a file*
>
I would just completely remove CUPS ... or log use of lp/lpr commands.
Hope this helps get you on the right track.
[-- Attachment #1.2: Type: text/html, Size: 9150 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Question regarding ntpd
From: Ryan Sawhill @ 2016-10-11 16:33 UTC (permalink / raw)
To: L. A. Walsh; +Cc: Jarsulic, Michael [CRI], linux-audit
In-Reply-To: <57FC0CA7.4000404@tlinx.org>
[-- Attachment #1.1: Type: text/plain, Size: 401 bytes --]
Also perhaps relevant is that the latest audit package in Fedora 24 even
has:
~]# cat /usr/share/doc/audit/rules/22-ignore-chrony.rules
> ## This rule suppresses the time-change event when chrony does time updates
> -a never,exit -F arch=b64 -S adjtimex -F auid=unset -Fuid=chrony -F
> subj_type=chronyd_t
> -a never,exit -F arch=b32 -S adjtimex -F auid=unset -Fuid=chrony -F
> subj_type=chronyd_t
>
[-- Attachment #1.2: Type: text/html, Size: 580 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Steve Grubb @ 2016-10-11 16:40 UTC (permalink / raw)
To: Paul Moore; +Cc: Richard Guy Briggs, linux-audit
In-Reply-To: <CAGH-KgvR7BmJXYAhh1ovDK10adMXnbRm9=bzh2Efcgt4Wcq4LQ@mail.gmail.com>
On Monday, October 10, 2016 5:10:39 PM EDT Paul Moore wrote:
> On Mon, Oct 10, 2016 at 1:24 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Thursday, August 18, 2016 2:18:55 PM EDT Richard Guy Briggs wrote:
> >> loginuid_set support should have been added to userspace when it was
> >> added to the kernel around v3.10. Add it before we do similar for
> >> sessionID and sessionID_set.
> >
> > If this were accepted, how would this change writing rules? IOW, can you
> > give an example rule so we can see what this looks like?
>
> We have a RFE feature page which documents some rule examples:
>
> *
> https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-User-Filter
OK, thanks. This is helpful. So, what is the difference between these rules?
-a always,exit -F path=/tmp/sessionid_test -F loginuid=-1
-a always,exit -F path=/tmp/sessionid_set_test -F loginuid_set=0
-Steve
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Richard Guy Briggs @ 2016-10-11 18:27 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <2160607.4V3FbIfBlX@x2>
On 2016-10-11 12:40, Steve Grubb wrote:
> On Monday, October 10, 2016 5:10:39 PM EDT Paul Moore wrote:
> > On Mon, Oct 10, 2016 at 1:24 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > > On Thursday, August 18, 2016 2:18:55 PM EDT Richard Guy Briggs wrote:
> > >> loginuid_set support should have been added to userspace when it was
> > >> added to the kernel around v3.10. Add it before we do similar for
> > >> sessionID and sessionID_set.
> > >
> > > If this were accepted, how would this change writing rules? IOW, can you
> > > give an example rule so we can see what this looks like?
> >
> > We have a RFE feature page which documents some rule examples:
> >
> > *
> > https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-User-Filter
>
> OK, thanks. This is helpful. So, what is the difference between these rules?
>
> -a always,exit -F path=/tmp/sessionid_test -F loginuid=-1
>
> -a always,exit -F path=/tmp/sessionid_set_test -F loginuid_set=0
The only difference is one flag in the kernel to indicate how it was
invoked to be able to report when queried exactly the same way it was
invoked, but there is no difference in the actual behaviour of the
filter. This was added because of your report that "f24=0" was reported
instead of loginuid_set=0 for backwards compatibility.
Going forward, the implementation of the sessionid_set field (which
works similarly) will not allow an unset value of sessionid since these
are a new addition that didn't need to accomodate backward
compatibility.
> -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: [userspace PATCH v2 2/2] Check exclude filter cred extension fields available in kernel
From: Richard Guy Briggs @ 2016-10-11 19:09 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <2956869.9SxeY5TJWN@x2>
On 2016-10-10 13:47, Steve Grubb wrote:
> On Thursday, August 18, 2016 2:33:20 PM EDT Richard Guy Briggs wrote:
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > trunk/lib/errormsg.h | 2 +-
> > trunk/lib/libaudit.c | 39 ++++++++++++++++++++++-----------------
> > trunk/lib/libaudit.h | 3 +++
> > 3 files changed, 26 insertions(+), 18 deletions(-)
> >
> > diff --git a/trunk/lib/errormsg.h b/trunk/lib/errormsg.h
> > index 84bfdb3..4a897be 100644
> > --- a/trunk/lib/errormsg.h
> > +++ b/trunk/lib/errormsg.h
> > @@ -47,7 +47,7 @@ static const struct msg_tab err_msgtab[] = {
> > { -9, 0, "msgtype field can only be used with exclude filter
> > list" }, { -10, 0, "Failed upgrading rule" },
> > { -11, 0, "String value too long" },
> > - { -12, 0, "Only msgtype field can be used with exclude filter" },
> > + { -12, 0, "Only msgtype, uid, gid, auid*, subj* fields can be
> > used with exclude filter" }, { -13, 1, "only takes = or != operators"
> > },
> > { -14, 0, "Permission can only contain \'rwxa\'" },
> > { -15, 2, "-F unknown errno -"},
> > diff --git a/trunk/lib/libaudit.c b/trunk/lib/libaudit.c
> > index 798b3c8..5ffc38c 100644
> > --- a/trunk/lib/libaudit.c
> > +++ b/trunk/lib/libaudit.c
> > @@ -1401,23 +1401,28 @@ int audit_rule_fieldpair_data(struct audit_rule_data
> > **rulep, const char *pair, return -2;
> >
> > /* Exclude filter can be used only with MSGTYPE and cred fields */
> > - if (flags == AUDIT_FILTER_EXCLUDE)
> > - switch(field) {
> > - case AUDIT_PID:
> > - case AUDIT_UID:
> > - case AUDIT_GID:
> > - case AUDIT_LOGINUID:
> > - case AUDIT_LOGINUID_SET:
> > - case AUDIT_MSGTYPE:
> > - case AUDIT_SUBJ_USER:
> > - case AUDIT_SUBJ_ROLE:
> > - case AUDIT_SUBJ_TYPE:
> > - case AUDIT_SUBJ_SEN:
> > - case AUDIT_SUBJ_CLR:
> > - break;
> > - default:
> > - return -12;
> > - }
> > + if (flags == AUDIT_FILTER_EXCLUDE) {
> > + if ((features & AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND) == 0) {
>
> One question, why is this being and'ed directly? I was told that we have to go
> through AUDIT_FEATURE_TO_MASK() to convert the value to a mask which can then
> be and'ed. Is this macro now deprecated?
I was going to congratulate you on a nice catch, but
AUDIT_GET/SET_FEATURE and AUDIT_FEATURE_BITMAP are two different things.
The former gets and sets the state of features while the latter replaced
AUDIT_VERSION and simply checks for the presence of a backported
feature.
> -Steve
>
> > + if (field != AUDIT_MSGTYPE)
> > + return -30;
> > + } else
> > + switch(field) {
> > + case AUDIT_PID:
> > + case AUDIT_UID:
> > + case AUDIT_GID:
> > + case AUDIT_LOGINUID:
> > + case AUDIT_LOGINUID_SET:
> > + case AUDIT_MSGTYPE:
> > + case AUDIT_SUBJ_USER:
> > + case AUDIT_SUBJ_ROLE:
> > + case AUDIT_SUBJ_TYPE:
> > + case AUDIT_SUBJ_SEN:
> > + case AUDIT_SUBJ_CLR:
> > + break;
> > + default:
> > + return -12;
> > + }
> > + }
> >
> > rule->fields[rule->field_count] = field;
> > rule->fieldflags[rule->field_count] = op;
> > diff --git a/trunk/lib/libaudit.h b/trunk/lib/libaudit.h
> > index 0852bcc..f77691f 100644
> > --- a/trunk/lib/libaudit.h
> > +++ b/trunk/lib/libaudit.h
> > @@ -278,6 +278,9 @@ extern "C" {
> > #ifndef AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH
> > #define AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH 0x00000004
> > #endif
> > +#ifndef AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND
> > +#define AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND 0x00000008
> > +#endif
> >
> > /* Defines for interfield comparison update */
> > #ifndef AUDIT_OBJ_UID
>
>
- 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: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Steve Grubb @ 2016-10-11 19:22 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20161011182754.GJ744@madcap2.tricolour.ca>
On Tuesday, October 11, 2016 2:27:54 PM EDT Richard Guy Briggs wrote:
> On 2016-10-11 12:40, Steve Grubb wrote:
> > On Monday, October 10, 2016 5:10:39 PM EDT Paul Moore wrote:
> > > On Mon, Oct 10, 2016 at 1:24 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > > > On Thursday, August 18, 2016 2:18:55 PM EDT Richard Guy Briggs wrote:
> > > >> loginuid_set support should have been added to userspace when it was
> > > >> added to the kernel around v3.10. Add it before we do similar for
> > > >> sessionID and sessionID_set.
> > > >
> > > > If this were accepted, how would this change writing rules? IOW, can
> > > > you
> > > > give an example rule so we can see what this looks like?
> > >
> > > We have a RFE feature page which documents some rule examples:
> > >
> > > *
> > > https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-User-Fil
> > > ter
> >
> > OK, thanks. This is helpful. So, what is the difference between these
> > rules?
> >
> > -a always,exit -F path=/tmp/sessionid_test -F loginuid=-1
> >
> > -a always,exit -F path=/tmp/sessionid_set_test -F loginuid_set=0
>
> The only difference is one flag in the kernel to indicate how it was
> invoked to be able to report when queried exactly the same way it was
> invoked, but there is no difference in the actual behaviour of the
> filter. This was added because of your report that "f24=0" was reported
> instead of loginuid_set=0 for backwards compatibility.
OK. Generally its bad to have 2 ways to do the same thing. People use SCAP
content to check system configurations. If there's two ways to do the same
thing, then someone can accidentally choose the wrong way and fail their scan.
We run into this in the past where we allowed -a exit,always and -a
always,exit. All the rules had to be reworked to be consistent. Therefore, I
would recommend not using the loginuid_set option. We still get questions
about -w /path/file -p wa vs -a always,exit -F path=/path/file -F perm=wa. But
that one is so deeply embedded that it should not be fixed.
> Going forward, the implementation of the sessionid_set field (which
> works similarly) will not allow an unset value of sessionid since these
> are a new addition that didn't need to accomodate backward
> compatibility.
As long as we can trigger on sessionid=-1, then we are fine.
-Steve
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Paul Moore @ 2016-10-11 20:42 UTC (permalink / raw)
To: Steve Grubb; +Cc: Richard Guy Briggs, linux-audit
In-Reply-To: <2450529.4WsicgiRvn@x2>
On Tue, Oct 11, 2016 at 3:22 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Tuesday, October 11, 2016 2:27:54 PM EDT Richard Guy Briggs wrote:
>> On 2016-10-11 12:40, Steve Grubb wrote:
>> > On Monday, October 10, 2016 5:10:39 PM EDT Paul Moore wrote:
>> > > On Mon, Oct 10, 2016 at 1:24 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>> > > > On Thursday, August 18, 2016 2:18:55 PM EDT Richard Guy Briggs wrote:
>> > > >> loginuid_set support should have been added to userspace when it was
>> > > >> added to the kernel around v3.10. Add it before we do similar for
>> > > >> sessionID and sessionID_set.
>> > > >
>> > > > If this were accepted, how would this change writing rules? IOW, can
>> > > > you
>> > > > give an example rule so we can see what this looks like?
>> > >
>> > > We have a RFE feature page which documents some rule examples:
>> > >
>> > > *
>> > > https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-User-Fil
>> > > ter
>> >
>> > OK, thanks. This is helpful. So, what is the difference between these
>> > rules?
>> >
>> > -a always,exit -F path=/tmp/sessionid_test -F loginuid=-1
>> >
>> > -a always,exit -F path=/tmp/sessionid_set_test -F loginuid_set=0
>>
>> The only difference is one flag in the kernel to indicate how it was
>> invoked to be able to report when queried exactly the same way it was
>> invoked, but there is no difference in the actual behaviour of the
>> filter. This was added because of your report that "f24=0" was reported
>> instead of loginuid_set=0 for backwards compatibility.
>
> OK. Generally its bad to have 2 ways to do the same thing. People use SCAP
> content to check system configurations. If there's two ways to do the same
> thing, then someone can accidentally choose the wrong way and fail their scan.
> We run into this in the past where we allowed -a exit,always and -a
> always,exit. All the rules had to be reworked to be consistent. Therefore, I
> would recommend not using the loginuid_set option. We still get questions
> about -w /path/file -p wa vs -a always,exit -F path=/path/file -F perm=wa. But
> that one is so deeply embedded that it should not be fixed.
>
>> Going forward, the implementation of the sessionid_set field (which
>> works similarly) will not allow an unset value of sessionid since these
>> are a new addition that didn't need to accomodate backward
>> compatibility.
>
> As long as we can trigger on sessionid=-1, then we are fine.
Wait a minute ... what happened to the loginuid_set patches? Didn't
those get merged to userspace?
--
paul moore
security @ redhat
^ permalink raw reply
* Re: Question regarding ntpd
From: Paul Moore @ 2016-10-11 20:49 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit, Jarsulic, Michael [CRI], L. A. Walsh
In-Reply-To: <2633790.HIaGmAgEAo@x2>
On Tue, Oct 11, 2016 at 12:07 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Monday, October 10, 2016 2:48:23 PM EDT L. A. Walsh wrote:
>> Steve Grubb wrote:
>> > But ntpd overwhelms logs but chronyd might be marginally better. See bz
>> > https://bugzilla.redhat.com/show_bug.cgi?id=918127
>>
>> ---
>> I took a gander at said bugzilla num, and found a minor surprise in that
>> there
>> Miroslav Lichvar said:
>>
>> "You can use ntpd from the ntp package instead of chrony, it
>> shouldn't call adjtimex as often as chronyd does."
>> ---
>>
>> I.e. the exact opposite of your (Steve)'s statement. Wondered if that was
>> a misread or newer information...<*idle curiosity*>.
>>
>> Either way sounds like it would be "nice" to differentiate a "read" from
>> a "write" in this syscall if it is to be useful.
>
> I agree. But the problem with this syscall is that the operation is part of a
> data structure that is passed by address to the kernel. There currently is no
> good way to filter its uses because the audit subsystem can only look at the
> actual argument passed. I think there may be an issue opened for this on
> github.
Yep, link below:
* https://github.com/linux-audit/audit-kernel/issues/10
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Steve Grubb @ 2016-10-11 20:50 UTC (permalink / raw)
To: Paul Moore; +Cc: Richard Guy Briggs, linux-audit
In-Reply-To: <CAGH-Kguadhc66wTPus8Uoo8NHVLT1k=VK7MF3f-XCXsbJX_aKQ@mail.gmail.com>
On Tuesday, October 11, 2016 4:42:58 PM EDT Paul Moore wrote:
> On Tue, Oct 11, 2016 at 3:22 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Tuesday, October 11, 2016 2:27:54 PM EDT Richard Guy Briggs wrote:
> >> On 2016-10-11 12:40, Steve Grubb wrote:
> >> > On Monday, October 10, 2016 5:10:39 PM EDT Paul Moore wrote:
> >> > > On Mon, Oct 10, 2016 at 1:24 PM, Steve Grubb <sgrubb@redhat.com>
wrote:
> >> > > > On Thursday, August 18, 2016 2:18:55 PM EDT Richard Guy Briggs
wrote:
> >> > > >> loginuid_set support should have been added to userspace when it
> >> > > >> was
> >> > > >> added to the kernel around v3.10. Add it before we do similar for
> >> > > >> sessionID and sessionID_set.
> >> > > >
> >> > > > If this were accepted, how would this change writing rules? IOW,
> >> > > > can
> >> > > > you
> >> > > > give an example rule so we can see what this looks like?
> >> > >
> >> > > We have a RFE feature page which documents some rule examples:
> >> > >
> >> > > *
> >> > > https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-User-> >> > > Fil
> >> > > ter
> >> >
> >> > OK, thanks. This is helpful. So, what is the difference between these
> >> > rules?
> >> >
> >> > -a always,exit -F path=/tmp/sessionid_test -F loginuid=-1
> >> >
> >> > -a always,exit -F path=/tmp/sessionid_set_test -F loginuid_set=0
> >>
> >> The only difference is one flag in the kernel to indicate how it was
> >> invoked to be able to report when queried exactly the same way it was
> >> invoked, but there is no difference in the actual behaviour of the
> >> filter. This was added because of your report that "f24=0" was reported
> >> instead of loginuid_set=0 for backwards compatibility.
> >
> > OK. Generally its bad to have 2 ways to do the same thing. People use SCAP
> > content to check system configurations. If there's two ways to do the same
> > thing, then someone can accidentally choose the wrong way and fail their
> > scan. We run into this in the past where we allowed -a exit,always and -a
> > always,exit. All the rules had to be reworked to be consistent.
> > Therefore, I would recommend not using the loginuid_set option. We still
> > get questions about -w /path/file -p wa vs -a always,exit -F
> > path=/path/file -F perm=wa. But that one is so deeply embedded that it
> > should not be fixed.
> >
> >> Going forward, the implementation of the sessionid_set field (which
> >> works similarly) will not allow an unset value of sessionid since these
> >> are a new addition that didn't need to accomodate backward
> >> compatibility.
> >
> > As long as we can trigger on sessionid=-1, then we are fine.
>
> Wait a minute ... what happened to the loginuid_set patches? Didn't
> those get merged to userspace?
I'm reviewing this patch set for merging now that we are past all the 2.6 bug
fixing.
-Steve
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Paul Moore @ 2016-10-11 20:54 UTC (permalink / raw)
To: Steve Grubb; +Cc: Richard Guy Briggs, linux-audit
In-Reply-To: <12304239.24Z963VvWn@x2>
On Tue, Oct 11, 2016 at 4:50 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Tuesday, October 11, 2016 4:42:58 PM EDT Paul Moore wrote:
>> On Tue, Oct 11, 2016 at 3:22 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>> > On Tuesday, October 11, 2016 2:27:54 PM EDT Richard Guy Briggs wrote:
>> >> On 2016-10-11 12:40, Steve Grubb wrote:
>> >> > On Monday, October 10, 2016 5:10:39 PM EDT Paul Moore wrote:
>> >> > > On Mon, Oct 10, 2016 at 1:24 PM, Steve Grubb <sgrubb@redhat.com>
> wrote:
>> >> > > > On Thursday, August 18, 2016 2:18:55 PM EDT Richard Guy Briggs
> wrote:
>> >> > > >> loginuid_set support should have been added to userspace when it
>> >> > > >> was
>> >> > > >> added to the kernel around v3.10. Add it before we do similar for
>> >> > > >> sessionID and sessionID_set.
>> >> > > >
>> >> > > > If this were accepted, how would this change writing rules? IOW,
>> >> > > > can
>> >> > > > you
>> >> > > > give an example rule so we can see what this looks like?
>> >> > >
>> >> > > We have a RFE feature page which documents some rule examples:
>> >> > >
>> >> > > *
>> >> > > https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-User-> >> > > Fil
>> >> > > ter
>> >> >
>> >> > OK, thanks. This is helpful. So, what is the difference between these
>> >> > rules?
>> >> >
>> >> > -a always,exit -F path=/tmp/sessionid_test -F loginuid=-1
>> >> >
>> >> > -a always,exit -F path=/tmp/sessionid_set_test -F loginuid_set=0
>> >>
>> >> The only difference is one flag in the kernel to indicate how it was
>> >> invoked to be able to report when queried exactly the same way it was
>> >> invoked, but there is no difference in the actual behaviour of the
>> >> filter. This was added because of your report that "f24=0" was reported
>> >> instead of loginuid_set=0 for backwards compatibility.
>> >
>> > OK. Generally its bad to have 2 ways to do the same thing. People use SCAP
>> > content to check system configurations. If there's two ways to do the same
>> > thing, then someone can accidentally choose the wrong way and fail their
>> > scan. We run into this in the past where we allowed -a exit,always and -a
>> > always,exit. All the rules had to be reworked to be consistent.
>> > Therefore, I would recommend not using the loginuid_set option. We still
>> > get questions about -w /path/file -p wa vs -a always,exit -F
>> > path=/path/file -F perm=wa. But that one is so deeply embedded that it
>> > should not be fixed.
>> >
>> >> Going forward, the implementation of the sessionid_set field (which
>> >> works similarly) will not allow an unset value of sessionid since these
>> >> are a new addition that didn't need to accomodate backward
>> >> compatibility.
>> >
>> > As long as we can trigger on sessionid=-1, then we are fine.
>>
>> Wait a minute ... what happened to the loginuid_set patches? Didn't
>> those get merged to userspace?
>
> I'm reviewing this patch set for merging now that we are past all the 2.6 bug
> fixing.
Ah, nevermind ... I confused loginuid and sessionid, sorry about the confusion.
Anyway, I thought the desire for having a dedicated "is the loginuid
value set?" filter came from userspace? If not, where did this
requirement come from?
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Steve Grubb @ 2016-10-11 21:31 UTC (permalink / raw)
To: Paul Moore; +Cc: Richard Guy Briggs, linux-audit
In-Reply-To: <CAGH-KguoNFpq1kZoxn8gWLmj7Ub8jDudJ2_aS1e=xA-0xExHxg@mail.gmail.com>
On Tuesday, October 11, 2016 4:54:26 PM EDT Paul Moore wrote:
> On Tue, Oct 11, 2016 at 4:50 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Tuesday, October 11, 2016 4:42:58 PM EDT Paul Moore wrote:
> >> On Tue, Oct 11, 2016 at 3:22 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> >> > On Tuesday, October 11, 2016 2:27:54 PM EDT Richard Guy Briggs wrote:
> >> >> On 2016-10-11 12:40, Steve Grubb wrote:
> >> >> > On Monday, October 10, 2016 5:10:39 PM EDT Paul Moore wrote:
> >> >> > > On Mon, Oct 10, 2016 at 1:24 PM, Steve Grubb <sgrubb@redhat.com>
> >
> > wrote:
> >> >> > > > On Thursday, August 18, 2016 2:18:55 PM EDT Richard Guy Briggs
> >
> > wrote:
> >> >> > > >> loginuid_set support should have been added to userspace when
> >> >> > > >> it
> >> >> > > >> was
> >> >> > > >> added to the kernel around v3.10. Add it before we do similar
> >> >> > > >> for
> >> >> > > >> sessionID and sessionID_set.
> >> >> > > >
> >> >> > > > If this were accepted, how would this change writing rules? IOW,
> >> >> > > > can
> >> >> > > > you
> >> >> > > > give an example rule so we can see what this looks like?
> >> >> > >
> >> >> > > We have a RFE feature page which documents some rule examples:
> >> >> > >
> >> >> > > *
> >> >> > > https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-Us
> >> >> > > er-> >> > > Fil ter
> >> >> >
> >> >> > OK, thanks. This is helpful. So, what is the difference between
> >> >> > these
> >> >> > rules?
> >> >> >
> >> >> > -a always,exit -F path=/tmp/sessionid_test -F loginuid=-1
> >> >> >
> >> >> > -a always,exit -F path=/tmp/sessionid_set_test -F loginuid_set=0
> >> >>
> >> >> The only difference is one flag in the kernel to indicate how it was
> >> >> invoked to be able to report when queried exactly the same way it was
> >> >> invoked, but there is no difference in the actual behaviour of the
> >> >> filter. This was added because of your report that "f24=0" was
> >> >> reported
> >> >> instead of loginuid_set=0 for backwards compatibility.
> >> >
> >> > OK. Generally its bad to have 2 ways to do the same thing. People use
> >> > SCAP
> >> > content to check system configurations. If there's two ways to do the
> >> > same
> >> > thing, then someone can accidentally choose the wrong way and fail
> >> > their
> >> > scan. We run into this in the past where we allowed -a exit,always and
> >> > -a
> >> > always,exit. All the rules had to be reworked to be consistent.
> >> > Therefore, I would recommend not using the loginuid_set option. We
> >> > still
> >> > get questions about -w /path/file -p wa vs -a always,exit -F
> >> > path=/path/file -F perm=wa. But that one is so deeply embedded that it
> >> > should not be fixed.
> >> >
> >> >> Going forward, the implementation of the sessionid_set field (which
> >> >> works similarly) will not allow an unset value of sessionid since
> >> >> these
> >> >> are a new addition that didn't need to accomodate backward
> >> >> compatibility.
> >> >
> >> > As long as we can trigger on sessionid=-1, then we are fine.
> >>
> >> Wait a minute ... what happened to the loginuid_set patches? Didn't
> >> those get merged to userspace?
> >
> > I'm reviewing this patch set for merging now that we are past all the 2.6
> > bug fixing.
>
> Ah, nevermind ... I confused loginuid and sessionid, sorry about the
> confusion.
>
> Anyway, I thought the desire for having a dedicated "is the loginuid
> value set?" filter came from userspace? If not, where did this
> requirement come from?
I don't know where it came from. We have always used -1 for unset loginuid and
session id.
-Steve
^ permalink raw reply
* Re: Question regarding ntpd
From: L. A. Walsh @ 2016-10-11 21:37 UTC (permalink / raw)
To: Paul Moore; +Cc: Jarsulic, Michael [CRI], linux-audit
In-Reply-To: <CAHC9VhSbx6_9HHGMqYPE40peXjV5CQSBryPmsHHfJAyQAbz=3A@mail.gmail.com>
Paul Moore wrote:
> On Tue, Oct 11, 2016 at 12:07 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>
>> On Monday, October 10, 2016 2:48:23 PM EDT L. A. Walsh wrote:
>>
>> I.e. the exact opposite of your (Steve)'s statement. Wondered if that was
>> a misread or newer information...<*idle curiosity*>.
>>
>> Either way sounds like it would be "nice" to differentiate a "read" from
>> a "write" in this syscall if it is to be useful.
>>
>> I agree. But the problem with this syscall is that the operation
>> is part of a data structure that is passed by address to the kernel.
>> There currently is no good way to filter its uses because the audit subsystem can only look at the actual argument passed. I think there
>> may be an issue opened for this on github.
>>
>
> Yep, link below:
>
> * https://github.com/linux-audit/audit-kernel/issues/10
>
>
A parallel that may be useful -- the "file" program that ID's files,
can't just
look at the value of a field, but values pointed-to, by-a-field.
Without the ability to record the value of a "pointer", I'd think audit was
a bit hamstrung. At the destination of the pointer, one might want to
support
other data types than just 'value' (usernames, groupnames,
structures...etc).
Sad, but one might want to record an array of groups pointed to by some
field
as well.
Is it the case that nothing else in audit needs indirect information?
But as long as the data structure is defined by the kernel, I'd think it
a valid object to be able to audit...but that's my wanting flexibility.
Even wireshark/network monitoring needed to have the ability to compile
the filter into the kernel to create satifactory performance. Might not
audit
need similar?
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] Add support for loginuid_set
From: Paul Moore @ 2016-10-11 22:15 UTC (permalink / raw)
To: Steve Grubb; +Cc: Richard Guy Briggs, linux-audit
In-Reply-To: <1640839.Km0OhvKGNa@x2>
On Tue, Oct 11, 2016 at 5:31 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Tuesday, October 11, 2016 4:54:26 PM EDT Paul Moore wrote:
>> On Tue, Oct 11, 2016 at 4:50 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>> > On Tuesday, October 11, 2016 4:42:58 PM EDT Paul Moore wrote:
>> >> On Tue, Oct 11, 2016 at 3:22 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>> >> > On Tuesday, October 11, 2016 2:27:54 PM EDT Richard Guy Briggs wrote:
>> >> >> On 2016-10-11 12:40, Steve Grubb wrote:
>> >> >> > On Monday, October 10, 2016 5:10:39 PM EDT Paul Moore wrote:
>> >> >> > > On Mon, Oct 10, 2016 at 1:24 PM, Steve Grubb <sgrubb@redhat.com>
>> >
>> > wrote:
>> >> >> > > > On Thursday, August 18, 2016 2:18:55 PM EDT Richard Guy Briggs
>> >
>> > wrote:
>> >> >> > > >> loginuid_set support should have been added to userspace when
>> >> >> > > >> it
>> >> >> > > >> was
>> >> >> > > >> added to the kernel around v3.10. Add it before we do similar
>> >> >> > > >> for
>> >> >> > > >> sessionID and sessionID_set.
>> >> >> > > >
>> >> >> > > > If this were accepted, how would this change writing rules? IOW,
>> >> >> > > > can
>> >> >> > > > you
>> >> >> > > > give an example rule so we can see what this looks like?
>> >> >> > >
>> >> >> > > We have a RFE feature page which documents some rule examples:
>> >> >> > >
>> >> >> > > *
>> >> >> > > https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-Us
>> >> >> > > er-> >> > > Fil ter
>> >> >> >
>> >> >> > OK, thanks. This is helpful. So, what is the difference between
>> >> >> > these
>> >> >> > rules?
>> >> >> >
>> >> >> > -a always,exit -F path=/tmp/sessionid_test -F loginuid=-1
>> >> >> >
>> >> >> > -a always,exit -F path=/tmp/sessionid_set_test -F loginuid_set=0
>> >> >>
>> >> >> The only difference is one flag in the kernel to indicate how it was
>> >> >> invoked to be able to report when queried exactly the same way it was
>> >> >> invoked, but there is no difference in the actual behaviour of the
>> >> >> filter. This was added because of your report that "f24=0" was
>> >> >> reported
>> >> >> instead of loginuid_set=0 for backwards compatibility.
>> >> >
>> >> > OK. Generally its bad to have 2 ways to do the same thing. People use
>> >> > SCAP
>> >> > content to check system configurations. If there's two ways to do the
>> >> > same
>> >> > thing, then someone can accidentally choose the wrong way and fail
>> >> > their
>> >> > scan. We run into this in the past where we allowed -a exit,always and
>> >> > -a
>> >> > always,exit. All the rules had to be reworked to be consistent.
>> >> > Therefore, I would recommend not using the loginuid_set option. We
>> >> > still
>> >> > get questions about -w /path/file -p wa vs -a always,exit -F
>> >> > path=/path/file -F perm=wa. But that one is so deeply embedded that it
>> >> > should not be fixed.
>> >> >
>> >> >> Going forward, the implementation of the sessionid_set field (which
>> >> >> works similarly) will not allow an unset value of sessionid since
>> >> >> these
>> >> >> are a new addition that didn't need to accomodate backward
>> >> >> compatibility.
>> >> >
>> >> > As long as we can trigger on sessionid=-1, then we are fine.
>> >>
>> >> Wait a minute ... what happened to the loginuid_set patches? Didn't
>> >> those get merged to userspace?
>> >
>> > I'm reviewing this patch set for merging now that we are past all the 2.6
>> > bug fixing.
>>
>> Ah, nevermind ... I confused loginuid and sessionid, sorry about the
>> confusion.
>>
>> Anyway, I thought the desire for having a dedicated "is the loginuid
>> value set?" filter came from userspace? If not, where did this
>> requirement come from?
>
> I don't know where it came from. We have always used -1 for unset loginuid and
> session id.
Looking back through the git logs, it looks like it originally came
out of the user namespace work by Eric Biederman.
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [userspace PATCH v2 0/2] add support for more fields to the exclude filter
From: Steve Grubb @ 2016-10-11 22:56 UTC (permalink / raw)
To: Richard Guy Briggs, Paul Moore; +Cc: linux-audit
In-Reply-To: <1471545200-3742-1-git-send-email-rgb@redhat.com>
On Thursday, August 18, 2016 2:33:18 PM EDT Richard Guy Briggs wrote:
> Add userspace support for the exclude filter extension of subject
> credentials, including detection of the feature in the kernel.
>
> This set should be added after loginuid_set support and before sessionID
> user filter support to avoid merge conflicts.
>
> Richard Guy Briggs (2):
> exclude filter: add support for user filter fields
> Check exclude filter cred extension fields available in kernel
>
> trunk/docs/auditctl.8 | 2 +-
> trunk/lib/errormsg.h | 4 ++--
> trunk/lib/libaudit.c | 29 +++++++++++++++++++++++++----
> trunk/lib/libaudit.h | 3 +++
> 4 files changed, 31 insertions(+), 7 deletions(-)
Applied with some modifications as commit 1403.
-Steve
^ permalink raw reply
* Re: [userspace PATCH v2 2/3] Add sessionid_set option from kernel uapi macro AUDIT_SESSIONID_SET
From: Steve Grubb @ 2016-10-12 18:02 UTC (permalink / raw)
To: Richard Guy Briggs, Paul Moore; +Cc: linux-audit
In-Reply-To: <1471546054-4536-3-git-send-email-rgb@redhat.com>
On Thursday, August 18, 2016 2:47:33 PM EDT Richard Guy Briggs wrote:
> Add sessionid_set field option from kernel uapi macro SESSIONID_SET to
> enable specifying that sessionID is set or not in user filters.
Is there any compelling reason to support two differents fields that essentially
decide how to audit sessions? I think its a bit clunky to expect that people
write rules
-a always,exit -S open -F path=/path/file -F sessionid>0
but if you want to record daemons, then its not as simple as using -1 which is
what is in the logs and the intuitive answer. Instead you have to use a new
field.
-a always,exit -S open -F path=/path/file -F sessionid_set=0
But then you can also do the first rule as:
-a always,exit -S open -F path=/path/file -F sessionid_set=1
So, we have 2 ways of doing almost the same thing. I don't really like this.
-Steve
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> trunk/lib/fieldtab.h | 1 +
> trunk/lib/libaudit.c | 2 ++
> trunk/lib/libaudit.h | 4 ++++
> 3 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/trunk/lib/fieldtab.h b/trunk/lib/fieldtab.h
> index 84acc08..eeb951e 100644
> --- a/trunk/lib/fieldtab.h
> +++ b/trunk/lib/fieldtab.h
> @@ -34,6 +34,7 @@ _S(AUDIT_LOGINUID, "loginuid" )
> _S(AUDIT_LOGINUID_SET, "auid_set" )
> _S(AUDIT_LOGINUID_SET, "loginuid_set" )
> _S(AUDIT_SESSIONID, "sessionid" )
> +_S(AUDIT_SESSIONID_SET,"sessionid_set")
> _S(AUDIT_PERS, "pers" )
> _S(AUDIT_ARCH, "arch" )
> _S(AUDIT_MSGTYPE, "msgtype" )
> diff --git a/trunk/lib/libaudit.c b/trunk/lib/libaudit.c
> index 38776f4..5ffb720 100644
> --- a/trunk/lib/libaudit.c
> +++ b/trunk/lib/libaudit.c
> @@ -1650,6 +1650,8 @@ int audit_rule_fieldpair_data(struct audit_rule_data
> **rulep, const char *pair, case AUDIT_LOGINUID_SET:
> if(!features)
> return -30;
> + /* fallthrough */
> + case AUDIT_SESSIONID_SET:
> if (flags != AUDIT_FILTER_EXCLUDE &&
> flags != AUDIT_FILTER_USER &&
> flags != AUDIT_FILTER_EXIT)
> diff --git a/trunk/lib/libaudit.h b/trunk/lib/libaudit.h
> index 95b7a78..f8007c1 100644
> --- a/trunk/lib/libaudit.h
> +++ b/trunk/lib/libaudit.h
> @@ -381,6 +381,10 @@ extern "C" {
> #define AUDIT_SESSIONID 25
> #endif
>
> +#ifndef AUDIT_SESSIONID_SET
> +#define AUDIT_SESSIONID_SET 26
> +#endif
> +
> /* Architectures */
> #ifndef EM_ARM
> #define EM_ARM 40
^ 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