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
********************************************