linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Richard Guy Briggs <rgb@redhat.com>,
	linux-api@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Linux-Audit Mailing List <linux-audit@redhat.com>,
	linux-fsdevel@vger.kernel.org, Eric Paris <eparis@parisplace.org>
Subject: Re: [PATCH V1] audit: log xattr args not covered by syscall record
Date: Mon, 10 May 2021 19:52:40 -0400	[thread overview]
Message-ID: <CAHC9VhQdV93G5N_BKsxuDCtFbm9-xvAkve02t5sGOi9Mam2Wtg@mail.gmail.com> (raw)
In-Reply-To: <242f107a-3b74-c1c2-abd6-b3f369170023@schaufler-ca.com>

On Mon, May 10, 2021 at 12:30 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 5/7/2021 6:54 PM, Richard Guy Briggs wrote:
> > On 2021-05-07 14:03, Casey Schaufler wrote:
> >> On 5/7/2021 12:55 PM, Richard Guy Briggs wrote:
> >>> The *setxattr syscalls take 5 arguments.  The SYSCALL record only lists
> >>> four arguments and only lists pointers of string values.  The xattr name
> >>> string, value string and flags (5th arg) are needed by audit given the
> >>> syscall's main purpose.
> >>>
> >>> Add the auxiliary record AUDIT_XATTR (1336) to record the details not
> >>> available in the SYSCALL record including the name string, value string
> >>> and flags.
> >>>
> >>> Notes about field names:
> >>> - name is too generic, use xattr precedent from ima
> >>> - val is already generic value field name
> >>> - flags used by mmap, xflags new name
> >>>
> >>> Sample event with new record:
> >>> type=PROCTITLE msg=audit(05/07/2021 12:58:42.176:189) : proctitle=filecap /tmp/ls dac_override
> >>> type=PATH msg=audit(05/07/2021 12:58:42.176:189) : item=0 name=(null) inode=25 dev=00:1e mode=file,755 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
> >>> type=CWD msg=audit(05/07/2021 12:58:42.176:189) : cwd=/root
> >>> type=XATTR msg=audit(05/07/2021 12:58:42.176:189) : xattr="security.capability" val=01 xflags=0x0
> >> Would it be sensible to break out the namespace from the attribute?
> >>
> >>      attrspace="security" attrname="capability"
> > Do xattrs always follow this nomenclature?  Or only the ones we care
> > about?
>
> Xattrs always have a namespace (man 7 xattr) of "user", "trusted",
> "system" or "security". It's possible that additional namespaces will
> be created in the future, although it seems unlikely given that only
> "security" is widely used today.

Why should audit care about separating the name into two distinct
fields, e.g. "attrspace" and "attrname", instead of just a single
"xattr" field with a value that follows the "namespace.attribute"
format that is commonly seen by userspace?

> >> Why isn't val= quoted?
> > Good question.  I guessed it should have been since it used
> > audit_log_untrustedstring(), but even the raw output is unquoted unless
> > it was converted by auditd to unquoted before being stored to disk due
> > to nothing offensive found in it since audit_log_n_string() does add
> > quotes.  (hmmm, bit of a run-on sentence there...)
> >
> >> The attribute value can be a .jpg or worse. I could even see it being an eBPF
> >> program (although That Would Be Wrong) so including it in an audit record could
> >> be a bit of a problem.
> > In these cases it would almost certainly get caught by the control
> > character test audit_string_contains_control() in
> > audit_log_n_untrustedstring() called from audit_log_untrustedstring()
> > and deliver it as hex.
>
> In that case I'm more concerned with the potential size than with
> quoting. One of original use cases proposed for xattrs (back in the
> SGI Irix days) was to attach a bitmap to be used as the icon in file
> browsers as an xattr. Another was to attach the build instructions
> and source used to create a binary. None of that is information you'd
> want to see in a audit record. On the other hand, if the xattr was an
> eBPF program used to make access control decisions, you would want at
> least a reference to it in the audit record.

It would be interesting to see how this code would handle arbitrarily
large xattr values, or at the very least large enough values to blow
up the audit record size.

As pointed out elsewhere in this thread, and brought up again above
(albeit indirectly), I'm guessing we don't really care about *all*
xattrs, just the "special" xattrs that are security relevant, in which
case I think we need to reconsider how we collect this data.

I think it would also be very good to see what requirements may be
driving this work.  Is it purely a "gee, this seems important" or is
it a hard requirement in a security certification for example.

-- 
paul moore
www.paul-moore.com

  reply	other threads:[~2021-05-10 23:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-07 19:55 [PATCH V1] audit: log xattr args not covered by syscall record Richard Guy Briggs
2021-05-07 21:03 ` Casey Schaufler
2021-05-08  1:54   ` Richard Guy Briggs
2021-05-10 16:30     ` Casey Schaufler
2021-05-10 23:52       ` Paul Moore [this message]
2021-05-11  0:37         ` Casey Schaufler
2021-05-11  1:28           ` Paul Moore
2021-05-11 14:00             ` Casey Schaufler
2021-05-11 15:52               ` Paul Moore

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=CAHC9VhQdV93G5N_BKsxuDCtFbm9-xvAkve02t5sGOi9Mam2Wtg@mail.gmail.com \
    --to=paul@paul-moore.com \
    --cc=casey@schaufler-ca.com \
    --cc=eparis@parisplace.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgb@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).