From: Casey Schaufler <casey@schaufler-ca.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: Richard Guy Briggs <rgb@redhat.com>,
James Morris <jmorris@namei.org>,
linux-audit@redhat.com, casey.schaufler@intel.com
Subject: Re: [PATCH v15 00/23] LSM: Module stacking for AppArmor
Date: Mon, 9 Mar 2020 10:15:14 -0700 [thread overview]
Message-ID: <2f2695b5-dad9-9207-27a4-3786dff29c04@schaufler-ca.com> (raw)
In-Reply-To: <52786936.4IqQbOQo6H@x2>
On 3/6/2020 9:14 AM, Steve Grubb wrote:
> On Tuesday, March 3, 2020 12:22:31 PM EST Casey Schaufler wrote:
>> On 2/27/2020 9:29 AM, Casey Schaufler wrote:
>>> On 2/21/2020 4:03 PM, Casey Schaufler wrote:
>>>> Resending the audit related patches to the audit list,
>>>> as there have been problems with the CC lists.
>>> There's an awful lot of interaction between the module stacking
>>> and the audit sub-system. I have not gotten much feedback about
>>> the audit changes recently, but I can't bring myself to think
>>> this means there aren't any concerns. Before I start pushing for
>>> the stacking to get pulled I would really appreciate either ACKs
>>> or meaningful comments from the audit community. I can see that
>>> there's a lot going on in the audit sub-system, and appreciate
>>> that priorities may be elsewhere.
>>>
>>> Thank you.
>> I have to start pushing on this series. If the audit community
>> hasn't any additional feedback, I'll take it that what's here is
>> acceptable and move my lobbying efforts elsewhere.
> There is a limit in user space that may cause problems.
Oh my.
> MAX_AUDIT_MESSAGE_LENGTH 8970 // PATH_MAX*2+CONTEXT_SIZE*2+11+256+1
>
> This has been in place for years. This is designed to hand the AUDIT_PATH
> record which can have PATH_MAX * 2 for name field, then it has 11 bytes set
> aside for other fields, then 256 bytes to handle the largest possible SELinux
> label. So, if we are agoing to stab other LSM's into the object identifier,
> how big is it? Do you have a max size that everyone has to fit into?
We already have a potential problem here. This implicitly limits
the size of a label for all security modules. While we don't have
a problem for any of the existing modules, it reasonable to assume
that some module some day may want more than that. We have a dearth
of documentation on what security modules can and can't do, including
limits like this.
> Changing this constant in user space is not something that you set and are
> done. Everything will need recompiling.
Unfortunate, but hardly a surprise. I can see that having a MAX_AUDIT_MESSAGE_LENGTH
is going to require some finagling regardless of what value it has.
> And one other question, no field names are changing because of this are they?
No field names change. subj= and obj= remain as they are.
subj_selinux=, obj_smack= and the like are added.
> And if a distribution has only 1 LSM, will anyone notice a change in format?
No. Explicit steps are taken to ensure that the new fields are produced only
if there's more than one active security module.
> -Steve
Thanks for the response. I'll be making more comments based on Paul's feedback.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2020-03-09 17:15 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200222000407.110158-1-casey.ref@schaufler-ca.com>
2020-02-22 0:03 ` [PATCH v15 00/23] LSM: Module stacking for AppArmor Casey Schaufler
2020-02-22 0:03 ` Casey Schaufler
2020-02-22 0:03 ` [PATCH v15 01/23] LSM: Infrastructure management of the sock security Casey Schaufler
2020-02-22 0:03 ` Casey Schaufler
2020-02-22 0:03 ` [PATCH v15 02/23] LSM: Create and manage the lsmblob data structure Casey Schaufler
2020-02-22 0:03 ` Casey Schaufler
2020-03-06 20:55 ` Paul Moore
2020-02-22 0:03 ` [PATCH v15 03/23] LSM: Use lsmblob in security_audit_rule_match Casey Schaufler
2020-02-22 0:03 ` Casey Schaufler
2020-03-06 22:01 ` Paul Moore
2020-03-09 23:58 ` Casey Schaufler
2020-03-10 0:55 ` Paul Moore
2020-02-22 0:03 ` [PATCH v15 07/23] LSM: Use lsmblob in security_secid_to_secctx Casey Schaufler
2020-02-22 0:03 ` Casey Schaufler
2020-03-07 1:17 ` Paul Moore
2020-02-22 0:03 ` [PATCH v15 08/23] LSM: Use lsmblob in security_ipc_getsecid Casey Schaufler
2020-02-22 0:03 ` Casey Schaufler
2020-03-07 1:21 ` Paul Moore
2020-02-22 0:04 ` [PATCH v15 09/23] LSM: Use lsmblob in security_task_getsecid Casey Schaufler
2020-02-22 0:04 ` Casey Schaufler
2020-02-22 0:04 ` [PATCH v15 10/23] LSM: Use lsmblob in security_inode_getsecid Casey Schaufler
2020-02-22 0:04 ` Casey Schaufler
2020-02-22 0:04 ` [PATCH v15 11/23] LSM: Use lsmblob in security_cred_getsecid Casey Schaufler
2020-02-22 0:04 ` Casey Schaufler
2020-03-07 1:36 ` Paul Moore
2020-02-22 0:04 ` [PATCH v15 12/23] IMA: Change internal interfaces to use lsmblobs Casey Schaufler
2020-02-22 0:04 ` Casey Schaufler
2020-02-22 0:04 ` [PATCH v15 14/23] LSM: Ensure the correct LSM context releaser Casey Schaufler
2020-02-22 0:04 ` Casey Schaufler
2020-02-22 0:04 ` [PATCH v15 15/23] LSM: Use lsmcontext in security_secid_to_secctx Casey Schaufler
2020-02-22 0:04 ` Casey Schaufler
2020-03-07 2:01 ` Paul Moore
2020-02-22 0:04 ` [PATCH v15 20/23] Audit: Add subj_LSM fields when necessary Casey Schaufler
2020-02-22 0:04 ` Casey Schaufler
2020-03-07 2:18 ` Paul Moore
2020-03-07 2:24 ` Paul Moore
2020-03-10 1:25 ` Casey Schaufler
2020-03-10 21:46 ` Paul Moore
2020-02-22 0:04 ` [PATCH v15 21/23] Audit: Include object data for all security modules Casey Schaufler
2020-02-22 0:04 ` Casey Schaufler
2020-03-07 2:31 ` Paul Moore
2020-03-09 17:45 ` Casey Schaufler
2020-03-09 17:59 ` Paul Moore
2020-03-09 23:01 ` Casey Schaufler
2020-03-10 21:42 ` Paul Moore
2020-02-27 17:29 ` [PATCH v15 00/23] LSM: Module stacking for AppArmor Casey Schaufler
2020-03-03 17:22 ` Casey Schaufler
2020-03-03 17:54 ` Paul Moore
2020-03-03 17:58 ` Casey Schaufler
2020-03-06 17:14 ` Steve Grubb
2020-03-09 17:15 ` Casey Schaufler [this message]
[not found] <20200406210035.42547-1-casey.ref@schaufler-ca.com>
2020-04-06 21:00 ` Casey Schaufler
[not found] <20200406205509.42473-1-casey.ref@schaufler-ca.com>
2020-04-06 20:54 ` Casey Schaufler
[not found] <20200406205023.42338-1-casey.ref@schaufler-ca.com>
2020-04-06 20:50 ` Casey Schaufler
[not found] <20200406204037.42262-1-casey.ref@schaufler-ca.com>
2020-04-06 20:40 ` Casey Schaufler
2020-04-06 20:40 ` Casey Schaufler
[not found] <20200406203246.42079-1-casey.ref@schaufler-ca.com>
2020-04-06 20:32 ` Casey Schaufler
2020-04-06 20:32 ` Casey Schaufler
[not found] <20200214234203.7086-1-casey.ref@schaufler-ca.com>
2020-02-14 23:41 ` 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=2f2695b5-dad9-9207-27a4-3786dff29c04@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=casey.schaufler@intel.com \
--cc=jmorris@namei.org \
--cc=linux-audit@redhat.com \
--cc=rgb@redhat.com \
--cc=sgrubb@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.