From: John Johansen <john.johansen@canonical.com>
To: Casey Schaufler <casey@schaufler-ca.com>,
Stephen Smalley <stephen.smalley.work@gmail.com>
Cc: SElinux list <selinux@vger.kernel.org>,
James Morris <jmorris@namei.org>,
LSM List <linux-security-module@vger.kernel.org>,
linux-audit@redhat.com,
Casey Schaufler <casey.schaufler@intel.com>,
Stephen Smalley <sds@tycho.nsa.gov>
Subject: Re: [PATCH v20 05/23] net: Prepare UDS for security module stacking
Date: Wed, 9 Sep 2020 11:33:37 -0700 [thread overview]
Message-ID: <c4c78d28-61f5-74fe-6a9f-3c41c178d556@canonical.com> (raw)
In-Reply-To: <258ef772-0560-3fc3-9b9b-89941a7713fd@schaufler-ca.com>
On 9/9/20 11:19 AM, Casey Schaufler wrote:
> On 9/9/2020 6:19 AM, Stephen Smalley wrote:
>> On Tue, Sep 8, 2020 at 8:21 PM John Johansen
>> <john.johansen@canonical.com> wrote:
>>> On 9/8/20 4:37 PM, Casey Schaufler wrote:
>>>> On 9/8/2020 6:35 AM, Stephen Smalley wrote:
>>>>> On Mon, Sep 7, 2020 at 9:28 PM Stephen Smalley
>>>>> <stephen.smalley.work@gmail.com> wrote:
>>>>>> On Sat, Sep 5, 2020 at 3:07 PM John Johansen
>>>>>> <john.johansen@canonical.com> wrote:
>>>>>>> On 9/5/20 11:13 AM, Casey Schaufler wrote:
>>>>>>>> On 9/5/2020 6:25 AM, Paul Moore wrote:
>>>>>>>>> On Fri, Sep 4, 2020 at 7:58 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>>>>>> On 9/4/2020 2:53 PM, Paul Moore wrote:
>>>>>>>>>>> On Fri, Sep 4, 2020 at 5:35 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>>>>>>>> On 9/4/2020 1:08 PM, Paul Moore wrote:
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>>>> I understand the concerns you mention, they are all valid as far as
>>>>>>>>>>> I'm concerned, but I think we are going to get burned by this code as
>>>>>>>>>>> it currently stands.
>>>>>>>>>> Yes, I can see that. We're getting burned by the non-extensibility
>>>>>>>>>> of secids. It will take someone smarter than me to figure out how to
>>>>>>>>>> fit N secids into 32bits without danger of either failure or memory
>>>>>>>>>> allocation.
>>>>>>>>> Sooo what are the next steps here? It sounds like there is some
>>>>>>>>> agreement that the currently proposed unix_skb_params approach is a
>>>>>>>>> problem, but it also sounds like you just want to merge it anyway?
>>>>>>>> There are real problems with all the approaches. This is by far the
>>>>>>>> least invasive of the lot. If this is acceptable for now I will commit
>>>>>>>> to including the dynamic allocation version in the full stacking
>>>>>>>> (e.g. Smack + SELinux) stage. If it isn't, well, this stage is going
>>>>>>>> to take even longer than it already has. Sigh.
>>>>>>>>
>>>>>>>>
>>>>>>>>> I was sorta hoping for something a bit better.
>>>>>>>> I will be looking at alternatives. I am very much open to suggestions.
>>>>>>>> I'm not even 100% convinced that Stephen's objections to my separate
>>>>>>>> allocation strategy outweigh its advantages. If you have an opinion on
>>>>>>>> that, I'd love to hear it.
>>>>>>>>
>>>>>>> fwiw I prefer the separate allocation strategy, but as you have already
>>>>>>> said it trading off one set of problems for another. I would rather see
>>>>>>> this move forward and one set of trade offs isn't significantly worse
>>>>>>> than the other to me so, either wfm.
>>>>>> I remain unclear that AppArmor needs this patch at all even when
>>>>>> support for SO_PEERSEC lands.
>>>>>> Contrary to the patch description, it is about supporting SCM_SECURITY
>>>>>> for datagram not SO_PEERSEC. And I don't know of any actual users of
>>>>>> SCM_SECURITY even for SELinux, just SO_PEERSEC.
>>>>> I remembered that systemd once tried using SCM_SECURITY but that was a
>>>>> bug since systemd was using it with stream sockets and that wasn't
>>>>> supported by the kernel at the time,
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1224211, so systemd
>>>>> switched over to using SO_PEERSEC. Subsequently I did fix
>>>>> SCM_SECURITY to work with stream sockets via kernel commit
>>>>> 37a9a8df8ce9de6ea73349c9ac8bdf6ba4ec4f70 but SO_PEERSEC is still
>>>>> preferred. Looking around, I see that there is still one usage of
>>>>> SCM_SECURITY in systemd-journald but it doesn't seem to be required
>>>>> (if provided, journald will pass the label along but nothing seems to
>>>>> depend on it AFAICT). In any event, I don't believe this patch is
>>>>> needed to support stacking AppArmor.
>>>> Stephen is, as is so often the case, correct. AppArmor has a stub
>>>> socket_getpeersec_dgram() that gets removed in patch 23. If I remove
>>> right but as I said before this is coming, I have been playing with
>>> it and have code. So the series doesn't need it today but sooner than
>>> later it will be needed
>
> Is sooner like 5.10, or 5.15? It matters.
>
I can split SCM_SECURITY off from the rest of the unix mediation and
push it off for a while. So lets call it 5.15 or later.
>> I don't understand why. Is there a userspace component that relies on
>> SCM_SECURITY today for anything real (more than just blindly passing
>> it along and maybe writing to a log somewhere)? And this doesn't
>> provide support for a composite SCM_SECURITY or SCM_CONTEXT, so it
>> doesn't really solve the stacking problem for it anyway. What am I
>> missing? Why do you care about this patch?
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2020-09-09 18:38 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200826145247.10029-1-casey.ref@schaufler-ca.com>
2020-08-26 14:52 ` [PATCH v20 00/23] LSM: Module stacking for AppArmor Casey Schaufler
2020-08-26 14:52 ` [PATCH v20 01/23] LSM: Infrastructure management of the sock security Casey Schaufler
2020-08-26 14:52 ` [PATCH v20 02/23] LSM: Create and manage the lsmblob data structure Casey Schaufler
2020-09-04 21:50 ` Paul Moore
2020-08-26 14:52 ` [PATCH v20 03/23] LSM: Use lsmblob in security_audit_rule_match Casey Schaufler
2020-09-04 18:53 ` Paul Moore
2020-08-26 14:52 ` [PATCH v20 04/23] LSM: Use lsmblob in security_kernel_act_as Casey Schaufler
2020-09-04 19:46 ` Paul Moore
2020-08-26 14:52 ` [PATCH v20 05/23] net: Prepare UDS for security module stacking Casey Schaufler
2020-09-03 16:28 ` James Morris
2020-09-04 20:08 ` Paul Moore
2020-09-04 21:35 ` Casey Schaufler
2020-09-04 21:53 ` Paul Moore
2020-09-04 23:58 ` Casey Schaufler
2020-09-05 13:25 ` Paul Moore
2020-09-05 18:13 ` Casey Schaufler
2020-09-05 19:05 ` John Johansen
2020-09-08 1:28 ` Stephen Smalley
2020-09-08 13:35 ` Stephen Smalley
2020-09-08 23:37 ` Casey Schaufler
2020-09-09 0:21 ` John Johansen
2020-09-09 13:19 ` Stephen Smalley
2020-09-09 18:19 ` Casey Schaufler
2020-09-09 18:33 ` John Johansen [this message]
2020-09-09 18:47 ` John Johansen
2020-09-10 14:11 ` Paul Moore
2020-09-09 0:17 ` John Johansen
2020-08-26 14:52 ` [PATCH v20 06/23] LSM: Use lsmblob in security_secctx_to_secid Casey Schaufler
2020-09-04 21:29 ` Paul Moore
2020-08-26 14:52 ` [PATCH v20 07/23] LSM: Use lsmblob in security_secid_to_secctx Casey Schaufler
2020-09-04 21:59 ` Paul Moore
2020-08-26 14:52 ` [PATCH v20 08/23] LSM: Use lsmblob in security_ipc_getsecid Casey Schaufler
2020-09-05 13:12 ` Paul Moore
2020-08-26 14:52 ` [PATCH v20 09/23] LSM: Use lsmblob in security_task_getsecid Casey Schaufler
2020-09-05 13:18 ` Paul Moore
2020-08-26 14:52 ` [PATCH v20 10/23] LSM: Use lsmblob in security_inode_getsecid Casey Schaufler
2020-09-05 13:20 ` Paul Moore
2020-08-26 14:52 ` [PATCH v20 11/23] LSM: Use lsmblob in security_cred_getsecid Casey Schaufler
2020-08-26 14:52 ` [PATCH v20 12/23] IMA: Change internal interfaces to use lsmblobs Casey Schaufler
2020-09-06 2:28 ` Paul Moore
2020-08-26 14:52 ` [PATCH v20 13/23] LSM: Specify which LSM to display Casey Schaufler
2020-08-26 14:52 ` [PATCH v20 14/23] LSM: Ensure the correct LSM context releaser Casey Schaufler
2020-09-06 2:45 ` Paul Moore
2020-08-26 14:52 ` [PATCH v20 15/23] LSM: Use lsmcontext in security_secid_to_secctx Casey Schaufler
2020-08-26 14:52 ` [PATCH v20 16/23] LSM: Use lsmcontext in security_inode_getsecctx Casey Schaufler
2020-09-06 2:55 ` Paul Moore
2020-08-26 14:52 ` [PATCH v20 17/23] LSM: security_secid_to_secctx in netlink netfilter Casey Schaufler
2020-09-06 3:11 ` Paul Moore
2020-09-08 10:46 ` Pablo Neira Ayuso
2020-08-26 14:52 ` [PATCH v20 18/23] NET: Store LSM netlabel data in a lsmblob Casey Schaufler
2020-09-06 3:27 ` Paul Moore
2020-08-26 14:52 ` [PATCH v20 19/23] LSM: Verify LSM display sanity in binder Casey Schaufler
2020-09-06 3:30 ` Paul Moore
2020-08-26 14:52 ` [PATCH v20 20/23] Audit: Add new record for multiple process LSM attributes Casey Schaufler
2020-09-03 16:32 ` James Morris
2020-09-03 17:00 ` John Johansen
2020-09-03 21:49 ` Paul Moore
2020-09-06 16:32 ` Paul Moore
2020-08-26 14:52 ` [PATCH v20 21/23] Audit: Add a new record for multiple object " Casey Schaufler
2020-08-26 14:52 ` [PATCH v20 22/23] LSM: Add /proc attr entry for full LSM context Casey Schaufler
2020-08-26 18:02 ` Randy Dunlap
2020-08-26 14:52 ` [PATCH v20 23/23] AppArmor: Remove the exclusive flag Casey Schaufler
2020-08-26 15:27 ` [PATCH v20 00/23] LSM: Module stacking for AppArmor 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=c4c78d28-61f5-74fe-6a9f-3c41c178d556@canonical.com \
--to=john.johansen@canonical.com \
--cc=casey.schaufler@intel.com \
--cc=casey@schaufler-ca.com \
--cc=jmorris@namei.org \
--cc=linux-audit@redhat.com \
--cc=linux-security-module@vger.kernel.org \
--cc=sds@tycho.nsa.gov \
--cc=selinux@vger.kernel.org \
--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
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).