* Re: krb5 issues
From: Ken Bass @ 2016-05-26 15:16 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <5744603D.9020504@kenbass.com>
On 05/24/2016 10:07 AM, Ken Bass wrote:
>
> On a related note, using krb5 causes a problem with selinux. Unless I
> disable it (or figure out a rule) auditd fails to start because it is
> denied permission to create /var/tmp/auditd_0 kerberos replay cache file.
> Is there a rule or procedure to properly fix that?
Is there somewhere to file a bug report for this at? Obviously the
selinux is not being setup for auditd to manage the /var/tmp/auditd_0
file when krb5 is enabled. Using Centos 7.2.
^ permalink raw reply
* Re: Better error message in auditd wanted
From: Steve Grubb @ 2016-05-26 14:54 UTC (permalink / raw)
To: linux-audit; +Cc: Christian Boltz
In-Reply-To: <9702820.CWonohP2Se@tux.boltz.de.vu>
Hello,
On Thursday, May 26, 2016 03:03:11 PM Christian Boltz wrote:
> I'd like to ask for a more useful error message in auditd ;-)
>
> If audit.log is world-readable (chmod 644 [1]), auditd refuses to start.
>
> The problem is that it gives a completely useless error message when
> doing that:
>
> # systemctl status auditd.service
> ● auditd.service - Security Auditing Service
> Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor
> preset: enabled) Active: failed (Result: exit-code) since Sa 2016-05-21
> 12:43:55 CEST; 4min 14s ago Process: 8656 ExecStartPost=/sbin/augenrules
> --load (code=exited, status=0/SUCCESS) Process: 8654 ExecStart=/sbin/auditd
> -n (code=exited, status=6)
> Main PID: 8654 (code=exited, status=6)
>
> Mai 21 12:43:55 tux systemd[1]: Starting Security Auditing Service...
> Mai 21 12:43:55 tux systemd[1]: auditd.service: Main process exited,
> code=exited, status=6/NOTCONFIGURED Mai 21 12:43:55 tux augenrules[8656]:
> /sbin/augenrules: No change
> Mai 21 12:43:55 tux augenrules[8656]: No rules
> Mai 21 12:43:55 tux systemd[1]: Failed to start Security Auditing Service.
> Mai 21 12:43:55 tux systemd[1]: auditd.service: Unit entered failed state.
> Mai 21 12:43:55 tux systemd[1]: auditd.service: Failed with result
> 'exit-code'.
>
>
> Exit status 6/NOTCONFIGURED is not really helpful and not even a
> correct) information :-(
>
> After searching around, reading the manpage etc. I tried to start auditd
> manually in debug mode:
>
>
> # auditd -f
> Config file /etc/audit/auditd.conf opened for parsing log_file_parser called
> with: /var/log/audit/audit.log /var/log/audit/audit.log permissions should
> be 0600 or 0640
> The audit daemon is exiting.
>
>
> Now _that_ is a useful message and clearly states what the problem is.
>
> Can you please change auditd so that it prints or logs this useful
> message independent of the given parameters?
This is the code you are talking about:
https://fedorahosted.org/audit/browser/trunk/src/auditd-config.c#L618
It is LOG_ERR, so it should be captured by syslog. Not sure what else can be
done.
-Steve
> In case it matters: I'm using openSUSE Tumbleweed with audit 2.5.
>
>
> Regards,
>
> Christian Boltz
>
> [1] I did that chmod to make testing of aa-logprof (part of the AppArmor
> userspace tools) easier.
>
> > I see no "do" in your script, so this will give you a "syntax error
> > near unexpected token `done'" after shutdown ;-))
>
> I've been hearing funny noises after shutdown, that must be it :-)
> [> Christian Boltz and Chris Maaskant in opensuse]
>
>
> --
> 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
* Better error message in auditd wanted
From: Christian Boltz @ 2016-05-26 13:03 UTC (permalink / raw)
To: linux-audit
Hello,
I'd like to ask for a more useful error message in auditd ;-)
If audit.log is world-readable (chmod 644 [1]), auditd refuses to start.
The problem is that it gives a completely useless error message when
doing that:
# systemctl status auditd.service
● auditd.service - Security Auditing Service
Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sa 2016-05-21 12:43:55 CEST; 4min 14s ago
Process: 8656 ExecStartPost=/sbin/augenrules --load (code=exited, status=0/SUCCESS)
Process: 8654 ExecStart=/sbin/auditd -n (code=exited, status=6)
Main PID: 8654 (code=exited, status=6)
Mai 21 12:43:55 tux systemd[1]: Starting Security Auditing Service...
Mai 21 12:43:55 tux systemd[1]: auditd.service: Main process exited, code=exited, status=6/NOTCONFIGURED
Mai 21 12:43:55 tux augenrules[8656]: /sbin/augenrules: No change
Mai 21 12:43:55 tux augenrules[8656]: No rules
Mai 21 12:43:55 tux systemd[1]: Failed to start Security Auditing Service.
Mai 21 12:43:55 tux systemd[1]: auditd.service: Unit entered failed state.
Mai 21 12:43:55 tux systemd[1]: auditd.service: Failed with result 'exit-code'.
Exit status 6/NOTCONFIGURED is not really helpful and not even a
correct) information :-(
After searching around, reading the manpage etc. I tried to start auditd
manually in debug mode:
# auditd -f
Config file /etc/audit/auditd.conf opened for parsing log_file_parser called with: /var/log/audit/audit.log
/var/log/audit/audit.log permissions should be 0600 or 0640
The audit daemon is exiting.
Now _that_ is a useful message and clearly states what the problem is.
Can you please change auditd so that it prints or logs this useful
message independent of the given parameters?
In case it matters: I'm using openSUSE Tumbleweed with audit 2.5.
Regards,
Christian Boltz
[1] I did that chmod to make testing of aa-logprof (part of the AppArmor
userspace tools) easier.
--
> I see no "do" in your script, so this will give you a "syntax error
> near unexpected token `done'" after shutdown ;-))
I've been hearing funny noises after shutdown, that must be it :-)
[> Christian Boltz and Chris Maaskant in opensuse]
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: krb5 issues
From: Ken Bass @ 2016-05-24 14:07 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <57432011.1060201@kenbass.com>
On 05/23/2016 11:21 AM, Ken Bass wrote:
> I enabled krb5 in my audisp-remote and audispd-remote reports "GSS-API
> error sending token length" and fails to log remotely.
>
> If I reboot the destination auditd server AFTER the clients are
> running it appears to work. But if I reboot any clients machine,
> logging from that rebooted machine fails.
> I created my service principals using freeipa - all systems are clean
> installs of Centos 7.2.
>
> For now, I disabled krb5, but that is not a good solution.
After disabling krb5 and rebooting the client servers several times I am
seeing similar problems. I am seeing a dozen or so log file entries of
Too many connections from 10.10.10.10:39107 - rejected
I only have 2 clients and all I am doing is rebooting them. I tried
increasing the tcp_listen_queue to 20 (from the default of 5) which made
no difference.
I seem to have traced it to needing to specify the tcp_client_ports to
60 rather than using whatever the default was. What would have been
blocking this? And why only when the clients are rebooted second does it
fail?
After changing this the Kerberos works, so I think the 'error sending
token length' is basically the same message but in a different code path
to indicate the connection is rejected / cannot write to the TCP socket.
Was the commented out ##tcp_client_ports parameter supposed to be
changed by the end user? Was the defaults supposed to work?
On a related note, using krb5 causes a problem with selinux. Unless I
disable it (or figure out a rule) auditd fails to start because it is
denied permission to create /var/tmp/auditd_0 kerberos replay cache file.
Is there a rule or procedure to properly fix that?
^ permalink raw reply
* krb5 issues
From: Ken Bass @ 2016-05-23 15:21 UTC (permalink / raw)
To: linux-audit
Hello,
I enabled krb5 in my audisp-remote and audispd-remote reports "GSS-API
error sending token length" and fails to log remotely.
If I reboot the destination auditd server AFTER the clients are running
it appears to work. But if I reboot any clients machine, logging from
that rebooted machine fails.
I created my service principals using freeipa - all systems are clean
installs of Centos 7.2.
For now, I disabled krb5, but that is not a good solution.
Thank you,
Ken
^ permalink raw reply
* Re: [PATCH] audit: fixup: log on errors from filter user rules
From: Paul Moore @ 2016-05-20 18:38 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit, linux-kernel, sgrubb, eparis
In-Reply-To: <52272665ce6c4b1dd18ca1b6a4fdafa8634c77e8.1463366687.git.rgb@redhat.com>
On Sunday, May 15, 2016 10:47:39 PM Richard Guy Briggs wrote:
> In commit 724e4fcc the intention was to pass any errors back from
> audit_filter_user_rules() to audit_filter_user(). Add that code.
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/auditfilter.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Looks good to me; queued up and should appear in audit#next after the merge
window closes.
> diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
> index b8ff9e1..96c9a1b 100644
> --- a/kernel/auditfilter.c
> +++ b/kernel/auditfilter.c
> @@ -1339,8 +1339,8 @@ static int audit_filter_user_rules(struct audit_krule
> *rule, int type, break;
> }
>
> - if (!result)
> - return 0;
> + if (result <= 0)
> + return result;
> }
> switch (rule->action) {
> case AUDIT_NEVER: *state = AUDIT_DISABLED; break;
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [PATCH] audit: add support for session ID user filter
From: Paul Moore @ 2016-05-20 18:25 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit, linux-kernel, sgrubb, eparis
In-Reply-To: <d897f32b82f3e589c85a3839caeb6f38b70a8eb6.1462934395.git.rgb@redhat.com>
On Tuesday, May 10, 2016 10:47:23 PM Richard Guy Briggs wrote:
> 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.
It seems like that would be a good idea, wouldn't it? Although instead of
SESSIONID_UNDEFINED I like SESSIONID_SET a bit more so it is consistent with
LOGINUID_SET.
> ---
>
> 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;
--
paul moore
security @ redhat
^ permalink raw reply
* RE: Audit reporting Invalid argument
From: Bhagwat, Shriniketan Manjunath @ 2016-05-19 3:37 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <1956741.kKb8qJBsiM@x2>
Thanks Steve and Richard for your response.
I will provide the fix soon.
Regards,
Ketan
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Monday, May 16, 2016 6:24 PM
To: Bhagwat, Shriniketan Manjunath <shriniketan.bhagwat@hpe.com>
Cc: linux-audit@redhat.com
Subject: Re: Audit reporting Invalid argument
On Saturday, May 14, 2016 09:40:05 AM Bhagwat, Shriniketan Manjunath wrote:
> > Not today. The check for uid 0 is a poor man's check for
> > CAP_AUDIT_CONTROL
>
> Are there any future plans to support enabling audit from non root
> user using CAP_AUDIT_CONTROL?
You are the only person who has asked for it. I suppose it can be done in a couple lines of code. But you still have the permissions of the directories that hold the rules to correct. Easy to fix, but I think you might be fighting the distribution's package manager which would set things back to root every update.
> Regarding suppression of events, I will do some testing and let you
> know later.
>
> Is there a way I can avoid default logging of the audit events to
> /var/log/audit/audit.log?
If you have an old copy old the audit system (2.5.1 or earlier) then use log_format = NOLOG. If you have a current copy, then use write_logs = no.
-Steve
> I do not want audit to log audit events to audit.log, however I will
> capture them using my plug-in. Is there a way I can accomplish this? I
> tried to commenting the log_file filed from auditd.conf, however the
> events are still written to audit.log. I think below code from
> auditd-config.c is causing audit to write to audit.log
>
> config->log_file = strdup("/var/log/audit/audit.log");
^ permalink raw reply
* Re: Monitoring "root-level" commands
From: Steve Grubb @ 2016-05-18 12:42 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <BY1PR09MB0887A43C1B312460B39B2F29C7490@BY1PR09MB0887.namprd09.prod.outlook.com>
On Wednesday, May 18, 2016 12:18:21 PM Warron S French wrote:
> My Special Security Team, not being UNIX/Linux savvy asked me if I could put
> into place audit rules that monitor "Root-Level" commands.
>
> I don't know of any specific identifier for such a term, and the closest
> thing I could come up with was monitoring those files that fall under
> /usr/sbin/ and /sbin/; does anyone else have any thoughts about how to
> approach this task?
Typically this is handled by monitoring what root runs. One huge difference
between windows and linux is that running one command may spawn 20 or 30
scripts and helpers. So, its easier to use the keystroke logging to what the
root user is doing.
To enable this, you would add:
session required pam_tty_audit.so disable=* enable=root
to the pam stack for su if that's how admins get the shell. If sudo gives them
shell access, then you can add it there, too. Sudo normally logs the commands
and parameters that it runs. If you are given a shell, though, all it logs is
it started a shell.
-Steve
> I figured I would use a rule such as:
> -w /sbin/ -p rawx -k watch_root_commands (I used rawx, to
> account for replacement by a hacker)
^ permalink raw reply
* Monitoring "root-level" commands
From: Warron S French @ 2016-05-18 12:18 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 584 bytes --]
My Special Security Team, not being UNIX/Linux savvy asked me if I could put into place audit rules that monitor "Root-Level" commands.
I don't know of any specific identifier for such a term, and the closest thing I could come up with was monitoring those files that fall under /usr/sbin/ and /sbin/; does anyone else have any thoughts about how to approach this task?
I figured I would use a rule such as:
-w /sbin/ -p rawx -k watch_root_commands (I used rawx, to account for replacement by a hacker)
Thank you in advance,
Warron French, MBA, SCSA
[-- Attachment #1.2: Type: text/html, Size: 2906 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [GIT PULL] Audit patches for 4.7
From: Paul Moore @ 2016-05-17 22:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-audit, linux-kernel
Hi Linus,
Four small audit patches for 4.7; two are simple cleanups around the audit
thread management code, one adds a tty field to AUDIT_LOGIN events, and the
final patch makes tty_name() usable regardless of CONFIG_TTY. Nothing
controversial, and it all passes our regression test. Please pull for 4.7.
Thanks,
-Paul
---
The following changes since commit b562e44f507e863c6792946e4e1b1449fbbac85d:
Linux 4.5 (2016-03-13 21:28:54 -0700)
are available in the git repository at:
git://git.infradead.org/users/pcmoore/audit stable-4.7
for you to fetch changes up to 188e3c5cd2b672620291e64a21f1598fe91e40b6:
tty: provide tty_name() even without CONFIG_TTY (2016-04-27 17:12:58 -0400)
----------------------------------------------------------------
Arnd Bergmann (1):
tty: provide tty_name() even without CONFIG_TTY
Jiri Slaby (1):
audit: cleanup prune_tree_thread
Paul Moore (1):
audit: we don't need to __set_current_state(TASK_RUNNING)
Richard Guy Briggs (1):
audit: add tty field to LOGIN event
include/linux/audit.h | 24 ++++++++++++++++++++++++
include/linux/tty.h | 4 +++-
kernel/audit.c | 30 ++++++++++--------------------
kernel/audit_tree.c | 12 +++++-------
kernel/auditsc.c | 8 ++++++--
5 files changed, 48 insertions(+), 30 deletions(-)
--
paul moore
security @ redhat
^ permalink raw reply
* Re: auditd hangs
From: Richard Guy Briggs @ 2016-05-17 17:15 UTC (permalink / raw)
To: Andrey Kulikov; +Cc: linux-audit
In-Reply-To: <573ADB01.2020000@corp.mail.ru>
On 16/05/17, Andrey Kulikov wrote:
> Hi everyone,
>
> We have several thousands hosts running CentOS 7. Every day auditd
> stops writing audit.log on 2-3 of them (different hosts every day).
Without more information, I suspect it is this bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=1253123
Is there any complaint in the syslog about auditd disappearing?
> Here is strace output:
>
> # strace -p 17306
> Process 17306 attached
> epoll_wait(7, {}, 64, 59743) = 0
> epoll_wait(7, {}, 64, 59743) = 0
> epoll_wait(7, {}, 64, 59743) = 0
> epoll_wait(7, {}, 64, 59743) = 0
> epoll_wait(7, {}, 64, 59743) = 0
> epoll_wait(7, {}, 64, 59743) = 0
> epoll_wait(7, {}, 64, 59743) = 0
> epoll_wait(7, 7fb4c3302be0, 64, 59743) = -1 EINTR (Interrupted system call)
> --- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=2728, si_uid=0} ---
> write(8, "\1\0\0\0\0\0\0\0", 8) = 8
> rt_sigreturn() = -1 EINTR (Interrupted system call)
> epoll_wait(7, {{EPOLLIN, {u32=8, u64=4294967304}}}, 64, 59743) = 1
> read(8, "\1\0\0\0\0\0\0\0", 8) = 8
> sendto(3, "\20\0\0\0\362\3\5\0\4\0\0\0\0\0\0\0", 16, 0,
> {sa_family=AF_NETLINK,
> pid=0, groups=00000000}, 12) = 16
> poll([{fd=3, events=POLLIN}], 1, 500) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3,
> "$\0\0\0\2\0\0\0\4\0\0\0\232C\0\0\0\0\0\0\20\0\0\0\362\3\5\0\4\0\0\0"...,
> 8988, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000},
> [12]) = 36
> recvfrom(3,
> "$\0\0\0\2\0\0\0\4\0\0\0\232C\0\0\0\0\0\0\20\0\0\0\362\3\5\0\4\0\0\0"...,
> 8988, MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000},
> [12]) = 36
> epoll_wait(7, {{EPOLLIN, {u32=3, u64=4294967299}}}, 64, 59743) = 1
> recvfrom(3,
> "N\0\0\0\362\3\0\0\4\0\0\0\232C\0\0\363\3\0\0\217C\0\0unconfin"..., 8988,
> MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 80
> mmap(NULL, 8392704, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK,
> -1, 0) = 0x7fb4be5da000
> mprotect(0x7fb4be5da000, 4096, PROT_NONE) = 0
> clone(child_stack=0x7fb4bedd9eb0,
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
> parent_tidptr=0x7fb4bedda9d0, tls=0x7fb4bedda700,
> child_tidptr=0x7fb4bedda9d0)
> = 3014
> epoll_wait(7,
>
> ... and line "epoll_wait(7," repeated infinitely.
>
> auditd restart helps, but I thint this is a bug. What can be causes
> of the problem?
>
> Thanks for your help in advance!
>
> --
> Regards,
> Andrey Kulikov.
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
- 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
* auditd hangs
From: Andrey Kulikov @ 2016-05-17 8:49 UTC (permalink / raw)
To: linux-audit
Hi everyone,
We have several thousands hosts running CentOS 7. Every day auditd stops
writing audit.log on 2-3 of them (different hosts every day). Here is
strace output:
# strace -p 17306
Process 17306 attached
epoll_wait(7, {}, 64, 59743) = 0
epoll_wait(7, {}, 64, 59743) = 0
epoll_wait(7, {}, 64, 59743) = 0
epoll_wait(7, {}, 64, 59743) = 0
epoll_wait(7, {}, 64, 59743) = 0
epoll_wait(7, {}, 64, 59743) = 0
epoll_wait(7, {}, 64, 59743) = 0
epoll_wait(7, 7fb4c3302be0, 64, 59743) = -1 EINTR (Interrupted system call)
--- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=2728, si_uid=0} ---
write(8, "\1\0\0\0\0\0\0\0", 8) = 8
rt_sigreturn() = -1 EINTR (Interrupted system call)
epoll_wait(7, {{EPOLLIN, {u32=8, u64=4294967304}}}, 64, 59743) = 1
read(8, "\1\0\0\0\0\0\0\0", 8) = 8
sendto(3, "\20\0\0\0\362\3\5\0\4\0\0\0\0\0\0\0", 16, 0,
{sa_family=AF_NETLINK,
pid=0, groups=00000000}, 12) = 16
poll([{fd=3, events=POLLIN}], 1, 500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3,
"$\0\0\0\2\0\0\0\4\0\0\0\232C\0\0\0\0\0\0\20\0\0\0\362\3\5\0\4\0\0\0"...,
8988, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000},
[12]) = 36
recvfrom(3,
"$\0\0\0\2\0\0\0\4\0\0\0\232C\0\0\0\0\0\0\20\0\0\0\362\3\5\0\4\0\0\0"...,
8988, MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000},
[12]) = 36
epoll_wait(7, {{EPOLLIN, {u32=3, u64=4294967299}}}, 64, 59743) = 1
recvfrom(3,
"N\0\0\0\362\3\0\0\4\0\0\0\232C\0\0\363\3\0\0\217C\0\0unconfin"..., 8988,
MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 80
mmap(NULL, 8392704, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK,
-1, 0) = 0x7fb4be5da000
mprotect(0x7fb4be5da000, 4096, PROT_NONE) = 0
clone(child_stack=0x7fb4bedd9eb0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7fb4bedda9d0, tls=0x7fb4bedda700,
child_tidptr=0x7fb4bedda9d0)
= 3014
epoll_wait(7,
... and line "epoll_wait(7," repeated infinitely.
auditd restart helps, but I thint this is a bug. What can be causes of
the problem?
Thanks for your help in advance!
--
Regards,
Andrey Kulikov.
^ permalink raw reply
* Re: Audit reporting Invalid argument
From: Richard Guy Briggs @ 2016-05-16 17:21 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com, Bhagwat, Shriniketan Manjunath
In-Reply-To: <1956741.kKb8qJBsiM@x2>
On 16/05/16, Steve Grubb wrote:
> On Saturday, May 14, 2016 09:40:05 AM Bhagwat, Shriniketan Manjunath wrote:
> > > Not today. The check for uid 0 is a poor man's check for CAP_AUDIT_CONTROL
> >
> > Are there any future plans to support enabling audit from non root user
> > using CAP_AUDIT_CONTROL?
>
> You are the only person who has asked for it. I suppose it can be done in a
> couple lines of code. But you still have the permissions of the directories
> that hold the rules to correct. Easy to fix, but I think you might be fighting
> the distribution's package manager which would set things back to root every
> update.
There is no kernel obstacle that I can see now. It used to depend on
CAP_NET_ADMIN, I think, but that stuff has all been fixed. I can see
applications for it, possibly even in containers down the road...
> -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: exclude filter action ignored?
From: Steve Grubb @ 2016-05-16 16:01 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20160516154426.GD21780@madcap2.tricolour.ca>
On Monday, May 16, 2016 11:44:26 AM Richard Guy Briggs wrote:
> On 16/05/16, Steve Grubb wrote:
> > On Sunday, May 15, 2016 04:38:27 PM Richard Guy Briggs wrote:
> > > Hi Steve,
> > >
> > > Can you confirm that the exclude filter action parameter is ignored?
> >
> > The exclude filter was supposed to do only 1 thing, delete events. It was
> > needed to create a pure CAPP system back in the lspp days. There are
> > things
> > like selinux which sends events whether you wanted them or not. For a pure
> > CAPP system you just tell it the msgtype of selinux events and then they
> > are gone. People found other uses later like getting rid of cron job pam
> > messages. But its always been used to remove events rather than trigger
> > them.
>
> Fine. Can we put something in the manpage to clarify that
> "exclude,never" won't do what people might think, which might be to
> override some other rule on a different list?
Typically where we use never rules is in blocking events on a certain
directory or application. This would be the entry and user filters. AFAIK, no
one has reported a problem where exclude,never wasn't working. :-)
> Something like "The exclude list ignores the action, and is treated as
> "always", or block the never option entirely either in userspace or in the
> kernel. I realize this latter option could be contentious since some might
> interpret that as "breaking userspace".
No one could possibly be counting on that to work (because it doesn't work).
But we can adjust the man page.
-Steve
^ permalink raw reply
* Re: exclude filter action ignored?
From: Richard Guy Briggs @ 2016-05-16 15:44 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <11175563.uHevLF1eMJ@x2>
On 16/05/16, Steve Grubb wrote:
> On Sunday, May 15, 2016 04:38:27 PM Richard Guy Briggs wrote:
> > Hi Steve,
> >
> > Can you confirm that the exclude filter action parameter is ignored?
>
> The exclude filter was supposed to do only 1 thing, delete events. It was
> needed to create a pure CAPP system back in the lspp days. There are things
> like selinux which sends events whether you wanted them or not. For a pure
> CAPP system you just tell it the msgtype of selinux events and then they are
> gone. People found other uses later like getting rid of cron job pam messages.
> But its always been used to remove events rather than trigger them.
Fine. Can we put something in the manpage to clarify that
"exclude,never" won't do what people might think, which might be to
override some other rule on a different list? Something like "The
exclude list ignores the action, and is treated as "always", or block
the never option entirely either in userspace or in the kernel. I
realize this latter option could be contentious since some might
interpret that as "breaking userspace".
> > I can't find any evidence in the kernel or in userspace that the action
> > value is actually honoured. In fact, looking at the manpage for
> > auditctl(8), the wording of the action contradicts the intuitive meaning
> > of that filter name. And as a matter of fact, I find discussion of it
> > here:
> > https://www.redhat.com/archives/linux-audit/2005-October/msg00020.html
> >
> >
> > In auditctl, setopt() calls audit_rule_setup() which calls lookup_filter()
> > and lookup_action(), then calls audit_rule_fieldpair_data() none of which
> > check when parsing the AUDIT_MSGTYPE field.
> >
> > During rule addition, in kernel/auditfilter.c:audit_rule_change() and
> > callees AUDIT_FILTER_TYPE is never checked for either action but simply
> > copied.
> >
> > When called from audit_log_start() in
> > kernel/auditfilter.c:audit_filter_type(), the state is never checked, so
> > either AUDIT_NEVER or AUDIT_ALWAYS actions gives the same result which
> > is to ignore that message type.
>
> Which should delete the event from being emitted.
Yes, that is what I understand it does after reading the code carefully.
I'm saying that the rule statement syntax is non-intuitive.
> -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: exclude filter action ignored?
From: Steve Grubb @ 2016-05-16 13:19 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20160515203827.GB21780@madcap2.tricolour.ca>
On Sunday, May 15, 2016 04:38:27 PM Richard Guy Briggs wrote:
> Hi Steve,
>
> Can you confirm that the exclude filter action parameter is ignored?
The exclude filter was supposed to do only 1 thing, delete events. It was
needed to create a pure CAPP system back in the lspp days. There are things
like selinux which sends events whether you wanted them or not. For a pure
CAPP system you just tell it the msgtype of selinux events and then they are
gone. People found other uses later like getting rid of cron job pam messages.
But its always been used to remove events rather than trigger them.
> I can't find any evidence in the kernel or in userspace that the action
> value is actually honoured. In fact, looking at the manpage for
> auditctl(8), the wording of the action contradicts the intuitive meaning
> of that filter name. And as a matter of fact, I find discussion of it
> here:
> https://www.redhat.com/archives/linux-audit/2005-October/msg00020.html
>
>
> In auditctl, setopt() calls audit_rule_setup() which calls lookup_filter()
> and lookup_action(), then calls audit_rule_fieldpair_data() none of which
> check when parsing the AUDIT_MSGTYPE field.
>
> During rule addition, in kernel/auditfilter.c:audit_rule_change() and
> callees AUDIT_FILTER_TYPE is never checked for either action but simply
> copied.
>
> When called from audit_log_start() in
> kernel/auditfilter.c:audit_filter_type(), the state is never checked, so
> either AUDIT_NEVER or AUDIT_ALWAYS actions gives the same result which
> is to ignore that message type.
Which should delete the event from being emitted.
-Steve
^ permalink raw reply
* Re: Audit reporting Invalid argument
From: Steve Grubb @ 2016-05-16 12:53 UTC (permalink / raw)
To: Bhagwat, Shriniketan Manjunath; +Cc: linux-audit@redhat.com
In-Reply-To: <8FC6AD31395616439ECBCD98E071A87F4BF15630@G4W3202.americas.hpqcorp.net>
On Saturday, May 14, 2016 09:40:05 AM Bhagwat, Shriniketan Manjunath wrote:
> > Not today. The check for uid 0 is a poor man's check for CAP_AUDIT_CONTROL
>
> Are there any future plans to support enabling audit from non root user
> using CAP_AUDIT_CONTROL?
You are the only person who has asked for it. I suppose it can be done in a
couple lines of code. But you still have the permissions of the directories
that hold the rules to correct. Easy to fix, but I think you might be fighting
the distribution's package manager which would set things back to root every
update.
> Regarding suppression of events, I will do some testing and let you know
> later.
>
> Is there a way I can avoid default logging of the audit events to
> /var/log/audit/audit.log?
If you have an old copy old the audit system (2.5.1 or earlier) then use
log_format = NOLOG. If you have a current copy, then use write_logs = no.
-Steve
> I do not want audit to log audit events to
> audit.log, however I will capture them using my plug-in. Is there a way I
> can accomplish this? I tried to commenting the log_file filed from
> auditd.conf, however the events are still written to audit.log. I think
> below code from auditd-config.c is causing audit to write to audit.log
>
> config->log_file = strdup("/var/log/audit/audit.log");
^ permalink raw reply
* [PATCH] audit: fixup: log on errors from filter user rules
From: Richard Guy Briggs @ 2016-05-16 2:47 UTC (permalink / raw)
To: linux-audit, linux-kernel; +Cc: Richard Guy Briggs, sgrubb, pmoore, eparis
In commit 724e4fcc the intention was to pass any errors back from
audit_filter_user_rules() to audit_filter_user(). Add that code.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
kernel/auditfilter.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index b8ff9e1..96c9a1b 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -1339,8 +1339,8 @@ static int audit_filter_user_rules(struct audit_krule *rule, int type,
break;
}
- if (!result)
- return 0;
+ if (result <= 0)
+ return result;
}
switch (rule->action) {
case AUDIT_NEVER: *state = AUDIT_DISABLED; break;
--
1.7.1
^ permalink raw reply related
* exclude filter action ignored?
From: Richard Guy Briggs @ 2016-05-15 20:38 UTC (permalink / raw)
To: linux-audit
Hi Steve,
Can you confirm that the exclude filter action parameter is ignored? I
can't find any evidence in the kernel or in userspace that the action
value is actually honoured. In fact, looking at the manpage for
auditctl(8), the wording of the action contradicts the intuitive meaning
of that filter name. And as a matter of fact, I find discussion of it
here:
https://www.redhat.com/archives/linux-audit/2005-October/msg00020.html
In auditctl, setopt() calls audit_rule_setup() which calls lookup_filter() and
lookup_action(), then calls audit_rule_fieldpair_data() none of which
check when parsing the AUDIT_MSGTYPE field.
During rule addition, in kernel/auditfilter.c:audit_rule_change() and
callees AUDIT_FILTER_TYPE is never checked for either action but simply
copied.
When called from audit_log_start() in
kernel/auditfilter.c:audit_filter_type(), the state is never checked, so
either AUDIT_NEVER or AUDIT_ALWAYS actions gives the same result which
is to ignore that message type.
- 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: Audit reporting Invalid argument
From: Bhagwat, Shriniketan Manjunath @ 2016-05-14 9:40 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <1581661.ndI2rhVsuG@x2>
Hi Steve,
Thanks for your input.
> Not today. The check for uid 0 is a poor man's check for CAP_AUDIT_CONTROL
Are there any future plans to support enabling audit from non root user using CAP_AUDIT_CONTROL?
Regarding suppression of events, I will do some testing and let you know later.
Is there a way I can avoid default logging of the audit events to /var/log/audit/audit.log? I do not want audit to log audit events to audit.log, however I will capture them using my plug-in. Is there a way I can accomplish this? I tried to commenting the log_file filed from auditd.conf, however the events are still written to audit.log. I think below code from auditd-config.c is causing audit to write to audit.log
config->log_file = strdup("/var/log/audit/audit.log");
Regards,
Ketan
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Thursday, May 12, 2016 1:22 AM
To: Bhagwat, Shriniketan Manjunath <shriniketan.bhagwat@hpe.com>
Cc: linux-audit@redhat.com
Subject: Re: Audit reporting Invalid argument
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: ausearch produces a Warning
From: Warron S French @ 2016-05-13 11:51 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <20160512213235.48223c5d@ivy-bridge>
Thank you for the education and the guidance Steve.
It is greatly appreciated,
Warron French, MBA, SCSA
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Thursday, May 12, 2016 9:33 PM
To: Warron S French <warron.s.french@aero.org>
Cc: linux-audit@redhat.com
Subject: Re: ausearch produces a Warning
On Thu, 12 May 2016 19:14:35 +0000
Warron S French <warron.s.french@aero.org> wrote:
> Hello all,
> I have audit logging working exactly as I want it now
> (thanks to you all), but when running ausearch on various systems (not
> all, which tells me something isn't consistent) I get a warning:
>
> Warning - freq is non-zero and incremental flushing not selected.
<snip>
> The question I have is, even this says "Warning" does it mean there is
> something I really need to be intensely looking into to prevent issues
> to come?
ausearch/report/auditd all share the same config file parser code. This warning is actually not important for ausearch/report, but is meaningful for auditd. What this means is that you have incremental flushing halfway setup. Meaning that the value is non-zero as if you intended to flush periodically, but you don't actually have incremental selected as the flushing technique. The fix is to either select incremental as the flushing technique or set freq to 0 so that its consistent with the flush technique.
The reason that you would want to use incremental flushing is for performance. I'd recommend 100 or 200 for the freq setting on a busy or aggregating server. I'd recommend 50 for everyone else.
> I do not fully understand the impact of what the flush parameter. I
> am also trying to comply with a STIG as well; I think that's what has
> caused this message to be presented.
It means you may not be getting the logging performance that you intended.
-Steve
^ permalink raw reply
* Re: ausearch produces a Warning
From: Steve Grubb @ 2016-05-13 1:32 UTC (permalink / raw)
To: Warron S French; +Cc: linux-audit@redhat.com
In-Reply-To: <BY1PR09MB088719EEBCC0CEFBF973C136C7730@BY1PR09MB0887.namprd09.prod.outlook.com>
On Thu, 12 May 2016 19:14:35 +0000
Warron S French <warron.s.french@aero.org> wrote:
> Hello all,
> I have audit logging working exactly as I want it now
> (thanks to you all), but when running ausearch on various systems
> (not all, which tells me something isn't consistent) I get a warning:
>
> Warning - freq is non-zero and incremental flushing not selected.
<snip>
> The question I have is, even this says "Warning" does it mean there
> is something I really need to be intensely looking into to prevent
> issues to come?
ausearch/report/auditd all share the same config file parser code. This
warning is actually not important for ausearch/report, but is
meaningful for auditd. What this means is that you have incremental
flushing halfway setup. Meaning that the value is non-zero as if you
intended to flush periodically, but you don't actually have incremental
selected as the flushing technique. The fix is to either select
incremental as the flushing technique or set freq to 0 so that its
consistent with the flush technique.
The reason that you would want to use incremental flushing is for
performance. I'd recommend 100 or 200 for the freq setting on a busy or
aggregating server. I'd recommend 50 for everyone else.
> I do not fully understand the impact of what the flush parameter. I
> am also trying to comply with a STIG as well; I think that's what has
> caused this message to be presented.
It means you may not be getting the logging performance that you
intended.
-Steve
^ permalink raw reply
* ausearch produces a Warning
From: Warron S French @ 2016-05-12 19:14 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 1666 bytes --]
Hello all,
I have audit logging working exactly as I want it now (thanks to you all), but when running ausearch on various systems (not all, which tells me something isn't consistent) I get a warning:
Warning - freq is non-zero and incremental flushing not selected.
I saw on the internet a post that (involved you Steve Grubb) in reply to someone else from Date: Fri, 19 May 2006 15:01:37 -0400
Here is the part of the thread where you replied Steve:
* From: Steve Grubb <sgrubb redhat com>
* To: Linda Knippers <linda knippers hp com>
* Cc: linux-audit redhat com
* Subject: Re: Double addition of rule yields two log messages
* Date: Fri, 19 May 2006 15:01:37 -0400
________________________________
On Friday 19 May 2006 14:47, Linda Knippers wrote:
> But why does ausearch care?
Ausearch doesn't care about this particular setting. Its looking at the config
to find the log files. The parser is what cares and it is what emitted this
warning. As such, you can use ausearch to make sure your config is sane
before sending sighup to reconfigure the audit daemon.
> Seems like if anything cared it would be the auditd but I can't find an
> error or warning from it anywhere.
Should be in the syslog.
-Steve
The question I have is, even this says "Warning" does it mean there is something I really need to be intensely looking into to prevent issues to come?
I do not fully understand the impact of what the flush parameter. I am also trying to comply with a STIG as well; I think that's what has caused this message to be presented.
Thank you,
Warron French, MBA, SCSA
[-- Attachment #1.2: Type: text/html, Size: 12625 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* 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
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