Linux-Security-Module Archive on lore.kernel.org
 help / color / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Stephen Smalley <stephen.smalley.work@gmail.com>,
	casey.schaufler@intel.com, James Morris <jmorris@namei.org>,
	LSM List <linux-security-module@vger.kernel.org>,
	SElinux list <selinux@vger.kernel.org>,
	Kees Cook <keescook@chromium.org>,
	John Johansen <john.johansen@canonical.com>,
	penguin-kernel@i-love.sakura.ne.jp,
	Stephen Smalley <sds@tycho.nsa.gov>,
	linux-audit@redhat.com, Steve Grubb <sgrubb@redhat.com>,
	Richard Guy Briggs <rgb@redhat.com>
Subject: Re: [PATCH v17 20/23] Audit: Add a new record for multiple subject LSM attributes
Date: Tue, 19 May 2020 11:48:47 -0400
Message-ID: <CAHC9VhQOVRYTvjp4kmJx-rziSqeRb-=XSKYMBeN_o-ioJp7JNg@mail.gmail.com> (raw)
In-Reply-To: <774a37e3-3469-d606-a468-a57892b44645@schaufler-ca.com>

On Mon, May 18, 2020 at 8:16 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 5/18/2020 3:21 PM, Paul Moore wrote:
> > On Mon, May 18, 2020 at 4:43 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> On 5/18/2020 11:02 AM, Stephen Smalley wrote:
> >>> On Thu, May 14, 2020 at 7:30 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >>>> Create a new audit record type to contain the subject information
> >>>> when there are multiple security modules that require such data.
> >>>> This record is emitted before the other records for the event, but
> >>>> is linked with the same timestamp and serial number.
> >>>>
> >>>> Reviewed-by: Kees Cook <keescook@chromium.org>
> >>>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> >>>> Cc: linux-audit@redhat.com
> >>>> ---
> >>> With this patch, I see userspace audit records like this one:
> >>>
> >>> type=SYSTEM_BOOT msg=audit(1589816792.181:103): pid=789 uid=0
> >>> auid=4294967295 ses=4294967295 subj=? subj=system_u:system_r:init_t:s0
> >>> msg=' comm="systemd-update-utmp"
> >>> exe="/usr/lib/systemd/systemd-update-utmp" hostname=? addr=?
> >>> terminal=? res=success'
> >>>
> >>> I'm guessing that userspace is appending the second subj= field when
> >>> it sees subj=? or otherwise is missing subj= information?
> >> I haven't looked at the userspace code, but I expect you're right.
> >> It looks like there will need to be some change in the userspace
> >> for the multiple LSM case. The "completion" shown here isn't correct,
> >> because it only fills in one of the subject attributes, not both.
> > Wait, didn't we agree on a a "subj=? subj_selinux=XXX
> > subj_apparmor=YYY subj_smack=ZZZ" format?  It looks like there are two
> > 'subj' fields in the record above which is bad, don't do that please.
>
> That's not something that's coming from the kernel.

Yes it is.  Well, sorta.  With audit *everything* must come from the
kernel in order to meet the security goals that audit tries to
achieve.  I know you already know most of this, but I'm mentioning it
for others who are following along.

The record above is an audit user message which is a message that is
generated in userspace by a trusted process and written to the kernel,
the kernel then generates an audit record based on this message and
inserts it into the audit stream.  The text string that originates
from the userspace process is placed in the "msg" field; the
UID/AUID/subj/etc. information is supplied by the kernel (we don't
want to trust the process any more than absolutely necessary).

On my system, running a random but fairly modern kernel (a 5.7.0-rc5
variant) I see the following for the SYSTEM_BOOT record on my most
recent boot:

  type=SYSTEM_BOOT msg=audit(05/13/2020 14:19:23.983:89) : pid=633
    uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0
    msg=' comm=systemd-update-utmp
      exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=?
      terminal=? res=success'

... pay special attention to the single "subj" field ;)

> I'll check again, but I think that everyplace in the kernel that
> produces a subj= has been trained to create a type=1420 record
> instead.
>
> >>> Then we have kernel audit records like this:
> >>>
> >>> type=PROCTITLE msg=audit(1589816791.959:101): proctitle=2F7362696E2F617564697463
> >>> 746C002D52002F6574632F61756469742F61756469742E72756C6573
> >>> type=SYSCALL msg=audit(1589816791.959:101): arch=c000003e syscall=44
> >>> success=yes exit=1056 a0=3 a1=7fff9ccc98a0 a2=420 a3=0 items=0
> >>> ppid=773 pid=783 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
> >>> egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="auditctl"
> >>> exe="/usr/sbin/auditctl" subj=? key=(null)
> >>> type=UNKNOWN[1420] msg=audit(1589816791.959:101):
> >>> subj_selinux=system_u:system_r:unconfined_service_t:s0
> >>> subj_apparmor==unconfined
> >>> type=CONFIG_CHANGE msg=audit(1589816791.959:101): auid=4294967295
> >>> ses=4294967295 subj=? op=add_rule key=(null) list=1 res=1
> >>> type=UNKNOWN[1420] msg=audit(1589816791.959:101):
> >>> subj_selinux=system_u:system_r:unconfined_service_t:s0
> >>> subj_apparmor==unconfined
> >>>
> >>> where we are getting multiple copies of the new record type, one for
> >>> each record type that had subj=?.
> >> While obviously wasteful, the type=1420 behavior is consistent with
> >> the subj=? behavior, which is to duplicate the subj= value. I know
> >> we've got enough hobgoblins in the audit system that we don't need
> >> to add any more in the name of a foolish consistency.
> > You need to provide a bit more reason why we need byte-for-byte
> > duplicate records in a single event.  As it currently stands this
> > looks like something we definitely don't want.
>
> The CONFIG_CHANGE record already duplicates the subj= information
> in the SYSCALL record.

Yeah, let's not get started on that discussion ;)  Thankfully that
isn't what I was talking about in my earlier comment in this thread.

In the audit event above we see a number of records all part of a
single event (they all share the same timestamp:
"audit(1589816791.959:101)"), and in this single event we see two
identical records of type 1420 (the new record you are proposing).
That is my concern, I would expect just a single type 1420 record to
be added to this event.

For those who may not be familiar with audit, this is what a typical
audit event with a CONFIG_CHANGE record that adds an audit filter rule
looks like with an unpatched kernel:

  type=PROCTITLE msg=audit(05/13/2020 13:55:25.598:10349) :
    proctitle=auditctl -a always,exit -F arch b64 -S bpf
      -k testsuite-1589392525-yPWwmHYp
  type=SYSCALL msg=audit(05/13/2020 13:55:25.598:10349) : arch=x86_64
    syscall=send to success=yes exit=1088 a0=0x4 a1=0x7ffc93b8c910
    a2=0x440 a3=0x0 items=0 ppid=2650 pid=2659 auid=root uid=root
    gid=root euid=root suid=root fsuid=root egid=root sgid=root
    fsgid=root tty=pts0 ses=1 comm=auditctl exe=/usr/sbin/auditctl
    subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
  type=CONFIG_CHANGE msg=audit(05/13/2020 13:55:25.598:10349) : auid=root
    ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
    op=add_rule key=testsuite-1589392525-yPWwmHYp list=exit res=yes

> I just maintained the duplication. You're
> right, it's silly to have two identical type=1420 records for the event.
> I will have to come up with a mechanism to prevent the duplication.
> with luck, there's already a similar case for some other record.

-- 
paul moore
www.paul-moore.com

  parent reply index

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200514221142.11857-1-casey.ref@schaufler-ca.com>
2020-05-14 22:11 ` [PATCH v17 00/23] LSM: Module stacking for AppArmor Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 01/23] LSM: Infrastructure management of the sock security Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 02/23] LSM: Create and manage the lsmblob data structure Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 03/23] LSM: Use lsmblob in security_audit_rule_match Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 04/23] LSM: Use lsmblob in security_kernel_act_as Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 05/23] net: Prepare UDS for security module stacking Casey Schaufler
2020-05-18 17:02     ` Stephen Smalley
2020-05-14 22:11   ` [PATCH v17 06/23] Use lsmblob in security_secctx_to_secid Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 07/23] LSM: Use lsmblob in security_secid_to_secctx Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 08/23] LSM: Use lsmblob in security_ipc_getsecid Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 09/23] LSM: Use lsmblob in security_task_getsecid Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 10/23] LSM: Use lsmblob in security_inode_getsecid Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 11/23] LSM: Use lsmblob in security_cred_getsecid Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 12/23] IMA: Change internal interfaces to use lsmblobs Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 13/23] LSM: Specify which LSM to display Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 14/23] LSM: Ensure the correct LSM context releaser Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 15/23] LSM: Use lsmcontext in security_secid_to_secctx Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 16/23] LSM: Use lsmcontext in security_inode_getsecctx Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 17/23] LSM: security_secid_to_secctx in netlink netfilter Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 18/23] NET: Store LSM netlabel data in a lsmblob Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 19/23] LSM: Verify LSM display sanity in binder Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 20/23] Audit: Add a new record for multiple subject LSM attributes Casey Schaufler
2020-05-18 18:02     ` Stephen Smalley
2020-05-18 20:42       ` Casey Schaufler
2020-05-18 22:21         ` Paul Moore
2020-05-19  0:16           ` Casey Schaufler
2020-05-19  0:58             ` Casey Schaufler
2020-05-19 15:48             ` Paul Moore [this message]
2020-05-14 22:11   ` [PATCH v17 21/23] Audit: Add a new record for multiple object " Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 22/23] LSM: Add /proc attr entry for full LSM context Casey Schaufler
2020-05-14 22:11   ` [PATCH v17 23/23] AppArmor: Remove the exclusive flag Casey Schaufler

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='CAHC9VhQOVRYTvjp4kmJx-rziSqeRb-=XSKYMBeN_o-ioJp7JNg@mail.gmail.com' \
    --to=paul@paul-moore.com \
    --cc=casey.schaufler@intel.com \
    --cc=casey@schaufler-ca.com \
    --cc=jmorris@namei.org \
    --cc=john.johansen@canonical.com \
    --cc=keescook@chromium.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=rgb@redhat.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    --cc=sgrubb@redhat.com \
    --cc=stephen.smalley.work@gmail.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

Linux-Security-Module Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-security-module/0 linux-security-module/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-security-module linux-security-module/ https://lore.kernel.org/linux-security-module \
		linux-security-module@vger.kernel.org
	public-inbox-index linux-security-module

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-security-module


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git