* Re: [PATCH] selinux: print leading 0x on ioctlcmd audits
From: Paul Moore @ 2016-07-15 19:02 UTC (permalink / raw)
To: Steve Grubb, William Roberts
Cc: seandroid-list-+05T5uksL2qpZYMLLGbcSA,
selinux-+05T5uksL2qpZYMLLGbcSA,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <1613578.6STCXkp1CU@x2>
On Fri, Jul 15, 2016 at 2:54 PM, Steve Grubb <sgrubb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Thursday, July 14, 2016 6:17:32 PM EDT Paul Moore wrote:
>> Re: [PATCH] selinux: print leading 0x on ioctlcmd audits
>> From: Paul Moore <paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org>
>> To: william.c.roberts-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
>> CC: selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org, seandroid-list-+05T5uksL2qpZYMLLGbcSA@public.gmane.org, Stephen Smalley
>> <sds-+05T5uksL2qpZYMLLGbcSA@public.gmane.org>, Me, linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org Date: Yesterday 6:17 PM
>>
>> On Thu, Jul 14, 2016 at 3:29 PM, <william.c.roberts-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> > From: William Roberts <william.c.roberts-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> >
>> > ioctlcmd is currently printing hex numbers, but their is no leading
>> > 0x. Thus things like ioctlcmd=1234 are misleading, as the base is
>> > not evident.
>> >
>> > Correct this by adding 0x as a prefix, so ioctlcmd=1234 becomes
>> > ioctlcmd=0x1234.
>> >
>> > Signed-off-by: William Roberts <william.c.roberts-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> > ---
>> > security/lsm_audit.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> NOTE: adding Steve Grubb and the audit mailing list to the CC line
>>
>> Like it or not, I believe the general standard/convention when it
>> comes to things like this is to leave off the "0x" prefix; the idea
>> being that is saves precious space in the audit logs and the value is
>> only ever going to be in hex anyway.
>
> We normally like the 0x prefix on anything that is hex so that stroul can figure
> it out itself. And since AVC's should in theory be rare or occassional, log
> space is not a concern.
>
> That said, what is this ioctlcmd field name? Is this the ioctl number? As in
> syscall arg a1? If so, it should be hooked up to the interpretation for that.
>
> Also, we have a field dictionary with some basic info about each field used in
> audit events:
>
> http://people.redhat.com/sgrubb/audit/field-dictionary.txt
Correction, that file now lives at the link below, the file on Steve's
people page is deprecated.
https://github.com/linux-audit/audit-documentation/blob/master/specs/fields/field-dictionary.csv
> This is important so that people don't make up new ones that do the same
> thing. The ioctlcmd field name should be recorded. Are there more that need
> documenting?
Steve/William, one of you want to send a patch/PR for the field dictionary?
--
paul moore
security @ redhat
_______________________________________________
Selinux mailing list
Selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org
To unsubscribe, send email to Selinux-leave-+05T5uksL2pAGbPMOrvdOA@public.gmane.org
To get help, send an email containing "help" to Selinux-request-+05T5uksL2pAGbPMOrvdOA@public.gmane.org
^ permalink raw reply
* Re: [PATCH] selinux: print leading 0x on ioctlcmd audits
From: Steve Grubb @ 2016-07-15 18:54 UTC (permalink / raw)
To: Paul Moore; +Cc: seandroid-list, selinux, linux-audit
In-Reply-To: <CAHC9VhReO7tLcB=K6KbGpH_inzMCLVLHmYWibNFGVku27Y=kFw@mail.gmail.com>
On Thursday, July 14, 2016 6:17:32 PM EDT Paul Moore wrote:
> Re: [PATCH] selinux: print leading 0x on ioctlcmd audits
> From: Paul Moore <paul@paul-moore.com>
> To: william.c.roberts@intel.com
> CC: selinux@tycho.nsa.gov, seandroid-list@tycho.nsa.gov, Stephen Smalley
> <sds@tycho.nsa.gov>, Me, linux-audit@redhat.com Date: Yesterday 6:17 PM
>
> On Thu, Jul 14, 2016 at 3:29 PM, <william.c.roberts@intel.com> wrote:
> > From: William Roberts <william.c.roberts@intel.com>
> >
> > ioctlcmd is currently printing hex numbers, but their is no leading
> > 0x. Thus things like ioctlcmd=1234 are misleading, as the base is
> > not evident.
> >
> > Correct this by adding 0x as a prefix, so ioctlcmd=1234 becomes
> > ioctlcmd=0x1234.
> >
> > Signed-off-by: William Roberts <william.c.roberts@intel.com>
> > ---
> > security/lsm_audit.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> NOTE: adding Steve Grubb and the audit mailing list to the CC line
>
> Like it or not, I believe the general standard/convention when it
> comes to things like this is to leave off the "0x" prefix; the idea
> being that is saves precious space in the audit logs and the value is
> only ever going to be in hex anyway.
We normally like the 0x prefix on anything that is hex so that stroul can figure
it out itself. And since AVC's should in theory be rare or occassional, log
space is not a concern.
That said, what is this ioctlcmd field name? Is this the ioctl number? As in
syscall arg a1? If so, it should be hooked up to the interpretation for that.
Also, we have a field dictionary with some basic info about each field used in
audit events:
http://people.redhat.com/sgrubb/audit/field-dictionary.txt
This is important so that people don't make up new ones that do the same
thing. The ioctlcmd field name should be recorded. Are there more that need
documenting?
-Steve
^ permalink raw reply
* Re: [PATCH] selinux: print leading 0x on ioctlcmd audits
From: Paul Moore @ 2016-07-15 18:19 UTC (permalink / raw)
To: William Roberts
Cc: seandroid-list@tycho.nsa.gov, linux-audit@redhat.com,
selinux@tycho.nsa.gov
In-Reply-To: <CAFftDdoHASP4V0=q6mvOmFMtOBYhgw1S7Js=fMtYQPEFr9ryxw@mail.gmail.com>
On Thu, Jul 14, 2016 at 7:33 PM, William Roberts
<bill.c.roberts@gmail.com> wrote:
> On Thu, Jul 14, 2016 at 4:18 PM, William Roberts wrote:
>> On Thu, Jul 14, 2016 at 3:17 PM, Paul Moore <paul@paul-moore.com> wrote:
>>> On Thu, Jul 14, 2016 at 3:29 PM, <william.c.roberts@intel.com> wrote:
>>> > From: William Roberts <william.c.roberts@intel.com>
>>> >
>>> > ioctlcmd is currently printing hex numbers, but their is no leading
>>> > 0x. Thus things like ioctlcmd=1234 are misleading, as the base is
>>> > not evident.
>>> >
>>> > Correct this by adding 0x as a prefix, so ioctlcmd=1234 becomes
>>> > ioctlcmd=0x1234.
>>> >
>>> > Signed-off-by: William Roberts <william.c.roberts@intel.com>
>>> > ---
>>> > security/lsm_audit.c | 2 +-
>>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> NOTE: adding Steve Grubb and the audit mailing list to the CC line
>>>
>>> Like it or not, I believe the general standard/convention when it
>>> comes to things like this is to leave off the "0x" prefix; the idea
>>> being that is saves precious space in the audit logs and the value is
>>> only ever going to be in hex anyway.
>>
>> Is it always in hex, what about pid?
>
> Outside of escaped untrusted input ...
That's what I've been working on the past few days and it colored my
view of things. I tracked down Steve just now and it looks like the
preference *is* to have a "0x" prefix, my apologies for the confusion.
I'll add this to the SELinux next queue.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: How can I install the latest version of Linux Audit on CentOS 6.8?
From: Steve Grubb @ 2016-07-15 13:17 UTC (permalink / raw)
To: linux-audit; +Cc: Konrad Witaszczyk
In-Reply-To: <DA0F677D-1DB2-44D8-9E58-76DA8667EFFA@FreeBSD.org>
On Friday, July 15, 2016 2:52:02 PM EDT Mateusz Piotrowski wrote:
> I’m trying to update the 2013 version of auditd on a just installed CentOS
> 6.8-i386.
>
> So far I’ve downloaded audit-userspace from GitHub[1] and I’ve faced a
> couple of problems:
>
> 1. README says that I should consult the README-install file. I cannot see
> this file. Where is it? 2. I consulted the INSTALL.tmp and since I’ve not
> got any ./configure file inside my clone I deducted I’ve got to run
> ./autogen.sh. I was missing some dependencies so I ran `yum install
> autoconf automake libtool`.
>
> Then I ran `./configure --sbindir=/sbin --with-python=yes --with-libwrap
> --enable-gssapi-krb5=yes --with-libcap-ng=yes` but the command failed at
> this is a part of the log I got (the full log file is available here[2]):
>
> configure: WARNING: unrecognized options: --with-libcap-ng
> ...
> Checking for programs
> ...
> ./configure: line 13130: AX_PROG_CC_FOR_BUILD: command not found
> ...
> Checking for header files
> ...
> checking for python... /usr/bin/python
> checking for python version... 2.6
> checking for python platform... linux2
> checking for python script directory...
> ${prefix}/lib/python2.6/site-packages checking for python extension module
> directory... ${exec_prefix}/lib/python2.6/site-packages configure: error:
> Python explicitly requested and python headers were not found
>
> Have you got any idea what the problem is?
Probably missing dependencies that would have been detected by building from a
spec file.
> Is there an easier way to get the latest Linux Audit version on my system?
Why wouldn't you start with the distribution tar file?
http://people.redhat.com/sgrubb/audit/audit-2.6.5.tar.gz
If you are creating a distributable tar file for compilation, that would assume
that you already had all dependencies solved on your system. The distributable
tar file above was created on a system with all dependencies solved and the
latest auto tools so that platforms are correctly detected.
If you want it packaged, then start with the Centos 6.8 spec file and adjust
accordingly. The spec file shipped is aimed at future systems that are systemd
based. So, you'd want to start with a spec file that was intended for the OS
that you are using.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* How can I install the latest version of Linux Audit on CentOS 6.8?
From: Mateusz Piotrowski @ 2016-07-15 12:52 UTC (permalink / raw)
To: linux-audit; +Cc: Konrad Witaszczyk
[-- Attachment #1.1: Type: text/plain, Size: 1777 bytes --]
Hello,
I’m trying to update the 2013 version of auditd on a just installed CentOS 6.8-i386.
So far I’ve downloaded audit-userspace from GitHub[1] and I’ve faced a couple of problems:
1. README says that I should consult the README-install file. I cannot see this file. Where is it?
2. I consulted the INSTALL.tmp and since I’ve not got any ./configure file inside my clone I deducted I’ve got to run ./autogen.sh. I was missing some dependencies so I ran `yum install autoconf automake libtool`.
Then I ran `./configure --sbindir=/sbin --with-python=yes --with-libwrap --enable-gssapi-krb5=yes --with-libcap-ng=yes` but the command failed at this is a part of the log I got (the full log file is available here[2]):
configure: WARNING: unrecognized options: --with-libcap-ng
...
Checking for programs
...
./configure: line 13130: AX_PROG_CC_FOR_BUILD: command not found
...
Checking for header files
...
checking for python... /usr/bin/python
checking for python version... 2.6
checking for python platform... linux2
checking for python script directory... ${prefix}/lib/python2.6/site-packages
checking for python extension module directory... ${exec_prefix}/lib/python2.6/site-packages
configure: error: Python explicitly requested and python headers were not found
Have you got any idea what the problem is?
Is there an easier way to get the latest Linux Audit version on my system?
Cheers!
-m
[1]: https://github.com/linux-audit/audit-userspace <https://github.com/linux-audit/audit-userspace>
[2]: http://pastebin.com/jd7ZSmLV <http://pastebin.com/jd7ZSmLV>
[Logs in a raw txt format]: http://pastebin.com/raw/Jd7ZSmLV <http://pastebin.com/raw/Jd7ZSmLV>
[-- Attachment #1.2: Type: text/html, Size: 3046 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Weird issues in 2.6.5
From: Steve Grubb @ 2016-07-15 1:09 UTC (permalink / raw)
To: Chris Nandor; +Cc: linux-audit
In-Reply-To: <CAHcE2wrPftjsy2QMB4+qsa9o-S=xWqjiD+rtKX0wM24ksT0tkQ@mail.gmail.com>
On Wednesday, July 13, 2016 3:22:01 PM EDT Chris Nandor wrote:
> The buffering appears to be on the client side, because if I restart the
> server's auditd, those lines are not lost: they still appear in the remote
> log ... but not until the next time I run `sudo ls` on the client side.
>
> This is on 1.7.x. This does not happen on 2.4.x or 2.6.x.
Bugs were fixed. 1.7.x is very old.
-Steve
^ permalink raw reply
* Re: [PATCH] selinux: print leading 0x on ioctlcmd audits
From: William Roberts @ 2016-07-14 23:33 UTC (permalink / raw)
To: Paul Moore
Cc: seandroid-list@tycho.nsa.gov, linux-audit@redhat.com,
selinux@tycho.nsa.gov
In-Reply-To: <CAFftDdoHOeGdwfK79aviHmFr4JxE1rX0z0vcfZZtbtvv2TL9ew@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2654 bytes --]
On Thu, Jul 14, 2016 at 4:18 PM, William Roberts <bill.c.roberts@gmail.com>
wrote:
>
>
> On Thu, Jul 14, 2016 at 3:17 PM, Paul Moore <paul@paul-moore.com> wrote:
>
>> On Thu, Jul 14, 2016 at 3:29 PM, <william.c.roberts@intel.com> wrote:
>> > From: William Roberts <william.c.roberts@intel.com>
>> >
>> > ioctlcmd is currently printing hex numbers, but their is no leading
>> > 0x. Thus things like ioctlcmd=1234 are misleading, as the base is
>> > not evident.
>> >
>> > Correct this by adding 0x as a prefix, so ioctlcmd=1234 becomes
>> ioctlcmd=0x1234.
>> >
>> > Signed-off-by: William Roberts <william.c.roberts@intel.com>
>> > ---
>> > security/lsm_audit.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> NOTE: adding Steve Grubb and the audit mailing list to the CC line
>>
>> Like it or not, I believe the general standard/convention when it
>> comes to things like this is to leave off the "0x" prefix; the idea
>> being that is saves precious space in the audit logs and the value is
>> only ever going to be in hex anyway.
>>
>
> Is it always in hex, what about pid?
>
Outside of escaped untrusted input, everything I see is printed in base10.
But if its convention that "you should just know", I am fine
with that too, its just that it wasn't self evident in the logs, and the
first time I encountered it their was no documentation or tooling
supporting it.
>
>>
>> > diff --git a/security/lsm_audit.c b/security/lsm_audit.c
>> > index cccbf30..82e4dbb 100644
>> > --- a/security/lsm_audit.c
>> > +++ b/security/lsm_audit.c
>> > @@ -257,7 +257,7 @@ static void dump_common_audit_data(struct
>> audit_buffer *ab,
>> > audit_log_format(ab, " ino=%lu", inode->i_ino);
>> > }
>> >
>> > - audit_log_format(ab, " ioctlcmd=%hx", a->u.op->cmd);
>> > + audit_log_format(ab, " ioctlcmd=0x%hx", a->u.op->cmd);
>> > break;
>> > }
>> > case LSM_AUDIT_DATA_DENTRY: {
>> > --
>> > 1.9.1
>> >
>> > _______________________________________________
>> > Selinux mailing list
>> > Selinux@tycho.nsa.gov
>> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> > To get help, send an email containing "help" to
>> Selinux-request@tycho.nsa.gov.
>>
>> --
>> paul moore
>> www.paul-moore.com
>> _______________________________________________
>> Selinux mailing list
>> Selinux@tycho.nsa.gov
>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to
>> Selinux-request@tycho.nsa.gov.
>>
>
>
>
> --
> Respectfully,
>
> William C Roberts
>
>
--
Respectfully,
William C Roberts
[-- Attachment #1.2: Type: text/html, Size: 4995 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] selinux: print leading 0x on ioctlcmd audits
From: William Roberts @ 2016-07-14 23:18 UTC (permalink / raw)
To: Paul Moore
Cc: seandroid-list@tycho.nsa.gov, linux-audit@redhat.com,
selinux@tycho.nsa.gov
In-Reply-To: <CAHC9VhReO7tLcB=K6KbGpH_inzMCLVLHmYWibNFGVku27Y=kFw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2156 bytes --]
On Thu, Jul 14, 2016 at 3:17 PM, Paul Moore <paul@paul-moore.com> wrote:
> On Thu, Jul 14, 2016 at 3:29 PM, <william.c.roberts@intel.com> wrote:
> > From: William Roberts <william.c.roberts@intel.com>
> >
> > ioctlcmd is currently printing hex numbers, but their is no leading
> > 0x. Thus things like ioctlcmd=1234 are misleading, as the base is
> > not evident.
> >
> > Correct this by adding 0x as a prefix, so ioctlcmd=1234 becomes
> ioctlcmd=0x1234.
> >
> > Signed-off-by: William Roberts <william.c.roberts@intel.com>
> > ---
> > security/lsm_audit.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> NOTE: adding Steve Grubb and the audit mailing list to the CC line
>
> Like it or not, I believe the general standard/convention when it
> comes to things like this is to leave off the "0x" prefix; the idea
> being that is saves precious space in the audit logs and the value is
> only ever going to be in hex anyway.
>
Is it always in hex, what about pid?
>
> > diff --git a/security/lsm_audit.c b/security/lsm_audit.c
> > index cccbf30..82e4dbb 100644
> > --- a/security/lsm_audit.c
> > +++ b/security/lsm_audit.c
> > @@ -257,7 +257,7 @@ static void dump_common_audit_data(struct
> audit_buffer *ab,
> > audit_log_format(ab, " ino=%lu", inode->i_ino);
> > }
> >
> > - audit_log_format(ab, " ioctlcmd=%hx", a->u.op->cmd);
> > + audit_log_format(ab, " ioctlcmd=0x%hx", a->u.op->cmd);
> > break;
> > }
> > case LSM_AUDIT_DATA_DENTRY: {
> > --
> > 1.9.1
> >
> > _______________________________________________
> > Selinux mailing list
> > Selinux@tycho.nsa.gov
> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> > To get help, send an email containing "help" to
> Selinux-request@tycho.nsa.gov.
>
> --
> paul moore
> www.paul-moore.com
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to
> Selinux-request@tycho.nsa.gov.
>
--
Respectfully,
William C Roberts
[-- Attachment #1.2: Type: text/html, Size: 3680 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] selinux: print leading 0x on ioctlcmd audits
From: Paul Moore @ 2016-07-14 22:17 UTC (permalink / raw)
To: william.c.roberts; +Cc: seandroid-list, selinux, linux-audit
In-Reply-To: <1468524562-30981-1-git-send-email-william.c.roberts@intel.com>
On Thu, Jul 14, 2016 at 3:29 PM, <william.c.roberts@intel.com> wrote:
> From: William Roberts <william.c.roberts@intel.com>
>
> ioctlcmd is currently printing hex numbers, but their is no leading
> 0x. Thus things like ioctlcmd=1234 are misleading, as the base is
> not evident.
>
> Correct this by adding 0x as a prefix, so ioctlcmd=1234 becomes ioctlcmd=0x1234.
>
> Signed-off-by: William Roberts <william.c.roberts@intel.com>
> ---
> security/lsm_audit.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
NOTE: adding Steve Grubb and the audit mailing list to the CC line
Like it or not, I believe the general standard/convention when it
comes to things like this is to leave off the "0x" prefix; the idea
being that is saves precious space in the audit logs and the value is
only ever going to be in hex anyway.
> diff --git a/security/lsm_audit.c b/security/lsm_audit.c
> index cccbf30..82e4dbb 100644
> --- a/security/lsm_audit.c
> +++ b/security/lsm_audit.c
> @@ -257,7 +257,7 @@ static void dump_common_audit_data(struct audit_buffer *ab,
> audit_log_format(ab, " ino=%lu", inode->i_ino);
> }
>
> - audit_log_format(ab, " ioctlcmd=%hx", a->u.op->cmd);
> + audit_log_format(ab, " ioctlcmd=0x%hx", a->u.op->cmd);
> break;
> }
> case LSM_AUDIT_DATA_DENTRY: {
> --
> 1.9.1
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] Fix whitespace in CWD record
From: Paul Moore @ 2016-07-14 21:51 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <1772571.A9vuBSQyZx@x2>
On Thu, Jul 14, 2016 at 10:59 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> Fix the whitespace in the CWD record
>
> Signed-off-by: Steve Grubb <sgrubb@redhat.com>
> ---
> kernel/auditsc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Generally I don't like merging patches this late, but this patch is so
trivial I'll make an exception. Also, I fixed it this time, but in
the future please prefix your patch subject lines with the subsystem
name, e.g. "audit: fix whitespace in CWD record".
> diff -urp linux-4.7.0-0.rc4.git1.1.fc23.x86_64.orig/kernel/auditsc.c linux-4.7.0-0.rc4.git1.1.fc23.x86_64/kernel/auditsc.c
> --- linux-4.7.0-0.rc4.git1.1.fc23.x86_64.orig/kernel/auditsc.c 2016-06-25 12:44:41.756440052 -0400
> +++ linux-4.7.0-0.rc4.git1.1.fc23.x86_64/kernel/auditsc.c 2016-07-14 09:56:50.222227280 -0400
> @@ -1426,7 +1426,7 @@ static void audit_log_exit(struct audit_
> if (context->pwd.dentry && context->pwd.mnt) {
> ab = audit_log_start(context, GFP_KERNEL, AUDIT_CWD);
> if (ab) {
> - audit_log_d_path(ab, " cwd=", &context->pwd);
> + audit_log_d_path(ab, "cwd=", &context->pwd);
> audit_log_end(ab);
> }
> }
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: USER_CMD
From: Chris Nandor @ 2016-07-14 21:28 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <3356082.2SN9eLZslF@x2>
[-- Attachment #1.1: Type: text/plain, Size: 1941 bytes --]
Ah, I see. I didn't get that it was sudo itself doing it (assuming it was
linked to libaudit). Yes, in 12.04, libaudit is not part of the base
system. I've tried it in a vagrant box under 16.04, ldd reports libaudit
is linked, and it works fine there.
I think we'll just skip pam_tty_audit (since it records passwords on
12.04's kernel) and USER_CMD on our 12.04 boxes.
Thanks!
On Thu, Jul 14, 2016 at 12:50 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Thursday, July 14, 2016 12:44:02 PM EDT Chris Nandor wrote:
> > So how do I get it then?
>
> You just run a command under sudo and it does it. There is a chance that
> your
> copy of sudo does not have auditing enabled. You can try using ldd to see
> if
> its linked to the audit libraries. If not, then its not supported.
>
> -Steve
>
> > I found a 9-year old mail from you about bash
> > --audit and aubash but that isn't working for me.
> > > On Jul 14, 2016, at 12:06, Steve Grubb <sgrubb@redhat.com> wrote:
> > >> On Thursday, July 14, 2016 10:44:46 AM EDT Chris Nandor wrote:
> > >> Sorry, I guess I should have been more clear ... what sort of rule
> would
> > >> make it show up? I'm not seeing it.
> > >
> > > Its hardwired. You don't need to add a rule. The rules that you add
> always
> > > result in SYSCALL events. You should also add a key to every rule as a
> > > reminder of what it means. So, any SYSCALL event that does not have a
> key
> > > is trigger by something else like a SELinux AVC.
> > >
> > > -Steve
> > >
> > >>> On Thu, Jul 14, 2016 at 10:37 AM, Steve Grubb <sgrubb@redhat.com>
> wrote:
> > >>>> On Thursday, July 14, 2016 10:22:30 AM EDT Chris Nandor wrote:
> > >>>> How does one get USER_CMD records into the audit.log?
> > >>>
> > >>> The sudo command is the usual way.
> > >>>
> > >>> -Steve
> > >>>
> > >>> --
> > >>> Linux-audit mailing list
> > >>> Linux-audit@redhat.com
> > >>> https://www.redhat.com/mailman/listinfo/linux-audit
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 3029 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: USER_CMD
From: Steve Grubb @ 2016-07-14 19:50 UTC (permalink / raw)
To: Chris Nandor; +Cc: linux-audit
In-Reply-To: <002D079F-50B0-4CE9-A54B-E7E1DD9861CF@pobox.com>
On Thursday, July 14, 2016 12:44:02 PM EDT Chris Nandor wrote:
> So how do I get it then?
You just run a command under sudo and it does it. There is a chance that your
copy of sudo does not have auditing enabled. You can try using ldd to see if
its linked to the audit libraries. If not, then its not supported.
-Steve
> I found a 9-year old mail from you about bash
> --audit and aubash but that isn't working for me.
> > On Jul 14, 2016, at 12:06, Steve Grubb <sgrubb@redhat.com> wrote:
> >> On Thursday, July 14, 2016 10:44:46 AM EDT Chris Nandor wrote:
> >> Sorry, I guess I should have been more clear ... what sort of rule would
> >> make it show up? I'm not seeing it.
> >
> > Its hardwired. You don't need to add a rule. The rules that you add always
> > result in SYSCALL events. You should also add a key to every rule as a
> > reminder of what it means. So, any SYSCALL event that does not have a key
> > is trigger by something else like a SELinux AVC.
> >
> > -Steve
> >
> >>> On Thu, Jul 14, 2016 at 10:37 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> >>>> On Thursday, July 14, 2016 10:22:30 AM EDT Chris Nandor wrote:
> >>>> How does one get USER_CMD records into the audit.log?
> >>>
> >>> The sudo command is the usual way.
> >>>
> >>> -Steve
> >>>
> >>> --
> >>> Linux-audit mailing list
> >>> Linux-audit@redhat.com
> >>> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: USER_CMD
From: Chris Nandor @ 2016-07-14 19:44 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <2500772.GKlpCM7XVk@x2>
So how do I get it then? I found a 9-year old mail from you about bash --audit and aubash but that isn't working for me.
> On Jul 14, 2016, at 12:06, Steve Grubb <sgrubb@redhat.com> wrote:
>
>> On Thursday, July 14, 2016 10:44:46 AM EDT Chris Nandor wrote:
>> Sorry, I guess I should have been more clear ... what sort of rule would
>> make it show up? I'm not seeing it.
>
> Its hardwired. You don't need to add a rule. The rules that you add always
> result in SYSCALL events. You should also add a key to every rule as a
> reminder of what it means. So, any SYSCALL event that does not have a key is
> trigger by something else like a SELinux AVC.
>
> -Steve
>
>>> On Thu, Jul 14, 2016 at 10:37 AM, Steve Grubb <sgrubb@redhat.com> wrote:
>>>> On Thursday, July 14, 2016 10:22:30 AM EDT Chris Nandor wrote:
>>>> How does one get USER_CMD records into the audit.log?
>>>
>>> The sudo command is the usual way.
>>>
>>> -Steve
>>>
>>> --
>>> Linux-audit mailing list
>>> Linux-audit@redhat.com
>>> https://www.redhat.com/mailman/listinfo/linux-audit
>
>
^ permalink raw reply
* Re: USER_CMD
From: Steve Grubb @ 2016-07-14 19:06 UTC (permalink / raw)
To: Chris Nandor; +Cc: linux-audit
In-Reply-To: <CAHcE2wrcXyskQOoKnt=bnhjjXn5NVCPRMB3w+icAugXBRknzEA@mail.gmail.com>
On Thursday, July 14, 2016 10:44:46 AM EDT Chris Nandor wrote:
> Sorry, I guess I should have been more clear ... what sort of rule would
> make it show up? I'm not seeing it.
Its hardwired. You don't need to add a rule. The rules that you add always
result in SYSCALL events. You should also add a key to every rule as a
reminder of what it means. So, any SYSCALL event that does not have a key is
trigger by something else like a SELinux AVC.
-Steve
> On Thu, Jul 14, 2016 at 10:37 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Thursday, July 14, 2016 10:22:30 AM EDT Chris Nandor wrote:
> > > How does one get USER_CMD records into the audit.log?
> >
> > The sudo command is the usual way.
> >
> > -Steve
> >
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Linux-audit Digest, Vol 142, Issue 18
From: aung @ 2016-07-14 18:51 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <mailman.73.1468512020.20620.linux-audit@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 6346 bytes --]
Hi All,
Please ask me one question regarding about of RHEL security. To hack RHEL
root privilege is possible or not ? Even this system didn't try to patch
update CVE,RHSA and so on.
Thanks in advance for your feedback.
All the best,
-Aung
On Thu, Jul 14, 2016 at 10:30 PM, <linux-audit-request@redhat.com> wrote:
> Send Linux-audit mailing list submissions to
> linux-audit@redhat.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.redhat.com/mailman/listinfo/linux-audit
> or, via email, send a message with subject or body 'help' to
> linux-audit-request@redhat.com
>
> You can reach the person managing the list at
> linux-audit-owner@redhat.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linux-audit digest..."
>
>
> Today's Topics:
>
> 1. Re: Weird issues in 2.6.5 (Chris Nandor)
> 2. [PATCH] Fix whitespace in CWD record (Steve Grubb)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 13 Jul 2016 15:22:01 -0700
> From: Chris Nandor <pudge@pobox.com>
> To: Steve Grubb <sgrubb@redhat.com>
> Cc: linux-audit@redhat.com
> Subject: Re: Weird issues in 2.6.5
> Message-ID:
> <CAHcE2wrPftjsy2QMB4+qsa9o-S=
> xWqjiD+rtKX0wM24ksT0tkQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I set heartbeat to 60 on the client and idle to 120 on the server.
> Reconnects seem fine now, although I never did nail down the exact
> conditions under which reconnects failed.
>
> But I still have the problem of weird buffering on the client side. If I
> run `sudo ls` on the client side, locally I get something like:
>
> node=grax.sea.marchex.com type=SYSCALL
> msg=audit(1468448156.161:3288765): arch=c000003e syscall=59 success=yes
> exit=0 a0=8f81e8 a1=8f7578 a2=8febf0 a3=7ffd3d956370 items=2 ppid=19387
> pid=19388 auid=2288 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=pts4 ses=399 comm="ls" exe="/bin/ls" key="rootcmd"
> node=grax.sea.marchex.com type=EXECVE
> msg=audit(1468448156.161:3288765): argc=1 a0="ls"
> node=grax.sea.marchex.com type=CWD msg=audit(1468448156.161:3288765):
> cwd="/tmp"
> node=grax.sea.marchex.com type=PATH msg=audit(1468448156.161:3288765):
> item=0 name="/bin/ls" inode=132438 dev=09:01 mode=0100755 ouid=0 ogid=0
> rdev=00:00
> node=grax.sea.marchex.com type=PATH msg=audit(1468448156.161:3288765):
> item=1 name=(null) inode=71179 dev=09:01 mode=0100755 ouid=0 ogid=0
> rdev=00:00
>
> But remotely, I just get:
>
> node=grax.sea.marchex.com type=SYSCALL
> msg=audit(1468448156.161:3288765): arch=c000003e syscall=59 success=yes
> exit=0 a0=8f81e8 a1=8f7578 a2=8febf0 a3=7ffd3d956370 items=2 ppid=19387
> pid=19388 auid=2288 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=pts4 ses=399 comm="ls" exe="/bin/ls" key="rootcmd"
>
> Just the first line of the audit record. No matter how long I wait. If I
> then run `sudo ls` again, *then* the rest of the lines show up in the
> server's log.
>
> The buffering appears to be on the client side, because if I restart the
> server's auditd, those lines are not lost: they still appear in the remote
> log ... but not until the next time I run `sudo ls` on the client side.
>
> This is on 1.7.x. This does not happen on 2.4.x or 2.6.x.
>
>
>
>
>
>
>
> On Wed, Jul 13, 2016 at 11:38 AM, Steve Grubb <sgrubb@redhat.com> wrote:
>
> > On Wednesday, July 13, 2016 10:51:07 AM EDT Chris Nandor wrote:
> > > The only reason I am even upgrading is because of the issues with
> > > audisp-remote, the not-reconnecting, and the apparent client-side
> > > buffering, that went away with 2.4.x and 2.6.x. So if we decide to
> ship
> > > logs a different way than with audisp-remote, then it might be best to
> > > stick with 1.7.x.
> >
> > This sounds a lot like the idle detection is not set right. In audisp-
> > remote.conf there is a setting heartbeat_timeout. This should be set to
> > something like 60 or 120. Then on the server in auditd.conf there is a
> > setting
> > tcp_client_max_idle which should be over twice as high as
> > heartbeat_timeout.
> > So, you'd set it to 180 or 300.
> >
> > > That said, so far I see no issues, so we're going to forge ahead and
> see
> > > what happens. I just need to keep in mind what our mitigation plan
> would
> > > be if we do run into issues.
> >
> > Old utilities won't know what to do with enriched events. AFAICS, that
> > would
> > be the long term issue. You'll need to do aperl, awk, or cut command to
> > trim
> > off the unknown part of the event in your logs.
> >
> > -Steve
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://www.redhat.com/archives/linux-audit/attachments/20160713/023e5d70/attachment.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Thu, 14 Jul 2016 10:59:19 -0400
> From: Steve Grubb <sgrubb@redhat.com>
> To: linux-audit@redhat.com
> Subject: [PATCH] Fix whitespace in CWD record
> Message-ID: <1772571.A9vuBSQyZx@x2>
> Content-Type: text/plain; charset="us-ascii"
>
> Fix the whitespace in the CWD record
>
> Signed-off-by: Steve Grubb <sgrubb@redhat.com>
> ---
> kernel/auditsc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -urp linux-4.7.0-0.rc4.git1.1.fc23.x86_64.orig/kernel/auditsc.c
> linux-4.7.0-0.rc4.git1.1.fc23.x86_64/kernel/auditsc.c
> --- linux-4.7.0-0.rc4.git1.1.fc23.x86_64.orig/kernel/auditsc.c 2016-06-25
> 12:44:41.756440052 -0400
> +++ linux-4.7.0-0.rc4.git1.1.fc23.x86_64/kernel/auditsc.c 2016-07-14
> 09:56:50.222227280 -0400
> @@ -1426,7 +1426,7 @@ static void audit_log_exit(struct audit_
> if (context->pwd.dentry && context->pwd.mnt) {
> ab = audit_log_start(context, GFP_KERNEL, AUDIT_CWD);
> if (ab) {
> - audit_log_d_path(ab, " cwd=", &context->pwd);
> + audit_log_d_path(ab, "cwd=", &context->pwd);
> audit_log_end(ab);
> }
> }
>
>
>
> ------------------------------
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
> End of Linux-audit Digest, Vol 142, Issue 18
> ********************************************
>
[-- Attachment #1.2: Type: text/html, Size: 9024 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: USER_CMD
From: Chris Nandor @ 2016-07-14 17:44 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <1545844.sIvAAjI6WL@x2>
[-- Attachment #1.1: Type: text/plain, Size: 473 bytes --]
Sorry, I guess I should have been more clear ... what sort of rule would
make it show up? I'm not seeing it.
On Thu, Jul 14, 2016 at 10:37 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Thursday, July 14, 2016 10:22:30 AM EDT Chris Nandor wrote:
> > How does one get USER_CMD records into the audit.log?
>
> The sudo command is the usual way.
>
> -Steve
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
[-- Attachment #1.2: Type: text/html, Size: 972 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: USER_CMD
From: Steve Grubb @ 2016-07-14 17:37 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <CAHcE2wqRTuQcAmdTrHdmZ2V0dwKsHS2C5qA=_MwG7Wa6TmiXKw@mail.gmail.com>
On Thursday, July 14, 2016 10:22:30 AM EDT Chris Nandor wrote:
> How does one get USER_CMD records into the audit.log?
The sudo command is the usual way.
-Steve
^ permalink raw reply
* USER_CMD
From: Chris Nandor @ 2016-07-14 17:22 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 63 bytes --]
How does one get USER_CMD records into the audit.log?
--Chris
[-- Attachment #1.2: Type: text/html, Size: 123 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Questions about the standard (Google Summer of Code Project)
From: Steve Grubb @ 2016-07-14 16:38 UTC (permalink / raw)
To: Mateusz Piotrowski; +Cc: linux-audit, Konrad Witaszczyk
In-Reply-To: <B63FF289-BB62-4A41-90E6-7297851B7370@FreeBSD.org>
On Thursday, July 14, 2016 6:10:00 PM EDT Mateusz Piotrowski wrote:
> Hello,
>
> Thank you for your reply! It is absolutely amazing. It clarified a lot.
>
> >> b) Why do some records are separated by a comma and a
> >>
> >> whitespace? Example:
> >> type=DAEMON_START msg=audit(1363713609.192:5426): auditd
> >> start, ver=2.2 format=raw kernel=2.6.32-358.2.1.el6.x86_64
> >> auid=500 pid=4979 subj=unconfined_u:system_r:auditd_t:s0
> >> res=success
> >
> > A long time ago the records were meant to be both human readable (don't
> > laugh) and machine consumable. Over time these have been converted
> > name=value pairs. Even the one you mention above has been fixed.
>
> I am not sure if I understood; does it mean that: `auditd start, ver=2.2` is
> outdated and deprecated? I’m confused because Debian did produced a log
> file with this element.
Every time that I find something that doe not conform to name=value, I change
it or submit a patch. The current output is:
type=DAEMON_START msg=audit(1468495169.149:9305): op=start ver=2.6.5
format=enriched kernel=4.6.3-300.fc24.x86_64 auid=4294967295 pid=987
subj=system_u:system_r:auditd_t:s0 res=success\x1dAUID="unset"
Audit 2.2 is from March 2012. That is pretty old now.
Also notice that this event is in the enriched format. Auparse also hides that
fact so that you don't need to worry about it. If you write your own parser,
you'll need to handle both formats.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* audit 2.6.5 released
From: Steve Grubb @ 2016-07-14 16:18 UTC (permalink / raw)
To: linux-audit
Hello,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit. It will also be in rawhide
soon. The ChangeLog is:
- Correct the header length for dispatched events
- Revise buffer handling in auditd to fix dispatched events
- Fix spelling in man pages
- Add documentation link to systemd unit file
- Correct af_unix pathname detection in ausearch/report
- Add remote_ended info to audisp-remote stat dump
This release fixes truncated records passed to audisp plugins when the old
event format was used. It was also discovered that ausearch was not picking
up patchnames for af_unix sockets and this was corrected. Besides that there
were several documentation fixups.
Please let me know if you run across any problems with this release.
-Steve
^ permalink raw reply
* Re: Questions about the standard (Google Summer of Code Project)
From: Mateusz Piotrowski @ 2016-07-14 16:10 UTC (permalink / raw)
To: linux-audit; +Cc: Konrad Witaszczyk
In-Reply-To: <2039823.hgKx5S6ioU@x2>
Hello,
Thank you for your reply! It is absolutely amazing. It clarified a lot.
>> b) Why do some records are separated by a comma and a
>> whitespace? Example:
>>
>> type=DAEMON_START msg=audit(1363713609.192:5426): auditd start,
>> ver=2.2 format=raw kernel=2.6.32-358.2.1.el6.x86_64 auid=500 pid=4979
>> subj=unconfined_u:system_r:auditd_t:s0 res=success
>
> A long time ago the records were meant to be both human readable (don't laugh)
> and machine consumable. Over time these have been converted name=value pairs.
> Even the one you mention above has been fixed.
I am not sure if I understood; does it mean that: `auditd start, ver=2.2` is outdated and deprecated? I’m confused because y Debian did produced a log file with this element.
Cheers,
-m
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* [PATCH] Fix whitespace in CWD record
From: Steve Grubb @ 2016-07-14 14:59 UTC (permalink / raw)
To: linux-audit
Fix the whitespace in the CWD record
Signed-off-by: Steve Grubb <sgrubb@redhat.com>
---
kernel/auditsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -urp linux-4.7.0-0.rc4.git1.1.fc23.x86_64.orig/kernel/auditsc.c linux-4.7.0-0.rc4.git1.1.fc23.x86_64/kernel/auditsc.c
--- linux-4.7.0-0.rc4.git1.1.fc23.x86_64.orig/kernel/auditsc.c 2016-06-25 12:44:41.756440052 -0400
+++ linux-4.7.0-0.rc4.git1.1.fc23.x86_64/kernel/auditsc.c 2016-07-14 09:56:50.222227280 -0400
@@ -1426,7 +1426,7 @@ static void audit_log_exit(struct audit_
if (context->pwd.dentry && context->pwd.mnt) {
ab = audit_log_start(context, GFP_KERNEL, AUDIT_CWD);
if (ab) {
- audit_log_d_path(ab, " cwd=", &context->pwd);
+ audit_log_d_path(ab, "cwd=", &context->pwd);
audit_log_end(ab);
}
}
^ permalink raw reply
* Re: Weird issues in 2.6.5
From: Chris Nandor @ 2016-07-13 22:22 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <3857340.Akeo5bVtPE@x2>
[-- Attachment #1.1: Type: text/plain, Size: 3136 bytes --]
I set heartbeat to 60 on the client and idle to 120 on the server.
Reconnects seem fine now, although I never did nail down the exact
conditions under which reconnects failed.
But I still have the problem of weird buffering on the client side. If I
run `sudo ls` on the client side, locally I get something like:
node=grax.sea.marchex.com type=SYSCALL
msg=audit(1468448156.161:3288765): arch=c000003e syscall=59 success=yes
exit=0 a0=8f81e8 a1=8f7578 a2=8febf0 a3=7ffd3d956370 items=2 ppid=19387
pid=19388 auid=2288 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=pts4 ses=399 comm="ls" exe="/bin/ls" key="rootcmd"
node=grax.sea.marchex.com type=EXECVE
msg=audit(1468448156.161:3288765): argc=1 a0="ls"
node=grax.sea.marchex.com type=CWD msg=audit(1468448156.161:3288765):
cwd="/tmp"
node=grax.sea.marchex.com type=PATH msg=audit(1468448156.161:3288765):
item=0 name="/bin/ls" inode=132438 dev=09:01 mode=0100755 ouid=0 ogid=0
rdev=00:00
node=grax.sea.marchex.com type=PATH msg=audit(1468448156.161:3288765):
item=1 name=(null) inode=71179 dev=09:01 mode=0100755 ouid=0 ogid=0
rdev=00:00
But remotely, I just get:
node=grax.sea.marchex.com type=SYSCALL
msg=audit(1468448156.161:3288765): arch=c000003e syscall=59 success=yes
exit=0 a0=8f81e8 a1=8f7578 a2=8febf0 a3=7ffd3d956370 items=2 ppid=19387
pid=19388 auid=2288 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=pts4 ses=399 comm="ls" exe="/bin/ls" key="rootcmd"
Just the first line of the audit record. No matter how long I wait. If I
then run `sudo ls` again, *then* the rest of the lines show up in the
server's log.
The buffering appears to be on the client side, because if I restart the
server's auditd, those lines are not lost: they still appear in the remote
log ... but not until the next time I run `sudo ls` on the client side.
This is on 1.7.x. This does not happen on 2.4.x or 2.6.x.
On Wed, Jul 13, 2016 at 11:38 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, July 13, 2016 10:51:07 AM EDT Chris Nandor wrote:
> > The only reason I am even upgrading is because of the issues with
> > audisp-remote, the not-reconnecting, and the apparent client-side
> > buffering, that went away with 2.4.x and 2.6.x. So if we decide to ship
> > logs a different way than with audisp-remote, then it might be best to
> > stick with 1.7.x.
>
> This sounds a lot like the idle detection is not set right. In audisp-
> remote.conf there is a setting heartbeat_timeout. This should be set to
> something like 60 or 120. Then on the server in auditd.conf there is a
> setting
> tcp_client_max_idle which should be over twice as high as
> heartbeat_timeout.
> So, you'd set it to 180 or 300.
>
> > That said, so far I see no issues, so we're going to forge ahead and see
> > what happens. I just need to keep in mind what our mitigation plan would
> > be if we do run into issues.
>
> Old utilities won't know what to do with enriched events. AFAICS, that
> would
> be the long term issue. You'll need to do aperl, awk, or cut command to
> trim
> off the unknown part of the event in your logs.
>
> -Steve
>
[-- Attachment #1.2: Type: text/html, Size: 4318 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Weird issues in 2.6.5
From: Chris Nandor @ 2016-07-13 21:14 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <1592387.yc9HYPXd4B@x2>
[-- Attachment #1.1: Type: text/plain, Size: 4615 bytes --]
Is there some documentation on how tty auditing works? I've got it
enabled, but I can't tell when something is going to be logged. It's not
immediate. (Also, on ubuntu 12.04, our older kernel apparently doesn't
support the feature in the pam module that does *not* log passwords. So
that's fun. Maybe not the end of the world, if we get kerberos running for
the log transfer, but ... yuck.)
On Wed, Jul 13, 2016 at 9:32 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, July 13, 2016 9:22:57 AM EDT Chris Nandor wrote:
> > Secondary question: the reason for what I'm working on is that we want to
> > be able to audit what folks do as root on our production hosts. We're
> not
> > a bank, and a perfect solution is not required, but we do need to be able
> > to take reasonable steps to find out if people with access are doing bad
> > things.
> >
> > Is this setup reasonable for that purpose?
>
> Yes. You would want to do two things, first enable tty auditing. This is
> done
> by the pam_tty_audit module. Second consider adding the
> 32-power-abuse.rules
> to your rules.
>
> > I know that's a loaded question
> > and I can answer any questions anyone has that are necessary to figure
> this
> > out. I am not asking so much about rules, but about architecture:
> logging
> > according to whatever rules we set up, to the local audit.log and
> > immediately to a remote using audisp-remote, so the log can't be easily
> > manipulated.
>
> Remote logging is the defence against local log manipulation.
>
> -Steve
>
> > On Wed, Jul 13, 2016 at 8:57 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > > On Wednesday, July 13, 2016 8:47:58 AM EDT Chris Nandor wrote:
> > > > Hi, I had some odd behavior to report.
> > > >
> > > > I am running ubuntu 12.04. Using the default auditd and
> audispd-plugins
> > > > packages for my release, I was able to get logs sent to local syslog
> and
> > >
> > > to
> > >
> > > > a remote auditd server (same basic configuration), but the entries
> were
> > > > being buffered somewhere (I think on the client side), and if the
> server
> > > > died reconnections didn't happen.
> > > >
> > > > So, I wanted a more recent version, so I compiled audit-userspace
> from
> > >
> > > the
> > >
> > > > github src mirror,* trunk@1341.
> > >
> > > The github repo is a mirror of svn and is not always up to date. The
> issue
> > > you
> > > are seeing is fixed in the next commit after the mirror stops.
> > >
> > > https://fedorahosted.org/audit/changeset/1342
> > >
> > > if you want the lastest you can:
> > >
> > > svn co http://svn.fedorahosted.org/svn/audit/trunk
> > >
> > > and then generate from there. I am planning to release audit-2.6.5
> > > tomorrow.
> > > So, if anyone can test the current code, I'd really appreciate it. I'm
> > > hoping
> > > the next release settles down the audit code.
> > >
> > > > When I did, I got some weird results. For example, I expected got
> > > >
> > > > something like this in my audit.log:
> > > > node=host.example.com type=CWD msg=audit(1468363871.644:3279856):
> > > > cwd="/etc/audisp"
> > > >
> > > > And that was as expected. In syslog, I expected to get:
> > > > Jul 13 08:34:53 host audispd: node=host.loc.example.com type=CWD
> > > >
> > > > msg=audit(1468363871.644:3279856): cwd="/etc/audisp"
> > > >
> > > > But instead, I got:
> > > > Jul 13 08:34:53 host audispd: type=CWD msg=node=
> host.loc.example.com
> > > >
> > > > type=CWD msg=audit(1468363871.644
> > > >
> > > > As you can see, the whole thing was prepended with "type=CWD msg=",
> and
> > >
> > > the
> > >
> > > > line was truncated. Similarly, on the remote host, I got the same
> thing:
> > > > type=CWD msg=node=host.loc.example.com type=CWD
> > >
> > > msg=audit(1468363871.644
> > >
> > > > I noticed that the most recent version of the src for ubuntu was
> 2.4.5,
> > >
> > > so
> > >
> > > > I grabbed the src tarball from packages.ubuntu and built it, and now
> > > > everything looks fine. The exact same line I see in my audit.log
> shows
> > >
> > > up
> > >
> > > > in the remote audit.log, with no buffering. When I restart the
> remote
> > > > auditd server or client, it reconnects. syslog has same entry
> > > > (prepended
> > > > with the timestamp etc.). Everything seems happy now.
> > > >
> > > >
> > > > *For some reason I had to define `CC_FOR_BUILD=gcc` in my shell when
> I
> > >
> > > ran
> > >
> > > > `make` from the svn/git src. I did not require this when building
> 2.4.5
> > > > from the ubuntu src.
> > >
> > > I think that should have been detected during configure.
> > >
> > > -Steve
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 6662 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Weird issues in 2.6.5
From: Chris Nandor @ 2016-07-13 21:11 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <17910807.r7x1d9MGge@x2>
[-- Attachment #1.1: Type: text/plain, Size: 2790 bytes --]
I've been using the latest (@r1347) for the last couple of hours, and the
problems I saw have gone away.
On Wed, Jul 13, 2016 at 8:57 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, July 13, 2016 8:47:58 AM EDT Chris Nandor wrote:
> > Hi, I had some odd behavior to report.
> >
> > I am running ubuntu 12.04. Using the default auditd and audispd-plugins
> > packages for my release, I was able to get logs sent to local syslog and
> to
> > a remote auditd server (same basic configuration), but the entries were
> > being buffered somewhere (I think on the client side), and if the server
> > died reconnections didn't happen.
> >
> > So, I wanted a more recent version, so I compiled audit-userspace from
> the
> > github src mirror,* trunk@1341.
>
> The github repo is a mirror of svn and is not always up to date. The issue
> you
> are seeing is fixed in the next commit after the mirror stops.
>
> https://fedorahosted.org/audit/changeset/1342
>
> if you want the lastest you can:
>
> svn co http://svn.fedorahosted.org/svn/audit/trunk
>
> and then generate from there. I am planning to release audit-2.6.5
> tomorrow.
> So, if anyone can test the current code, I'd really appreciate it. I'm
> hoping
> the next release settles down the audit code.
>
>
> > When I did, I got some weird results. For example, I expected got
> > something like this in my audit.log:
> >
> > node=host.example.com type=CWD msg=audit(1468363871.644:3279856):
> > cwd="/etc/audisp"
> >
> > And that was as expected. In syslog, I expected to get:
> >
> > Jul 13 08:34:53 host audispd: node=host.loc.example.com type=CWD
> > msg=audit(1468363871.644:3279856): cwd="/etc/audisp"
> >
> > But instead, I got:
> >
> > Jul 13 08:34:53 host audispd: type=CWD msg=node=host.loc.example.com
> > type=CWD msg=audit(1468363871.644
> >
> > As you can see, the whole thing was prepended with "type=CWD msg=", and
> the
> > line was truncated. Similarly, on the remote host, I got the same thing:
> >
> > type=CWD msg=node=host.loc.example.com type=CWD
> msg=audit(1468363871.644
> >
> > I noticed that the most recent version of the src for ubuntu was 2.4.5,
> so
> > I grabbed the src tarball from packages.ubuntu and built it, and now
> > everything looks fine. The exact same line I see in my audit.log shows
> up
> > in the remote audit.log, with no buffering. When I restart the remote
> > auditd server or client, it reconnects. syslog has same entry (prepended
> > with the timestamp etc.). Everything seems happy now.
> >
> >
> > *For some reason I had to define `CC_FOR_BUILD=gcc` in my shell when I
> ran
> > `make` from the svn/git src. I did not require this when building 2.4.5
> > from the ubuntu src.
>
> I think that should have been detected during configure.
>
> -Steve
>
[-- Attachment #1.2: Type: text/html, Size: 4027 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ 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