* Re: Why exclude unset auid in STIG rules
From: Warron S French @ 2016-05-11 20:43 UTC (permalink / raw)
To: Wyatt, Curtis, Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <A08CED02BC8EFC4B89CE0E0B16F995C4389B9F3C@azrc4sazmsg10.rc4s.com>
This is an interesting development. I will have to keep my eyes peeled for this thread.
Warron French, MBA, SCSA
________________________________________
From: linux-audit-bounces@redhat.com <linux-audit-bounces@redhat.com> on behalf of Wyatt, Curtis <Curtis.Wyatt@gd-ms.com>
Sent: Wednesday, May 11, 2016 4:16 PM
To: Steve Grubb
Cc: linux-audit@redhat.com
Subject: RE: Why exclude unset auid in STIG rules
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Wednesday, May 11, 2016 12:11 PM
>
> On Wednesday, May 11, 2016 06:40:52 PM Wyatt, Curtis wrote:
> > Ok, so the assumption is that daemons are not compromised?
>
> This is a complicated topic. Basically there are different levels of paranoia.
> The STIG in my mind addresses basic robustness. If you read through the
> SRG, the things its requiring are reasonable but not paranoid.
>
> I also think of it as a starting point. You can certainly tighten your system
> more than the STIG calls out. This is because you have specific knowledge of
> your operating environment and the threats that go with it. This might be for
> example knowledge about a daemon you have installed and whether or not
> its likely to be compromised. You can, with specific knowledge, add rules just
> for that daemon. But I don't think everyone wants to be held to the needs of
> a particular setup.
That makes sense, because the STIGS are applied to a wide variety of systems
operating in a variety of threat environments.
>
> I think there is a difference in what rules you would use to spot bad user
> activity vs the rules you would use for intrusion detection. (I am working on
> and testing rules for intrusion detection and they will be in an upcoming
> release.)
Love this.
> > In other words, if a daemon is compromised (or could be compromised),
> > wouldn't you want to monitor it's behavior as well?
>
> Perhaps if you feel that this is likely to happen in your environment. You may
> also wind up with so many events that you cannot see what a rogue
> employee just did right before they quit. Or so many events that you only
> can keep the last hour's logs on-hand.
Which is why I'm also exploring the best options for compressing logs. But
that's another topic for another time.
>
> I don't see anything in the SRG that leans towards IDS-like rules. Do you see
> any?
No, I do not. But now I understand all the reasoning.
As always, your very helpful, thanks.
Curtis
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* RE: Why exclude unset auid in STIG rules
From: Wyatt, Curtis @ 2016-05-11 20:16 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <4753435.QNXJuafnxx@x2>
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Wednesday, May 11, 2016 12:11 PM
>
> On Wednesday, May 11, 2016 06:40:52 PM Wyatt, Curtis wrote:
> > Ok, so the assumption is that daemons are not compromised?
>
> This is a complicated topic. Basically there are different levels of paranoia.
> The STIG in my mind addresses basic robustness. If you read through the
> SRG, the things its requiring are reasonable but not paranoid.
>
> I also think of it as a starting point. You can certainly tighten your system
> more than the STIG calls out. This is because you have specific knowledge of
> your operating environment and the threats that go with it. This might be for
> example knowledge about a daemon you have installed and whether or not
> its likely to be compromised. You can, with specific knowledge, add rules just
> for that daemon. But I don't think everyone wants to be held to the needs of
> a particular setup.
That makes sense, because the STIGS are applied to a wide variety of systems
operating in a variety of threat environments.
>
> I think there is a difference in what rules you would use to spot bad user
> activity vs the rules you would use for intrusion detection. (I am working on
> and testing rules for intrusion detection and they will be in an upcoming
> release.)
Love this.
> > In other words, if a daemon is compromised (or could be compromised),
> > wouldn't you want to monitor it's behavior as well?
>
> Perhaps if you feel that this is likely to happen in your environment. You may
> also wind up with so many events that you cannot see what a rogue
> employee just did right before they quit. Or so many events that you only
> can keep the last hour's logs on-hand.
Which is why I'm also exploring the best options for compressing logs. But
that's another topic for another time.
>
> I don't see anything in the SRG that leans towards IDS-like rules. Do you see
> any?
No, I do not. But now I understand all the reasoning.
As always, your very helpful, thanks.
Curtis
^ permalink raw reply
* Re: Audit reporting Invalid argument
From: Steve Grubb @ 2016-05-11 19:52 UTC (permalink / raw)
To: Bhagwat, Shriniketan Manjunath; +Cc: linux-audit@redhat.com
In-Reply-To: <8FC6AD31395616439ECBCD98E071A87F4BF15146@G4W3202.americas.hpqcorp.net>
On Wednesday, May 11, 2016 11:19:07 AM Bhagwat, Shriniketan Manjunath wrote:
> Thanks for the response. Your response cleared many of my doubts. I need one
> clarity on use of Linux capability CAP_AUDIT_CONTROL.
>
> My understanding is that, only root user can start/stop audit service and
> configure auditctl rules. auditctl.c and auditd.c specifically check for
> uid to be zero. The man page says CAP_AUDIT_CONTROL " Enable and disable
> kernel auditing; change auditing filter rules; retrieve auditing status and
> filtering rules." Does this mean, a process with CAP_AUDIT_CONTROL
> capability running from non root account will be able to start/stop audit
> and configure auditctl rules?
Not today. The check for uid 0 is a poor man's check for CAP_AUDIT_CONTROL. I
have not revisited the checks since allowing libcap-ng to link with other
components.
> Are there any documentation about how to use
> CAP_AUDIT_CONTROL capability and how it is related to audit?
Very little. Its mostly reading source code.
> Is it possible to suppress events for a file for the set of specific
> syscalls? Example: Using the below rule I want to suppress audit event only
> for chmod syscall for file /tmp/read_only. However below rule not only
> suppresses the audit event for chmod syscall but also for other syscalls
> for /tmp/read_only file.
>
> # auditctl -a never,exit -F arch=x86_64 -F path=/tmp/read_only -S chmod
This is how I would try to write it. If that suppresses more syscalls than
chmod and you can give us a reproducer, I think it should go in the new github
issue tracker for the kernel.
-Steve
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Monday, May 09, 2016 7:20 PM
> To: linux-audit@redhat.com
> Cc: Bhagwat, Shriniketan Manjunath <shriniketan.bhagwat@hpe.com>
> Subject: Re: Audit reporting Invalid argument
>
> On Monday, May 09, 2016 01:40:58 PM Bhagwat, Shriniketan Manjunath wrote:
> > I am trying to monitor multiple files using Linux audit. In order to
> > get better performance, I am trying to reduce number of rules. If I
> > specify more than one path field as in below example I am getting
> > "Invalid argument".
> >
> > Examle1:
> > # auditctl -a always,exit -F arch=x86_64 -F path=/home/secpack/test.c
> > -F path=/home/secpack/test -S open Error sending add rule data request
> > (Invalid argument)
> >
> > # auditctl -a always,exit -F arch=x86_64 -F path=/home/secpack/test.c
> > -F dir=/tmp/ -S open Error sending add rule data request (Invalid
> > argument)
> >
> > However, I am able to create a single rule to monitor multiple PIDs or
> > UIDs as below.
> >
> > Examle2:
> > # auditctl -a always,exit -F arch=x86_64 -F pid=3526 -F pid=3537 #
> > auditctl -a always,exit -F arch=x86_64 -F auid=0 -F auid=512 -F
> > auid=1002
>
> Which will produce no events due to the anding you mention below. Something
> cannot have both pid 3526 and 3537.
> > As per the auditctl man page, Build a rule field takes up to 64 fields
> > on a single command line. Each one must start with -F. Each field
> > equation is anded with each other to trigger an audit record. My
> > question is, 1. specify more than one path field as in example1 is valid?
>
> Nope.
>
> > 2. If not valid than how do I create single audit rule to monitor
> > multiple files/directory?
>
> They need to be separate rules. You can also recursively watch a directory
> with 'dir'
> > 3. If valid, then why "Invalid argument" is reported?
> > 4. To monitor 10 files, should 10 audit rules required?
>
> Possibly.
>
> > 5. if 10 rules are required, how to I optimize the rule for performance?
>
> The filesystem watches are very efficient. You can probably put a 100
> watches on random files and you will not be able to see any performance hit
> unless they are actually triggered. Syscall rules on the otherhand do
> affect performance.
> > My next question is does Linux audit support regular expressions?
>
> No. The kernel pretty much wants things to be numbers rather than strings.
>
> > How do I create audit rule to monitor /var/log/*.log?
>
> -a always,exit -F dir=/var/log/audit/ -F perm=wa -F key=write-audit-log
>
> -Steve
>
> > # auditctl -a always,exit -F arch=x86_64 -F path=^/var/log/*.log$ -S open
> > Error sending add rule data request (Invalid argument)
> >
> > If my questions are already documented, please guide me to the
> > documentation.
> >
> > Regards,
> > Ketan
^ permalink raw reply
* Re: Why exclude unset auid in STIG rules
From: Steve Grubb @ 2016-05-11 19:10 UTC (permalink / raw)
To: Wyatt, Curtis; +Cc: linux-audit@redhat.com
In-Reply-To: <A08CED02BC8EFC4B89CE0E0B16F995C4389B9E61@azrc4sazmsg10.rc4s.com>
On Wednesday, May 11, 2016 06:40:52 PM Wyatt, Curtis wrote:
> Ok, so the assumption is that daemons are not compromised?
This is a complicated topic. Basically there are different levels of paranoia.
The STIG in my mind addresses basic robustness. If you read through the SRG,
the things its requiring are reasonable but not paranoid.
I also think of it as a starting point. You can certainly tighten your system
more than the STIG calls out. This is because you have specific knowledge of
your operating environment and the threats that go with it. This might be for
example knowledge about a daemon you have installed and whether or not its
likely to be compromised. You can, with specific knowledge, add rules just for
that daemon. But I don't think everyone wants to be held to the needs of a
particular setup.
I think there is a difference in what rules you would use to spot bad user
activity vs the rules you would use for intrusion detection. (I am working on
and testing rules for intrusion detection and they will be in an upcoming
release.)
> In other words, if a daemon is compromised (or could be compromised),
> wouldn't you want to monitor it's behavior as well?
Perhaps if you feel that this is likely to happen in your environment. You may
also wind up with so many events that you cannot see what a rogue employee
just did right before they quit. Or so many events that you only can keep the
last hour's logs on-hand.
I don't see anything in the SRG that leans towards IDS-like rules. Do you see
any?
-Steve
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Wednesday, May 11, 2016 11:35 AM
>
> When a user logs in, the auid gets set to the uid that they used to login
> with. Daemons are not user sessions and have the loginuid set to -1. The
> auid representation is an unsigned 32 bit integer. So, -1 becomes
> 4294967295. The rules use a directive like this: -F auid>=1000 to trigger
> on user activity. It turns out that would trigger on daemons doing
> something because 4294967295 is greater than 1000. So, we exclude daemons
> because user activity is the prime target.
^ permalink raw reply
* RE: Why exclude unset auid in STIG rules
From: Wyatt, Curtis @ 2016-05-11 18:40 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <6776565.2lPe2APqfW@x2>
Ok, so the assumption is that daemons are not compromised? In other words, if a daemon is compromised (or could be compromised), wouldn't you want to monitor it's behavior as well?
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Wednesday, May 11, 2016 11:35 AM
When a user logs in, the auid gets set to the uid that they used to login with. Daemons are not user sessions and have the loginuid set to -1. The auid representation is an unsigned 32 bit integer. So, -1 becomes 4294967295. The rules use a directive like this: -F auid>=1000 to trigger on user activity. It turns out that would trigger on daemons doing something because 4294967295 is greater than 1000. So, we exclude daemons because user activity is the prime target.
^ permalink raw reply
* Re: Why exclude unset auid in STIG rules
From: Steve Grubb @ 2016-05-11 18:34 UTC (permalink / raw)
To: Wyatt, Curtis; +Cc: linux-audit@redhat.com
In-Reply-To: <A08CED02BC8EFC4B89CE0E0B16F995C4389B9DF6@azrc4sazmsg10.rc4s.com>
On Wednesday, May 11, 2016 06:28:11 PM Wyatt, Curtis wrote:
> I don't understand why the STIG audit rules have -F auid!=4294967295 in it.
> If auid is unset, why wouldn't you still want to see the events in the
> logs?
When a user logs in, the auid gets set to the uid that they used to login
with. Daemons are not user sessions and have the loginuid set to -1. The auid
representation is an unsigned 32 bit integer. So, -1 becomes 4294967295. The
rules use a directive like this: -F auid>=1000 to trigger on user activity. It
turns out that would trigger on daemons doing something because 4294967295 is
greater than 1000. So, we exclude daemons because user activity is the prime
target.
-Steve
^ permalink raw reply
* Why exclude unset auid in STIG rules
From: Wyatt, Curtis @ 2016-05-11 18:32 UTC (permalink / raw)
To: linux-audit@redhat.com
I don't understand why the STIG audit rules have -F auid!=4294967295 in it. If auid is unset, why wouldn't you still want to see the events in the logs?
Curtis
^ permalink raw reply
* aureport style output for syslog?
From: Jonathan Kelley @ 2016-05-11 16:49 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 292 bytes --]
Heya guys,
I'm looking to get the same level of verbosity as `aureport --tty` to local
syslog, /var/log/audit/audit.log shows me more PID's and stuff but not args
to commands like aureport... audispd doesn't solve this does it? Not sure
which output method pulls the args verbosity.
- Jon
[-- Attachment #1.2: Type: text/html, Size: 390 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Bug#759604: Any problem with making auditd log readable by the adm group?
From: Steve Grubb @ 2016-05-11 12:36 UTC (permalink / raw)
To: linux-audit; +Cc: intrigeri, 759604
In-Reply-To: <ad8f4cd5-a921-c66d-881b-2b00ec4f07cc@debian.org>
On Wednesday, May 11, 2016 09:55:33 AM Laurent Bigonville wrote:
> Le 09/05/16 à 21:07, intrigeri a écrit :
> > Hi,
>
> Hey,
>
> > in Debian, the convention for many log files is to make them readable
> > by members of the adm group. We're considering doing the same for the
> > auditd logs, in order to make apparmor-notify work out-of-the-box.
>
> Shouldn't apparmor-notify use the audispd to get the events instead of
> parsing directly the logs?
If this is a realtime event analysis tool, then yes. (The original question I
thought was if adding the adm group to let admins search audit logs would hurt
anything.) There are two ways that you can get the events. One way is to
enable the af_unix plugin and read off of the unix socket. The other way is to
make a plugin for which there is skeleton code here:
https://github.com/linux-audit/audit-userspace/tree/master/contrib/plugin
> I'm not objecting changing the permissions in debian, but I'm wondering
> if it shouldn't be better to do it like that, I think that the
> setroubleshoot (a SELinux troubleshooting service used in RHEL/Fedora)
> is doing it like that.
That is correct.
-Steve
^ permalink raw reply
* RE: Audit reporting Invalid argument
From: Bhagwat, Shriniketan Manjunath @ 2016-05-11 11:19 UTC (permalink / raw)
To: Steve Grubb, linux-audit@redhat.com
In-Reply-To: <10236212.OL7rdstKfk@x2>
Hi Steve,
Thanks for the response. Your response cleared many of my doubts. I need one clarity on use of Linux capability CAP_AUDIT_CONTROL.
My understanding is that, only root user can start/stop audit service and configure auditctl rules. auditctl.c and auditd.c specifically check for uid to be zero. The man page says CAP_AUDIT_CONTROL " Enable and disable kernel auditing; change auditing filter rules; retrieve auditing status and filtering rules." Does this mean, a process with CAP_AUDIT_CONTROL capability running from non root account will be able to start/stop audit and configure auditctl rules? Are there any documentation about how to use CAP_AUDIT_CONTROL capability and how it is related to audit?
Is it possible to suppress events for a file for the set of specific syscalls? Example: Using the below rule I want to suppress audit event only for chmod syscall for file /tmp/read_only. However below rule not only suppresses the audit event for chmod syscall but also for other syscalls for /tmp/read_only file.
# auditctl -a never,exit -F arch=x86_64 -F path=/tmp/read_only -S chmod
Regards,
Ketan
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Monday, May 09, 2016 7:20 PM
To: linux-audit@redhat.com
Cc: Bhagwat, Shriniketan Manjunath <shriniketan.bhagwat@hpe.com>
Subject: Re: Audit reporting Invalid argument
On Monday, May 09, 2016 01:40:58 PM Bhagwat, Shriniketan Manjunath wrote:
> I am trying to monitor multiple files using Linux audit. In order to
> get better performance, I am trying to reduce number of rules. If I
> specify more than one path field as in below example I am getting
> "Invalid argument".
>
> Examle1:
> # auditctl -a always,exit -F arch=x86_64 -F path=/home/secpack/test.c
> -F path=/home/secpack/test -S open Error sending add rule data request
> (Invalid argument)
>
> # auditctl -a always,exit -F arch=x86_64 -F path=/home/secpack/test.c
> -F dir=/tmp/ -S open Error sending add rule data request (Invalid
> argument)
>
> However, I am able to create a single rule to monitor multiple PIDs or
> UIDs as below.
>
> Examle2:
> # auditctl -a always,exit -F arch=x86_64 -F pid=3526 -F pid=3537 #
> auditctl -a always,exit -F arch=x86_64 -F auid=0 -F auid=512 -F
> auid=1002
Which will produce no events due to the anding you mention below. Something cannot have both pid 3526 and 3537.
> As per the auditctl man page, Build a rule field takes up to 64 fields
> on a single command line. Each one must start with -F. Each field
> equation is anded with each other to trigger an audit record. My
> question is, 1. specify more than one path field as in example1 is valid?
Nope.
> 2. If not valid than how do I create single audit rule to monitor
> multiple files/directory?
They need to be separate rules. You can also recursively watch a directory with 'dir'
> 3. If valid, then why "Invalid argument" is reported?
> 4. To monitor 10 files, should 10 audit rules required?
Possibly.
> 5. if 10 rules are required, how to I optimize the rule for performance?
The filesystem watches are very efficient. You can probably put a 100 watches on
random files and you will not be able to see any performance hit unless they
are actually triggered. Syscall rules on the otherhand do affect performance.
> My next question is does Linux audit support regular expressions?
No. The kernel pretty much wants things to be numbers rather than strings.
> How do I create audit rule to monitor /var/log/*.log?
-a always,exit -F dir=/var/log/audit/ -F perm=wa -F key=write-audit-log
-Steve
> # auditctl -a always,exit -F arch=x86_64 -F path=^/var/log/*.log$ -S open
> Error sending add rule data request (Invalid argument)
>
> If my questions are already documented, please guide me to the
> documentation.
>
> Regards,
> Ketan
^ permalink raw reply
* Bug#759604: Any problem with making auditd log readable by the adm group?
From: Laurent Bigonville @ 2016-05-11 7:55 UTC (permalink / raw)
To: intrigeri, 759604, linux-audit
In-Reply-To: <85futrf3ts.fsf@boum.org>
Le 09/05/16 à 21:07, intrigeri a écrit :
> Hi,
Hey,
> in Debian, the convention for many log files is to make them readable
> by members of the adm group. We're considering doing the same for the
> auditd logs, in order to make apparmor-notify work out-of-the-box.
Shouldn't apparmor-notify use the audispd to get the events instead of
parsing directly the logs?
I'm not objecting changing the permissions in debian, but I'm wondering
if it shouldn't be better to do it like that, I think that the
setroubleshoot (a SELinux troubleshooting service used in RHEL/Fedora)
is doing it like that.
Cheers,
Laurent Bigonville
^ permalink raw reply
* [PATCH] audit: add support for session ID user filter
From: Richard Guy Briggs @ 2016-05-11 2:47 UTC (permalink / raw)
To: linux-audit, linux-kernel; +Cc: Richard Guy Briggs
Define AUDIT_SESSIONID in the uapi and add support for specifying user
filters based on the session ID.
https://github.com/linux-audit/audit-kernel/issues/4
RFE: add a session ID filter to the kernel's user filter
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
Like loginuid (auid), should this have a seperate field type
(AUDIT_SESSIONID_UNDEFINED maybe?) to explicitly indicate that this
value should be undefined rather than depending on an in-band value of
-1 (or 4294967295)? If so, now would be the time to fix it.
---
include/uapi/linux/audit.h | 1 +
kernel/auditfilter.c | 2 ++
kernel/auditsc.c | 5 +++++
3 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 843540c..b6feaa7 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -251,6 +251,7 @@
#define AUDIT_OBJ_LEV_LOW 22
#define AUDIT_OBJ_LEV_HIGH 23
#define AUDIT_LOGINUID_SET 24
+#define AUDIT_SESSIONID 25 /* Session ID */
/* These are ONLY useful when checking
* at syscall exit time (AUDIT_AT_EXIT). */
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index b8ff9e1..23d076c 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -363,6 +363,7 @@ static int audit_field_valid(struct audit_entry *entry, struct audit_field *f)
case AUDIT_EXIT:
case AUDIT_SUCCESS:
case AUDIT_INODE:
+ case AUDIT_SESSIONID:
/* bit ops are only useful on syscall args */
if (f->op == Audit_bitmask || f->op == Audit_bittest)
return -EINVAL;
@@ -476,6 +477,7 @@ static struct audit_entry *audit_data_to_entry(struct audit_rule_data *data,
if (!gid_valid(f->gid))
goto exit_free;
break;
+ case AUDIT_SESSIONID:
case AUDIT_ARCH:
entry->rule.arch_f = f;
break;
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index b5daaa0..a82b1d9 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -445,6 +445,7 @@ static int audit_filter_rules(struct task_struct *tsk,
const struct cred *cred;
int i, need_sid = 1;
u32 sid;
+ unsigned int sessionid;
cred = rcu_dereference_check(tsk->cred, tsk == current || task_creation);
@@ -507,6 +508,10 @@ static int audit_filter_rules(struct task_struct *tsk,
case AUDIT_FSGID:
result = audit_gid_comparator(cred->fsgid, f->op, f->gid);
break;
+ case AUDIT_SESSIONID:
+ sessionid = audit_get_sessionid(current);
+ result = audit_comparator(sessionid, f->op, f->val);
+ break;
case AUDIT_PERS:
result = audit_comparator(tsk->personality, f->op, f->val);
break;
--
1.7.1
^ permalink raw reply related
* [PATCH] Add userspace support for session ID user filter.
From: Richard Guy Briggs @ 2016-05-11 2:36 UTC (permalink / raw)
To: linux-audit; +Cc: Richard Guy Briggs
Add support for the session ID user filter by adding the field name
"sessionid" using the kernel defined macro value AUDIT_SESSIONID.
https://github.com/linux-audit/audit-kernel/issues/4
RFE: add a session ID filter to the kernel's user filter
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
trunk/lib/fieldtab.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/trunk/lib/fieldtab.h b/trunk/lib/fieldtab.h
index bf48c95..88cf8ea 100644
--- a/trunk/lib/fieldtab.h
+++ b/trunk/lib/fieldtab.h
@@ -31,6 +31,7 @@ _S(AUDIT_SGID, "sgid" )
_S(AUDIT_FSGID, "fsgid" )
_S(AUDIT_LOGINUID, "auid" )
_S(AUDIT_LOGINUID, "loginuid" )
+_S(AUDIT_SESSIONID, "sessionid" )
_S(AUDIT_PERS, "pers" )
_S(AUDIT_ARCH, "arch" )
_S(AUDIT_MSGTYPE, "msgtype" )
--
1.7.1
^ permalink raw reply related
* Re: ANN: Linux Audit is now on GitHub
From: F Rafi @ 2016-05-11 1:04 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit@redhat.com
In-Reply-To: <1887363.RWvYDzSsYd@sifl>
[-- Attachment #1.1: Type: text/plain, Size: 2060 bytes --]
This is really great!! 🙌
Thanks
Farhan
On Tuesday, May 10, 2016, Paul Moore <pmoore@redhat.com> wrote:
> I'd like to announce that the Linux Audit project is now on GitHub:
>
> -> https://github.com/linux-audit
>
> We've already migrated much of the information on Steve Grubb's Red Hat
> people
> page, and the remaining items will be migrated soon. The move to GitHub
> allows us to consolidate audit development in one place while at the same
> time
> supporting issue tracking and documentation/wikis.
>
> The Linux Audit Project currently consists of four different repositories,
> each is described below:
>
> * audit-documentation
> This repository holds various audit resources, but the majority of the
> information is contained in the associated wiki. The information that
> used to
> reside on Steve's Red Hat people page now resides here.
>
> * audit-userspace
> This is a mirror of the userspace subversion repository. Those who are
> interested in submitting patches should continue to submit patches via the
> mailing list.
>
> * audit-kernel
> This is a mirror of the kernel repository. This repository will be used to
> track upstream bugs and feature requests (via GitHub issues), and the wiki
> will be used to document and track kernel development efforts. Those are
> are
> interested in submitting patches should continue to submit patches via the
> mailing list.
>
> * audit-testsuite
> This is a relatively new project, designed to be similar to the selinux-
> testsuite project, and intended to be a relatively simple regression test
> for
> the kernel. If anyone is interested in contributing, patches are welcome
> via
> the mailing list or GitHub pull requests!
>
> If you have any questions about this transition, or any of the repositories
> above, please send them to the mailing list.
>
> --
> paul moore
> security @ redhat
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com <javascript:;>
> https://www.redhat.com/mailman/listinfo/linux-audit
>
[-- Attachment #1.2: Type: text/html, Size: 2591 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Audit reporting misses AUDIT_SOCKETCALL (1306) message when 32-bit binary is running form 64-bit machine.
From: Paul Moore @ 2016-05-10 22:20 UTC (permalink / raw)
To: Kangkook Jee; +Cc: linux-audit
In-Reply-To: <6BC76399-5C34-4772-8E02-6CDE6F2E8CC9@gmail.com>
On Tue, May 10, 2016 at 5:02 PM, Kangkook Jee <aixer77@gmail.com> wrote:
> Dear Paul,
>
> As you requested, I installed ubuntu 14.04 system for both 32bit and 64bit systems and update their kernel version to the latest and I still see the problem occurring.
Hello,
Thank you for reporting this problem and your help in reproducing the
problem on a system with similar kernels. I'm not sure how quickly we
will be able to address this issue, but I've added it to our issue
tracker, you can follow the progress at the link below.
* https://github.com/linux-audit/audit-kernel/issues/14
--
paul moore
www.paul-moore.com
^ permalink raw reply
* ANN: Linux Audit is now on GitHub
From: Paul Moore @ 2016-05-10 22:02 UTC (permalink / raw)
To: linux-audit
I'd like to announce that the Linux Audit project is now on GitHub:
-> https://github.com/linux-audit
We've already migrated much of the information on Steve Grubb's Red Hat people
page, and the remaining items will be migrated soon. The move to GitHub
allows us to consolidate audit development in one place while at the same time
supporting issue tracking and documentation/wikis.
The Linux Audit Project currently consists of four different repositories,
each is described below:
* audit-documentation
This repository holds various audit resources, but the majority of the
information is contained in the associated wiki. The information that used to
reside on Steve's Red Hat people page now resides here.
* audit-userspace
This is a mirror of the userspace subversion repository. Those who are
interested in submitting patches should continue to submit patches via the
mailing list.
* audit-kernel
This is a mirror of the kernel repository. This repository will be used to
track upstream bugs and feature requests (via GitHub issues), and the wiki
will be used to document and track kernel development efforts. Those are are
interested in submitting patches should continue to submit patches via the
mailing list.
* audit-testsuite
This is a relatively new project, designed to be similar to the selinux-
testsuite project, and intended to be a relatively simple regression test for
the kernel. If anyone is interested in contributing, patches are welcome via
the mailing list or GitHub pull requests!
If you have any questions about this transition, or any of the repositories
above, please send them to the mailing list.
--
paul moore
security @ redhat
^ permalink raw reply
* Re: Audit reporting misses AUDIT_SOCKETCALL (1306) message when 32-bit binary is running form 64-bit machine.
From: Kangkook Jee @ 2016-05-10 21:02 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
In-Reply-To: <CAGH-KgsqSVR-DBO1Ffm9UCnCnGgr+hkWa7eeJ9_AWHAWXnjQFw@mail.gmail.com>
Dear Paul,
As you requested, I installed ubuntu 14.04 system for both 32bit and 64bit systems and update their kernel version to the latest and I still see the problem occurring.
Here’s how I reproduced the problem. Currently, kernel version for those systems are
white-lab0@ubuntu-32bit:~/32bit_test$ uname -a
Linux ubuntu-32bit 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:45:15 UTC 2015 i686 i686 i686 GNU/Linux
white-lab0@ubuntu-64bit:/tmp$ uname -a
Linux ubuntu-64bit 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
I ran the same experiment and captured logs from both system.
* Ubuntu 64 bit system
white-lab0@ubuntu-64bit:/tmp$ grep -A3 -e "syscall=102.*a0=3" /tmp/audit.log
...
MSG (1300): audit(1462912875.581:31612): arch=40000003 syscall=102 success=yes exit=0 a0=3 a1=ff9ec540 a2=f7599000 a3=ffffffff items=0 ppid=2193 pid=2433 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts4 ses=2 comm="conn" exe="/home/white-lab0/32bit_test/conn" key=(null)
MSG (1306): audit(1462912875.581:31612): saddr=020000357F0001010000000000000000
MSG (1327): audit(1462912875.581:31612): proctitle="-bash"
MSG (1320): audit(1462912875.581:31612):
...
* Ubuntu 32 bit system
white-lab0@ubuntu-32bit:~/32bit_test$ grep -A4 -n -e "syscall=102.*a0=3" /tmp/audit.log
--
2395:MSG (1300): audit(1462913073.096:5616): arch=40000003 syscall=102 success=yes exit=0 a0=3 a1=bff7f4d0 a2=b75a6000 a3=ffffffff items=0 ppid=3486 pid=3543 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts4 ses=2 comm="conn" exe="/home/white-lab0/32bit_test/conn" key=(null)
2396-MSG (1304): audit(1462913073.096:5616): nargs=3 a0=4 a1=8dc37a0 a2=10
2397-MSG (1306): audit(1462913073.096:5616): saddr=020000357F0001010000000000000000
2398-MSG (1327): audit(1462913073.096:5616): proctitle="-bash"
2399-MSG (1320): audit(1462913073.096:5616):
--
As you see from above, while Ubuntu 32 bit system could see 1304 messages, Ubuntu 64bit system is still failing to received the message.
Please take a look at this issue and please let me know if you need any more information.
Thanks for your help in advance
Regards, Kangkook
> On May 9, 2016, at 5:03 PM, Paul Moore <pmoore@redhat.com> wrote:
>
> Performing the same test with a 32-bit binary on both a 32-bit and
> 64-bit host using the same, current kernel version would be helpful.
>
>
> On Mon, May 9, 2016 at 4:54 PM, Kangkook Jee <aixer77@gmail.com> wrote:
>> Dear Paul,
>>
>> First of all, thanks a lot for your response.
>>
>> I think the problem that I have is that I can’t see expected message (which is AUDIT_SOCKCALL) from 64-bit kernel when it runs 32-bit binary that issues connect() system call.
>> Regarding 32-bit system that I showed from the previous mail is just for a reference case to show normal behavior. For whatever kernel version, I’m pretty sure it will produce a complete set of all 4 messages (1300, 1306, 1304, 1320).
>>
>> I think can run the same experiment from relatively newer version of kernel, but if what I see is true at least for a subset of kernel versions , I think it is still a problem.
>> If you still have any specific item that you want me to perform, please let me know.
>>
>> Thanks for your help again!
>>
>> Regards, Kangkook
>>
>>
>>> On May 9, 2016, at 4:15 PM, Paul Moore <paul@paul-moore.com> wrote:
>>>
>>> Without looking at the code too closely, have you tried doing these
>>> tests on the same kernel version, preferably a current kernel? The
>>> test below is comparing 3.13 to 2.6.18 which might not be a valid
>>> comparison, and even 3.13 is a few years old.
>>>
>>> On Fri, May 6, 2016 at 6:49 PM, Kangkook Jee <aixer77@gmail.com> wrote:
>>>> Hi, all
>>>>
>>>>
>>>> This is a bump.
>>>> Could any of you have a look into this case?
>>>>
>>>> Regards, Kangkook
>>>>
>>>> On May 4, 2016, at 5:21 PM, Kangkook Jee <aixer77@gmail.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> We are running a 32-bit program on a 64-bit machine (Ubuntu 14.04,
>>>> 3.13.0-57-generic kernel - x86_64) typically issuing network related system
>>>> calls which, in turn, would invoke the one of socketcall() system call.
>>>>
>>>> However, an expected audit raw message -- AUDIT_SOCKETCALL (1304) is
>>>> reported when we run the 32-bit binary from a 64-bit machine. The following
>>>> is the raw audit messages captured for connect() system from a 64-bit
>>>> machine running 32-bit binary.
>>>>
>>>> MSG (1300): audit(1462273146.351:21482453): arch=40000003 syscall=102
>>>> success=no exit=-2 a0=3 a1=ffe38240 a2=f7751000 a3=4 items=0 ppid=10269
>>>> pid=10755 auid=19287 uid=19287 gid=19287 euid=19287 suid=19287 fsuid=19287
>>>> egid=19287 sgid=19287 fsgid=19287 tty=pts16 ses=12 comm="conn"
>>>> exe="/home/accountname/32bit_test/conn" key=(null)
>>>> MSG (1306): audit(1462273146.351:21482453):
>>>> saddr=01002F7661722F72756E2F6E7363642F736F636B657400B7160054B7160054B71600130000001300000004000000010000000100000000000000000000000000000028791A0028791A000500000000100000CD5D77F734D676F748A15BF7D4811A00E82C0000A858000006000000
>>>> MSG (1320): audit(1462273146.351:21482453):
>>>>
>>>> And this is the raw audit message captured from a 32-bit machine (CentOS 5
>>>> 2.6.18-404.el5 i686) running 32-bit binary.
>>>>
>>>> MSG (1300): audit(1462289555.340:807319): arch=40000003 syscall=102
>>>> success=yes exit=0 a0=3 a1=bfef25b0 a2=67dff4 a3=816840 items=0 ppid=28509
>>>> pid=28560 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
>>>> tty=pts2 ses=10 comm="conn" exe="/home/kjee/conn"
>>>> subj=user_u:system_r:unconfined_t:s0 key=(null)
>>>> MSG (1306): audit(1462289555.340:807319):
>>>> saddr=020000358A0F6D630000000000000000000000000000000000000000
>>>> MSG (1304): audit(1462289555.340:807319): nargs=3 a0=4 a1=859c4b8 a2=1c
>>>> MSG (1320): audit(1462289555.340:807319):•
>>>>
>>>> I hope you to catch the difference. While the first case does not report
>>>> AUDIT_SOCKETCALL (1304) event, but the second case report the entry
>>>> providing the list of arguments starting with "nargs=".
>>>>
>>>> Could you tell me whether this is an expected behavior? Or is there any way
>>>> that I can fix it?
>>>>
>>>> I'm attaching the source code of the test program (conn.c) and summarizes
>>>> the procedure to reproduce the problem. If you have any difficulty producing
>>>> the issue, please let me know.
>>>>
>>>> 1. we added the following the audit rules from a 64-bit machine. It is
>>>> intended to capture events from both 64-bit and 32-bit system calls.
>>>>
>>>> /sbin/auditctl -a exit,always -F arch=b64 -S clone -S close -S creat -S dup
>>>> -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S
>>>> rename -S renameat -S unlink -S unlinkat -S vfork -S 288 -S accept -S
>>>> connect -S listen -S socket -S socketpair
>>>> /sbin/auditctl -a exit,always -F arch=b32 -S clone -S close -S creat -S dup
>>>> -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S
>>>> rename -S renameat -S unlink -S unlinkat -S vfork
>>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=3 # connect
>>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=4 # listen
>>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=5 # accept
>>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=8 # socketpair
>>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=18 # accept4
>>>>
>>>> $ sudo auditctl -l
>>>> LIST_RULES: exit,always arch=3221225534 (0xc000003e)
>>>> syscall=open,close,dup,dup2,socket,connect,accept,listen,socketpair,clone,fork,vfork,execve,exit,rename,creat,unlink,exit_group,openat,unlinkat,renameat,accept4,dup3
>>>> LIST_RULES: exit,always arch=1073741827 (0x40000003)
>>>> syscall=exit,fork,open,close,creat,unlink,execve,rename,dup,dup2,clone,vfork,exit_group,openat,unlinkat,renameat,dup3
>>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=1 (0x1)
>>>> syscall=socketcall
>>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=3 (0x3)
>>>> syscall=socketcall
>>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=4 (0x4)
>>>> syscall=socketcall
>>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=5 (0x5)
>>>> syscall=socketcall
>>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=8 (0x8)
>>>> syscall=socketcall
>>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=18 (0x12)
>>>> syscall=socketcall
>>>>
>>>> 2. We added the following the audit rules from a 32-bit machine.
>>>>
>>>> /sbin/auditctl -a exit,always -F arch=b32 -S clone -S close -S creat -S dup
>>>> -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S
>>>> rename -S renameat -S unlink -S unlinkat -S vfork
>>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=2
>>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=3
>>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=4
>>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=5
>>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=8
>>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=18
>>>>
>>>> LIST_RULES: exit,always arch=1073741827 (0x40000003)
>>>> syscall=exit,fork,open,close,creat,unlink,execve,rename,dup,dup2,clone,vfork,exit_group,openat,unlinkat,renameat,dup3
>>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=1 (0x1)
>>>> syscall=socketcall
>>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=2 (0x2)
>>>> syscall=socketcall
>>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=3 (0x3)
>>>> syscall=socketcall
>>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=4 (0x4)
>>>> syscall=socketcall
>>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=5 (0x5)
>>>> syscall=socketcall
>>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=8 (0x8)
>>>> syscall=socketcall
>>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=18 (0x12)
>>>> syscall=socketcall
>>>>
>>>> 3. Build conn.c source and running
>>>> conn.c is a simple connection client.
>>>> $ cc -o conn conn.c
>>>> $ ./conn <remote_host> <port>
>>>>
>>>> Example run
>>>>
>>>> $ ./conn localhost 22
>>>> $ Please enter the message: this is random message
>>>> SSH-2.0-OpenSSH_4.3
>>>>
>>>> Thanks a lot for your help in advance.
>>>>
>>>>
>>>> <conn.c>
>>>>
>>>>
>>>>
>>>> --
>>>> Linux-audit mailing list
>>>> Linux-audit@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/linux-audit
>>>
>>>
>>>
>>> --
>>> paul moore
>>> www.paul-moore.com
>>
>>
>> --
>> Linux-audit mailing list
>> Linux-audit@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-audit
>
>
>
> --
> paul moore
> security @ redhat
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* RE: audit-tools and SUDO
From: Warron S French @ 2016-05-10 17:46 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <3294586.6i81xjxGkV@x2>
OK, thank you.
I will do/try that and see if it makes a difference and then report-back to close out this thread.
Thanks Steve,
Warron French, MBA, SCSA
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Tuesday, May 10, 2016 11:45 AM
To: Warron S French <warron.s.french@aero.org>
Cc: linux-audit@redhat.com
Subject: Re: audit-tools and SUDO
On Tuesday, May 10, 2016 03:25:36 PM Warron S French wrote:
> > The lab works as expected, but my production environment does not.
> > %-/
>
> I would start by checking that events are coming out of the remote systems.
> You can use tcpdump port 60 on the clients. After confirming that, do
> the same on the server to see if events are getting there. Then look
> in syslog for anything that might give a clue. And then you can also
> tail -f /var/log/audit/audit.log to see if things are getting written to disk.
>
> \\ Steve, I know that I am receiving inputs to the server; because I
> can see events that I am purposely triggering based on 2 rules that I
> added and know how to cause an event; it is just that the node=client1
> (for example) aren't being sent along with the line being recorded.
> Does this troubleshooting step still make sense anyway?
No. If you are getting events at the server and audispd.conf has name_format= hostname, it should be working.
If this was set after the audit daemon on the clients started, then you need to restart the audit daemon for the name to take effect. As written, it collects the name one time at start up and uses it in all future events. This could be changed but that is how its doing today.
If you restart auditd on a non-systemd OS, this will cause the admin's auid to get stuck into the audit daemon's task structure and will cause problems. So, the cleanest thing to do is reboot the work station so that audispd has the hostname and your auid is not in daemons.
-Steve
^ permalink raw reply
* Re: audit-tools and SUDO
From: Steve Grubb @ 2016-05-10 15:45 UTC (permalink / raw)
To: Warron S French; +Cc: linux-audit@redhat.com
In-Reply-To: <BY1PR09MB088709DF1304A0853C895960C7710@BY1PR09MB0887.namprd09.prod.outlook.com>
On Tuesday, May 10, 2016 03:25:36 PM Warron S French wrote:
> > The lab works as expected, but my production environment does not. %-/
>
> I would start by checking that events are coming out of the remote systems.
> You can use tcpdump port 60 on the clients. After confirming that, do the
> same on the server to see if events are getting there. Then look in syslog
> for anything that might give a clue. And then you can also tail -f
> /var/log/audit/audit.log to see if things are getting written to disk.
>
> \\ Steve, I know that I am receiving inputs to the server; because I can see
> events that I am purposely triggering based on 2 rules that I added and
> know how to cause an event; it is just that the node=client1 (for example)
> aren't being sent along with the line being recorded. Does this
> troubleshooting step still make sense anyway?
No. If you are getting events at the server and audispd.conf has name_format=
hostname, it should be working.
If this was set after the audit daemon on the clients started, then you need
to restart the audit daemon for the name to take effect. As written, it
collects the name one time at start up and uses it in all future events. This
could be changed but that is how its doing today.
If you restart auditd on a non-systemd OS, this will cause the admin's auid to
get stuck into the audit daemon's task structure and will cause problems. So,
the cleanest thing to do is reboot the work station so that audispd has the
hostname and your auid is not in daemons.
-Steve
^ permalink raw reply
* RE: audit-tools and SUDO
From: Warron S French @ 2016-05-10 15:25 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <2247443.0y4SDndMu0@x2>
Replies are inline.
Warron French, MBA, SCSA
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Tuesday, May 10, 2016 10:31 AM
To: Warron S French <warron.s.french@aero.org>
Cc: linux-audit@redhat.com; burn@swtf.dyndns.org
Subject: Re: audit-tools and SUDO
On Tuesday, May 10, 2016 01:44:50 PM Warron S French wrote:
> > > I have two problems though; and they seem somewhat minor:
> > >
> > > 1. The audit events being captured don’t seem to be tied to any
> > > given node (so that I can perform ausearch --node hostName, or
> > > aureport), that’s the first issue.
> >
> >
> > What have you set the configuration parameter 'name_format'
> > in /etc/audit/auditd.conf to?
> >
> > One assumes you may want to set
> > name_format = fqd
> > or
> > name_format = hostname
> >
> > After the change on each host, don't forget to reload the
> > configuration with either a sighup on the auditd process or just
> > restart the service.
>
> On the lab-clients ends:
> In, and ONLY IN, my /etc/audisp/audispd.conf file have I set
> name_format=hostname, where hostname is a literal string of 'hostname'
> not THE hostname;
This is correct. Did you set remote_server in /etc/audisp/audisp-remote.conf?
\\Yes, the /etc/audisp/audisp-remote.conf file does have remote_server = <myServer1>.
> there is no name_format reference in any other file on my lab-client
> machines under the directory /etc/audisp/ anywhere. Also on my
> lab-client machines in the /etc/audit/auditd.conf file the name_format
> variable is set to NONE.
>
> On the lab-server end:
> In the only file that I modified, /etc/audit/auditd.conf, the only
> variables that I altered were:
> tcp_listen_port = 60
> tcp_client_ports = 60
> use_libwrap = no (because I am using iptables)
You would want to set name_format. This way the local events on the aggregating server have the same format.
\\So, Steve, I will set name_format, on the server, to 'hostname' explicitly without the quotes then - thank you.
> The lab works as expected, but my production environment does not. %-/
I would start by checking that events are coming out of the remote systems.
You can use tcpdump port 60 on the clients. After confirming that, do the same
on the server to see if events are getting there. Then look in syslog for
anything that might give a clue. And then you can also tail -f
/var/log/audit/audit.log to see if things are getting written to disk.
\\ Steve, I know that I am receiving inputs to the server; because I can see events that I am purposely triggering based on 2 rules that I added and know how to cause an event; it is just that the node=client1 (for example) aren't being sent along with the line being recorded. Does this troubleshooting step still make sense anyway?
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: audit-tools and SUDO
From: Steve Grubb @ 2016-05-10 14:31 UTC (permalink / raw)
To: Warron S French; +Cc: linux-audit@redhat.com
In-Reply-To: <BY1PR09MB088792A33B5B6AAFF5D8AE48C7710@BY1PR09MB0887.namprd09.prod.outlook.com>
On Tuesday, May 10, 2016 01:44:50 PM Warron S French wrote:
> > > I have two problems though; and they seem somewhat minor:
> > >
> > > 1. The audit events being captured don’t seem to be tied to any
> > > given node (so that I can perform ausearch --node hostName, or
> > > aureport), that’s the first issue.
> >
> >
> > What have you set the configuration parameter 'name_format'
> > in /etc/audit/auditd.conf to?
> >
> > One assumes you may want to set
> > name_format = fqd
> > or
> > name_format = hostname
> >
> > After the change on each host, don't forget to reload the
> > configuration with either a sighup on the auditd process or just restart
> > the service.
>
> On the lab-clients ends:
> In, and ONLY IN, my /etc/audisp/audispd.conf file have I set
> name_format=hostname, where hostname is a literal string of 'hostname' not
> THE hostname;
This is correct. Did you set remote_server in /etc/audisp/audisp-remote.conf?
> there is no name_format reference in any other file on my
> lab-client machines under the directory /etc/audisp/ anywhere. Also on my
> lab-client machines in the /etc/audit/auditd.conf file the name_format
> variable is set to NONE.
>
> On the lab-server end:
> In the only file that I modified, /etc/audit/auditd.conf, the only variables
> that I altered were:
> tcp_listen_port = 60
> tcp_client_ports = 60
> use_libwrap = no (because I am using iptables)
You would want to set name_format. This way the local events on the
aggregating server have the same format.
> The lab works as expected, but my production environment does not. %-/
I would start by checking that events are coming out of the remote systems.
You can use tcpdump port 60 on the clients. After confirming that, do the same
on the server to see if events are getting there. Then look in syslog for
anything that might give a clue. And then you can also tail -f
/var/log/audit/audit.log to see if things are getting written to disk.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: How to Audit ssh Commands --> wget, scp
From: Steve Grubb @ 2016-05-10 13:55 UTC (permalink / raw)
To: varun gulati; +Cc: linux-audit@redhat.com
In-Reply-To: <2052092882.1384284.1462888019553.JavaMail.yahoo@mail.yahoo.com>
On Tuesday, May 10, 2016 01:46:59 PM varun gulati wrote:
> Thanks for the response. We are not using web services to provide/serve this
> file.
You have to be. :-) If someone on another system uses wget to access a file on
the system you care about, something is serving the file on port 80. Maybe you
need to do a netstat -tanp to see what is serving the file.
> Its simply kept at a particular folder which people download using
> wget. Here is the wget command users are using to download the file from
> the different hosts: wget --no-cache
> http://servername/app/name/dist/xyz.zip
> Still no logging is happening :(Need your expert help with this.
>
> > Thanks for your suggestions. We incorporated the below rule for
> > auditctl which you suggested, but unfortunately it didn't helped. We
> > are able to log the wget from the same server but unfortunately it is
> > still not logging from a different host:
> >
> > -a always,exit -F path=/a/b/c/xyz.log -F perm=r -F key=log-access
> >
> > This is how the file looks like:
> >
> > -w /a/b/c/xyz.log -p rwxa -k Audit
This should get you all access of that file if you are on a distribution that
enables the audit system unless you are on a special file system like NFS which
is not supported by the audit system.
> > -w /usr/bin/wget -p rwxa -k Audit
This will show execution of wget on the server, not the client.
> > -a always,exit -F path=/a/b/c/xyz.log -F perm=r -F key=log-access
This is roughly the same as the first above just expressed in the longer form.
> > But nothing is logging the Audit when wget is called from any other
> > host. Can you please assist on this further.
>
> If you are using a web service (httpd, etc) to service your files, then
> make it authenticated and have it log.
I agree on this point. Auditd will tell you that the web server accessed the
file but not who is getting it. Only the web server can know that.
-Steve
> > On Tuesday, 10 May 2016 1:32 AM, Steve Grubb <sgrubb@redhat.com>
> > wrote:
> >
> > On Monday, May 09, 2016 04:13:19 PM varun gulati wrote:
> > > Hi Team,
> > > We have requirement where we have to monitor and log any read
> >
> > operations
> >
> > > performed on a file. e.g. /a/b/c/xyz.log
> >
> > -a always,exit -F path=/a/b/c/xyz.log -F perm=r -F key=log-access
> >
> > > This file is usually copied and downloaded by many users using
> >
> > various
> >
> > > operations, like, wget, ssh, jsp Download link provided. These
> >
> > commands are
> >
> > > fired from different hosts. With the auditd we want to create a rule
> >
> > which
> >
> > > auditctl can leverage to log the User ID that is reading (and
> >
> > copying) it
> >
> > > from a different host may be.
> >
> > You will get the local auid/uid that the kernel sees when the request
> > triggers
> > the rule. There is nothing more that can be done from the audit
> > system.
> >
> > -Steve
> >
> > > I have gone through many of the rules but didn't find anything
> >
> > fruitful as
> >
> > > such (which logs wget, scp commands from remote hosts). May be I am
> >
> > missing
> >
> > > on something. Since it is a very crucial requirement, appreciate
> >
> > your
> >
> > > guidance and directions with this. Let me know in case you require
> >
> > any
> >
> > > further information from my end. Many thanks in advance.
> > >
> > >
> > >
> > > Thanks and Regards,Varun Gulati
> >
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* RE: audit-tools and SUDO
From: Warron S French @ 2016-05-10 13:44 UTC (permalink / raw)
To: Steve Grubb, linux-audit@redhat.com, burn@swtf.dyndns.org
In-Reply-To: <4636570.EUPpVmsaCN@x2>
Replies are in-line with responses.
Warron French, MBA, SCSA
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Tuesday, May 10, 2016 9:25 AM
To: linux-audit@redhat.com; burn@swtf.dyndns.org
Cc: Warron S French <warron.s.french@aero.org>
Subject: Re: audit-tools and SUDO
On Tuesday, May 10, 2016 10:52:21 PM Burn Alting wrote:
> On Tue, 2016-05-10 at 12:31 +0000, Warron S French wrote:
> > Good morning everyone,
> >
> >
> >
> > I am working on an environment where I have managed to get
> > centralized audit logging to work – roughly 95% properly on six (6)
> > CentOS-6.7 workstations and a single (1) CentOS-6.7 server.
> >
> >
> >
> > I have two problems though; and they seem somewhat minor:
> >
> >
> >
> > 1. The audit events being captured don’t seem to be tied to any
> > given node (so that I can perform ausearch --node hostName, or
> > aureport), that’s the first issue.
>
> What have you set the configuration parameter 'name_format'
> in /etc/audit/auditd.conf to?
>
> One assumes you may want to set
> name_format = fqd
> or
> name_format = hostname
>
> After the change on each host, don't forget to reload the
> configuration with either a sighup on the auditd process or just restart the service.
On the lab-clients ends:
In, and ONLY IN, my /etc/audisp/audispd.conf file have I set name_format=hostname, where hostname is a literal string of 'hostname' not THE hostname; there is no name_format reference in any other file on my lab-client machines under the directory /etc/audisp/ anywhere. Also on my lab-client machines in the /etc/audit/auditd.conf file the name_format variable is set to NONE.
On the lab-server end:
In the only file that I modified, /etc/audit/auditd.conf, the only variables that I altered were:
tcp_listen_port = 60
tcp_client_ports = 60
use_libwrap = no (because I am using iptables)
The lab works as expected, but my production environment does not. %-/
This would set it for the local logs. And you would need to do this on the server that is aggregating the logs. (I think I forgot to mention that last
week.) But for the workstations, you have to set name_format in audispd.conf.
> > 2. The second issue is that I need to configure sudo to enable my
> > Special Security Team with the ability to perform their duties using
> > the aureport and the ausearch commands, but I get an error that
> > appears to be based on permissions.
>
> I recommend you show the command and resultant error in situations
> like this. That way we can provide a more informed response.
One approach some people take is to use the log_group setting in auditd.conf.
If there is a group that the security people belong to that others don't, then using that group name for log_group this is the easiest way and exactly why this option exists.
-Steve
Thanks for this Steve, I am going to engage the Special Security Team, because I have thought of another approach - making the auditors group become a local (/etc/group) file entry instead of using 389-ds to manage this association; that way it will always be reliable.
> > I am hoping that you guys can steer me in the correct direction; and
> > I can update my documentation to be even a little more thorough.
> >
> > Scenario2, might be more of a membership issue now that I think
> > about it; so please disregard as I think this is some weird 389-ds issue.
> >
> > I am hoping though that someone can suggest a reason why, when I
> > look directly at the content of the /var/log/audit/audit.log I am
> > not see any references to node=hostname1, hostname2 .. hostnameN?
> > Maybe I did misconfigure something, but I followed my own instructions to the “T”
> > and they didn’t produce this issue.
> >
> >
> >
> >
> >
> >
> >
> > Thank you in advance for your precious time sincerely,
> >
> >
> >
> > Warron French, MBA, SCSA
> >
> >
> > --
> > 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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: How to Audit ssh Commands --> wget, scp
From: varun gulati @ 2016-05-10 13:46 UTC (permalink / raw)
To: burn@swtf.dyndns.org; +Cc: linux-audit@redhat.com
In-Reply-To: <1462885014.3439.18.camel@swtf.swtf.dyndns.org>
[-- Attachment #1.1: Type: text/plain, Size: 2960 bytes --]
Hi Team,
Thanks for the response. We are not using web services to provide/serve this file. Its simply kept at a particular folder which people download using wget.
Here is the wget command users are using to download the file from the different hosts:
wget --no-cache http://servername/app/name/dist/xyz.zip
Still no logging is happening :(Need your expert help with this.
Thanks and Regards,Varun Gulati
On Tuesday, 10 May 2016 6:26 PM, Burn Alting <burn@swtf.dyndns.org> wrote:
On Tue, 2016-05-10 at 10:39 +0000, varun gulati wrote:
>
>
> Hi Steve,
>
>
> Thanks for your suggestions. We incorporated the below rule for
> auditctl which you suggested, but unfortunately it didn't helped. We
> are able to log the wget from the same server but unfortunately it is
> still not logging from a different host:
>
>
> -a always,exit -F path=/a/b/c/xyz.log -F perm=r -F key=log-access
>
>
> This is how the file looks like:
>
>
> -w /a/b/c/xyz.log -p rwxa -k Audit
>
>
> -w /usr/bin/wget -p rwxa -k Audit
>
>
> -a always,exit -F path=/a/b/c/xyz.log -F perm=r -F key=log-access
>
>
> But nothing is logging the Audit when wget is called from any other
> host. Can you please assist on this further.
If you are using a web service (httpd, etc) to service your files, then
make it authenticated and have it log.
>
>
> Thanks and Regards,
> Varun Gulati
>
>
>
>
>
> On Tuesday, 10 May 2016 1:32 AM, Steve Grubb <sgrubb@redhat.com>
> wrote:
>
>
>
> On Monday, May 09, 2016 04:13:19 PM varun gulati wrote:
> > Hi Team,
> > We have requirement where we have to monitor and log any read
> operations
> > performed on a file. e.g. /a/b/c/xyz.log
>
> -a always,exit -F path=/a/b/c/xyz.log -F perm=r -F key=log-access
>
>
> > This file is usually copied and downloaded by many users using
> various
> > operations, like, wget, ssh, jsp Download link provided. These
> commands are
> > fired from different hosts. With the auditd we want to create a rule
> which
> > auditctl can leverage to log the User ID that is reading (and
> copying) it
> > from a different host may be.
>
> You will get the local auid/uid that the kernel sees when the request
> triggers
> the rule. There is nothing more that can be done from the audit
> system.
>
> -Steve
>
>
>
> > I have gone through many of the rules but didn't find anything
> fruitful as
> > such (which logs wget, scp commands from remote hosts). May be I am
> missing
> > on something. Since it is a very crucial requirement, appreciate
> your
> > guidance and directions with this. Let me know in case you require
> any
> > further information from my end. Many thanks in advance.
> >
> >
> >
> > Thanks and Regards,Varun Gulati
>
>
>
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
[-- Attachment #1.2: Type: text/html, Size: 8187 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: audit-tools and SUDO
From: Steve Grubb @ 2016-05-10 13:25 UTC (permalink / raw)
To: linux-audit, burn
In-Reply-To: <1462884741.3439.16.camel@swtf.swtf.dyndns.org>
On Tuesday, May 10, 2016 10:52:21 PM Burn Alting wrote:
> On Tue, 2016-05-10 at 12:31 +0000, Warron S French wrote:
> > Good morning everyone,
> >
> >
> >
> > I am working on an environment where I have managed to get centralized
> > audit logging to work – roughly 95% properly on six (6) CentOS-6.7
> > workstations and a single (1) CentOS-6.7 server.
> >
> >
> >
> > I have two problems though; and they seem somewhat minor:
> >
> >
> >
> > 1. The audit events being captured don’t seem to be tied to any
> > given node (so that I can perform ausearch --node hostName, or
> > aureport), that’s the first issue.
>
> What have you set the configuration parameter 'name_format'
> in /etc/audit/auditd.conf to?
>
> One assumes you may want to set
> name_format = fqd
> or
> name_format = hostname
>
> After the change on each host, don't forget to reload the configuration
> with either a sighup on the auditd process or just restart the service.
This would set it for the local logs. And you would need to do this on the
server that is aggregating the logs. (I think I forgot to mention that last
week.) But for the workstations, you have to set name_format in audispd.conf.
> > 2. The second issue is that I need to configure sudo to enable my
> > Special Security Team with the ability to perform their duties using
> > the aureport and the ausearch commands, but I get an error that
> > appears to be based on permissions.
>
> I recommend you show the command and resultant error in situations like
> this. That way we can provide a more informed response.
One approach some people take is to use the log_group setting in auditd.conf.
If there is a group that the security people belong to that others don't, then
using that group name for log_group this is the easiest way and exactly why
this option exists.
-Steve
> > I am hoping that you guys can steer me in the correct direction; and I
> > can update my documentation to be even a little more thorough.
> >
> > Scenario2, might be more of a membership issue now that I think about
> > it; so please disregard as I think this is some weird 389-ds issue.
> >
> > I am hoping though that someone can suggest a reason why, when I look
> > directly at the content of the /var/log/audit/audit.log I am not see
> > any references to node=hostname1, hostname2 .. hostnameN? Maybe I did
> > misconfigure something, but I followed my own instructions to the “T”
> > and they didn’t produce this issue.
> >
> >
> >
> >
> >
> >
> >
> > Thank you in advance for your precious time sincerely,
> >
> >
> >
> > Warron French, MBA, SCSA
> >
> >
> > --
> > 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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ 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