From: Steve Grubb <sgrubb@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Audit <linux-audit@redhat.com>,
linux-api@vger.kernel.org, Jan Kara <jack@suse.cz>,
Paul Moore <pmoore@redhat.com>
Subject: Re: [PATCH v3 1/1] audit: Record fanotify access control decisions
Date: Mon, 25 Sep 2017 16:37:47 -0400 [thread overview]
Message-ID: <2007095.3atlGr9L8Y@x2> (raw)
In-Reply-To: <CAOQ4uxizzR=1wMCVMtwSWJzMpopHBK=9GtKnsz-5LP_bsELMgA@mail.gmail.com>
On Monday, September 25, 2017 2:49:19 PM EDT Amir Goldstein wrote:
> On Mon, Sep 25, 2017 at 6:19 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > Hello,
> >
> > The fanotify interface allows user space daemons to make access
> > control decisions. Under common criteria requirements, we need to
> > optionally record decisions based on policy. This patch adds a bit mask,
> > FAN_AUDIT, that a user space daemon can 'or' into the response decision
> > which will tell the kernel that it made a decision and record it.
> >
> > It would be used something like this in user space code:
> > response.response = FAN_DENY | FAN_AUDIT;
> > write(fd, &response, sizeof(struct fanotify_response));
> >
> > When the syscall ends, the audit system will record the decision as a
> > AUDIT_FANOTIFY auxiliary record to denote that the reason this event
> > occurred is the result of an access control decision from fanotify
> > rather than DAC or MAC policy.
> >
> > A sample event looks like this:
> >
> > type=PATH msg=audit(1504310584.332:290): item=0 name="./evil-ls"
> > inode=1319561 dev=fc:03 mode=0100755 ouid=1000 ogid=1000 rdev=00:00
> > obj=unconfined_u:object_r:user_home_t:s0 nametype=NORMAL
> > type=CWD msg=audit(1504310584.332:290): cwd="/home/sgrubb"
> > type=SYSCALL msg=audit(1504310584.332:290): arch=c000003e syscall=2
> > success=no exit=-1 a0=32cb3fca90 a1=0 a2=43 a3=8 items=1 ppid=901
> > pid=959 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000
> > fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=3 comm="bash"
> > exe="/usr/bin/bash" subj=unconfined_u:unconfined_r:unconfined_t:
> > s0-s0:c0.c1023 key=(null)
> > type=FANOTIFY msg=audit(1504310584.332:290): resp=2
> >
> > Prior to using the audit flag, the developer needs to call
> > fanotify_init or'ing in FAN_AUDIT_ENABLE to ensure that the kernel
> > supports auditing. The calling process must also have the CAP_AUDIT_WRITE
> > capability.
> >
> > Signed-off-by: sgrubb <sgrubb@redhat.com>
>
> Sorry, found more nits...
>
> > @@ -805,6 +808,13 @@ SYSCALL_DEFINE2(fanotify_init, unsigned int, flags,
> > unsigned int, event_f_flags)>
> > group->fanotify_data.max_marks =
> > FANOTIFY_DEFAULT_MAX_MARKS;
> >
> > }
> >
> > + if (flags & FAN_ENABLE_AUDIT) {
> > + fd = -EPERM;
> > + if (!capable(CAP_AUDIT_WRITE))
> > + goto out_destroy_group;
> > + group->audit_enabled = 1;
> > + }
> > +
>
> App should not be able to enable audit if audit is not configured in kernel.
> So there should be code that returns EINVAL for flag FAN_ENABLE_AUDIT if
> CONFIG_AUDITSYSCALL is not defined.
> Same deal as flag FAN_ALL_PERM_EVENTS and kernel config
> CONFIG_FANOTIFY_ACCESS_PERMISSIONS in fanotify_mark().
> Perhaps it is better not to extend FAN_ALL_INIT_FLAGS and explicitly
> test (flags & ~(FAN_ALL_INIT_FLAGS | FAN_ENABLE_AUDIT)) in fanotify_init()
> under ifdef, as done in fanotify_mark()?
OK. How about this, I do the (flags & ~(FAN_ALL_INIT_FLAGS |
FAN_ENABLE_AUDIT)) with an ifdef. This will cause -EINVAL if FAN_ENABLE_AUDIT
is attempted and CONFIG_AUDITSYSCALL is not defined. So, the code initially
discussed above for audit_enabled would not need to have an #else. I can
surround the "if" block with a CONFIG_AUDITSYSCALL so that it compiles out if
audit is not being used. This will cause audit_enabled to always be false when
audit is not compiled in.
> > diff --git a/include/linux/fsnotify_backend.h
> > b/include/linux/fsnotify_backend.h index c6c6931..8f7ea68 100644
> > --- a/include/linux/fsnotify_backend.h
> > +++ b/include/linux/fsnotify_backend.h
> > @@ -193,6 +193,7 @@ struct fsnotify_group {
> >
> > } fanotify_data;
> >
> > #endif /* CONFIG_FANOTIFY */
> >
> > };
> >
> > + unsigned int audit_enabled;
>
> This one should be bool and it belongs inside fanotify_data union member.
> Also, you need to translate it back to FAN_ENABLE_AUDIT in
> fanotify_show_fdinfo().
OK. Will fix this.
-Steve
next prev parent reply other threads:[~2017-09-25 20:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-25 15:19 [PATCH v3 1/1] audit: Record fanotify access control decisions Steve Grubb
2017-09-25 18:49 ` Amir Goldstein
2017-09-25 20:37 ` Steve Grubb [this message]
2017-09-26 4:10 ` Amir Goldstein
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=2007095.3atlGr9L8Y@x2 \
--to=sgrubb@redhat.com \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=linux-api@vger.kernel.org \
--cc=linux-audit@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=pmoore@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).