From: Steve Grubb <sgrubb@redhat.com>
To: Jiri Jaburek <jjaburek@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: filename not audited for openat() on F28
Date: Mon, 23 Apr 2018 11:29:31 -0400 [thread overview]
Message-ID: <1709554.3lbH4kOyIZ@x2> (raw)
In-Reply-To: <792c3c83-df1c-6e64-bf04-78719b0e0a20@redhat.com>
On Monday, April 23, 2018 6:24:52 AM EDT Jiri Jaburek wrote:
> On 04/20/18 15:37, Steve Grubb wrote:
> > On Friday, April 20, 2018 9:20:29 AM EDT Jiri Jaburek wrote:
> >> (Please CC me on replies.)
> >>
> >> Hello,
> >> I'm trying to run the audit-test suite on Fedora 28 and am running into
> >> it expecting a name= field in the SYSCALL entry.
> >>
> >> augrok --seek=697600 -m1 type==SYSCALL syscall=openat success=no
> >> pid=3951 auid=1000 uid=0 euid=0 suid=0 fsuid=0 gid=0
> >> egid=0 sgid=0 fsgid=0 exit=-13
> >> subj=staff_u:lspp_test_r:lspp_test_generic_t:SystemHigh
> >> name=tmp.owfFtgPOjx/new
> >>
> >> Fedora 28:
> >>
> >> ----
> >> time->Fri Apr 20 15:04:59 2018
> >> type=PROCTITLE msg=audit(1524229499.918:366591):
> >> proctitle=2F62696E2F62617368002E2F72756E2E62617368002D647600323734
> >> type=PATH msg=audit(1524229499.918:366591): item=0
> >> name="tmp.J4IQL7Buxe/" inode=1055495 dev=fd:02 mode=040700 ouid=0 ogid=0
> >> rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 nametype=PARENT
> >> cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
> >> type=CWD msg=audit(1524229499.918:366591):
> >> cwd="/usr/local/eal4_testing/audit-test/syscalls"
> >> type=SYSCALL msg=audit(1524229499.918:366591): arch=c000003e syscall=257
> >> success=no exit=-13 a0=3 a1=7ffc02f0eaf6 a2=c0 a3=16b6010 items=1
> >> ppid=5275 pid=5276 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> >> sgid=0 fsgid=0 tty=(none) ses=2 comm="do_openat"
> >> exe="/usr/local/eal4_testing/audit-test/utils/bin/do_openat"
> >> subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
> >> type=AVC msg=audit(1524229499.918:366591): avc: denied { create } for
> >> pid=5276 comm="do_openat" name="new"
> >> scontext=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023
> >> tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file permissive=0
> >> ----
> >>
> >> RHEL-7.5:
> >>
> >> ----
> >> time->Fri Apr 20 15:06:59 2018
> >> type=PROCTITLE msg=audit(1524229619.726:56605):
> >> proctitle=72756E636F6E0073746166665F753A6C7370705F746573745F723A6C737070
> >> 5F7
> >> 46573745F67656E657269635F743A53797374656D4869676800646F5F6F70656E617400
> >> 2F74
> >> 6D7000746D702E30674C74574A336977622F6E6577006372656174650073746166665F7
> >> 53A6 F626A6563745F723A757365725F746D705F743A53 type=PATH
> >> msg=audit(1524229619.726:56605): item=1
> >> name="tmp.0gLtWJ3iwb/new" objtype=CREATE cap_fp=0000000000000000
> >> cap_fi=0000000000000000 cap_fe=0 cap_fver=0
> >> type=PATH msg=audit(1524229619.726:56605): item=0 name="tmp.0gLtWJ3iwb/"
> >> inode=1055489 dev=fd:02 mode=040700 ouid=0 ogid=0 rdev=00:00
> >> obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 objtype=PARENT
> >> cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
> >> type=CWD msg=audit(1524229619.726:56605):
> >> cwd="/usr/local/eal4_testing/audit-test/syscalls"
> >> type=SYSCALL msg=audit(1524229619.726:56605): arch=c000003e syscall=257
> >> success=no exit=-13 a0=3 a1=7ffc1ecd6b57 a2=c0 a3=0 items=2 ppid=20750
> >> pid=20751 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> >> fsgid=0 tty=(none) ses=1595 comm="do_openat"
> >> exe="/usr/local/eal4_testing/audit-test/utils/bin/do_openat"
> >> subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
> >> ----
> >>
> >> The key difference here is probably the absence of
> >>
> >> type=PATH msg=audit(1524229619.726:56605): item=1
> >> name="tmp.0gLtWJ3iwb/new" objtype=CREATE cap_fp=0000000000000000
> >> cap_fi=0000000000000000 cap_fe=0 cap_fver=0
> >>
> >> on Fedora 28, which augrok looks for.
> >>
> >> Is this expected?
> >>
> >>
> >>
> >> I'm seeing something similar with other syscalls like
> >>
> >> creat("/tmp/tmp.9EsMgMuio7/new", 0700)
> >>
> >> producing
> >>
> >> ----
> >> type=PROCTITLE msg=audit(04/20/2018 15:15:35.547:371576) :
> >> proctitle=runcon staff_u:lspp_test_r:lspp_test_generic_t:SystemHigh
> >> do_creat /tmp/tmp.9EsMgMuio7/new staff_u:object_r:user_tmp_t:SystemLow
> >> type=PATH msg=audit(04/20/2018 15:15:35.547:371576) : item=0
> >> name=/tmp/tmp.9EsMgMuio7/ inode=1572964 dev=fd:02 mode=dir,700 ouid=root
> >> ogid=root rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023
> >> nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
> >> type=CWD msg=audit(04/20/2018 15:15:35.547:371576) :
> >> cwd=/usr/local/eal4_testing/audit-test/syscalls
> >> type=SYSCALL msg=audit(04/20/2018 15:15:35.547:371576) : arch=x86_64
> >> syscall=creat success=no exit=EACCES(Permission denied)
> >> a0=0x7ffc41d04af9 a1=0700 a2=0x0 a3=0x0 items=1 ppid=6779 pid=6780
> >> auid=eal uid=root gid=root euid=root suid=root fsuid=root egid=root
> >> sgid=root fsgid=root tty=(none) ses=2 comm=do_creat
> >> exe=/usr/local/eal4_testing/audit-test/utils/bin/do_creat
> >> subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
> >> type=AVC msg=audit(04/20/2018 15:15:35.547:371576) : avc: denied {
> >> create } for pid=6780 comm=do_creat name=new
> >> scontext=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023
> >> tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file permissive=0
> >
> > This record says you were denied create. That means it can report the
> > parent object and its properties. But it cannot report on the object
> > being created because it has no properties except an intended name. But
> > it has no device, inode, owner, label, etc. If the system were in
> > permissive mode, you will probably get the actual object and its
> > properties.
>
> Thanks, however I don't know if the reply was to openat() or creat()
Both have a denial AVC for the action that the syscall is performing.
> and I also don't know if it's an expected change compared to RHEL-7 or if
> I should treat it as bug.
The current behavior is a change. I suspect that because the name is about
all we have at this point, the record was dropped because it cannot be
normalized. IOW, its missing a bunch of fields. The old behavior is nice,
though, because you can see what was denied.
I don't know if this is considered a bug. Paul or Richard might need to say
if this is the new behavior going forward.
-Steve
> >> ----
> >>
> >> but the lack of "/new" in PATH here seems more like a bug.
> >>
> >> Thanks,
> >> Jiri
> >>
> >> --
> >> Linux-audit mailing list
> >> Linux-audit@redhat.com
> >> https://www.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2018-04-23 15:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-20 13:20 filename not audited for openat() on F28 Jiri Jaburek
2018-04-20 13:37 ` Steve Grubb
2018-04-23 10:24 ` Jiri Jaburek
2018-04-23 15:29 ` Steve Grubb [this message]
2018-04-23 22:12 ` Paul Moore
2018-04-24 16:40 ` Richard Guy Briggs
2018-04-24 20:08 ` Richard Guy Briggs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1709554.3lbH4kOyIZ@x2 \
--to=sgrubb@redhat.com \
--cc=jjaburek@redhat.com \
--cc=linux-audit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.