Linux-audit Digest, Vol 142, Issue 18
aung
unixaung at gmail.com
Thu Jul 14 18:51:28 UTC 2016
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 at redhat.com> wrote:
> Send Linux-audit mailing list submissions to
> linux-audit at 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 at redhat.com
>
> You can reach the person managing the list at
> linux-audit-owner at 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 at pobox.com>
> To: Steve Grubb <sgrubb at redhat.com>
> Cc: linux-audit at redhat.com
> Subject: Re: Weird issues in 2.6.5
> Message-ID:
> <CAHcE2wrPftjsy2QMB4+qsa9o-S=
> xWqjiD+rtKX0wM24ksT0tkQ at 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 at 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 at redhat.com>
> To: linux-audit at redhat.com
> Subject: [PATCH] Fix whitespace in CWD record
> Message-ID: <1772571.A9vuBSQyZx at x2>
> Content-Type: text/plain; charset="us-ascii"
>
> Fix the whitespace in the CWD record
>
> Signed-off-by: Steve Grubb <sgrubb at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
> End of Linux-audit Digest, Vol 142, Issue 18
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20160715/adabd11d/attachment.htm>
More information about the Linux-audit
mailing list