linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: John Johansen <john.johansen@canonical.com>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	Simon McVittie <smcv@collabora.com>
Cc: casey.schaufler@intel.com, jmorris@namei.org,
	linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
	keescook@chromium.org, penguin-kernel@i-love.sakura.ne.jp,
	paul@paul-moore.com, Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH v14 22/23] LSM: Add /proc attr entry for full LSM context
Date: Tue, 11 Feb 2020 10:35:38 -0800	[thread overview]
Message-ID: <397af078-a44b-6fcd-e125-8fdb0b441097@schaufler-ca.com> (raw)
In-Reply-To: <d3dfd552-cab1-f50e-f207-b6308d0d5990@canonical.com>

On 2/11/2020 9:58 AM, John Johansen wrote:
> On 2/11/20 7:59 AM, Stephen Smalley wrote:
>> On 2/10/20 2:00 PM, John Johansen wrote:
>>> On 2/10/20 10:32 AM, Casey Schaufler wrote:
>>>> Because attr/context (and later, SO_PEERCONTEXT) are new interfaces
>>>> there is no need to exactly duplicate what is in attr/current (later
>>>> SO_PEERSEC). I already plan to omit the "mode" component of the
>>>> AppArmor data in the AppArmor hook, as was discussed earlier. I would
>>>> prefer ASCII, but if AppArmor needs bytestrings, that's what we'll
>>>> have to do.
>>>>
>>>
>>> sadly, to not break userspace its a byte string because that is what the path based profile names are. AppArmor does support a more limited non path based profile name but I can't guarantee that is what userspace is using in policy.
>>
>> Ok, so /proc/pid/attr/context and SO_PEERCONTEXT have to be defined as returning bytestrings.
>>
>> So far we've talked about having AppArmor drop the trailing newline, be consistent with regard to whether the terminating NUL is included or excluded, and drop the mode field from what it returns for /proc/pid/attr/context and SO_PEERCONTEXT versus the current /proc/pid/attr/current and SO_PEERSEC.  Is that correct?
>>
>> How do we envision a liblsm processing the value returned from /proc/pid/attr/context or SO_PEEERCONTEXT?  

There hasn't been any serious thought put into liblsm. To date
there hasn't been an LSM level interface to worry about except
for /sys/kernel/security/lsm. My notions of what a liblsm ought
provide would seem archaic to most of the people here. I can make
proposals if there's a notion that liblsm makes sense.


>> It can certainly split it up per LSM.  But can it then take the apparmor portion of the context and pass that to existing libapparmor interfaces without breakage?  Or will the changes to the format described above create issues there?
>>
>>
> libapparmor can handle the changes. It does not require the mode string, currently anything unconfined does not include it, and we have already done experiments with dropping it in other cases. The trailing '\n' is handled conditionally so only if its there; this is well tested as the currently out of upstream af_unix socket mediation that is used by dbus does not include a trailing '\n' on the SO_PEERSEC.

So it doesn't seem that there would be significant difficulties
switching from "current" to "context". It won't be transparent,
but we're providing "display" to address that.



  reply	other threads:[~2020-02-11 18:35 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200124002306.3552-1-casey.ref@schaufler-ca.com>
2020-01-24  0:22 ` [PATCH v14 00/23] LSM: Module stacking for AppArmor Casey Schaufler
2020-01-24  0:22   ` [PATCH v14 01/23] LSM: Infrastructure management of the sock security Casey Schaufler
2020-01-24  0:22   ` [PATCH v14 02/23] LSM: Create and manage the lsmblob data structure Casey Schaufler
2020-01-24 14:21     ` Stephen Smalley
2020-01-24  0:22   ` [PATCH v14 03/23] LSM: Use lsmblob in security_audit_rule_match Casey Schaufler
2020-01-24  0:22   ` [PATCH v14 04/23] LSM: Use lsmblob in security_kernel_act_as Casey Schaufler
2020-01-24  0:22   ` [PATCH v14 05/23] net: Prepare UDS for security module stacking Casey Schaufler
2020-01-24  0:22   ` [PATCH v14 06/23] Use lsmblob in security_secctx_to_secid Casey Schaufler
2020-01-24 14:29     ` Stephen Smalley
2020-01-24  0:22   ` [PATCH v14 07/23] LSM: Use lsmblob in security_secid_to_secctx Casey Schaufler
2020-01-24  0:22   ` [PATCH v14 08/23] LSM: Use lsmblob in security_ipc_getsecid Casey Schaufler
2020-01-24  0:22   ` [PATCH v14 09/23] LSM: Use lsmblob in security_task_getsecid Casey Schaufler
2020-01-24  0:22   ` [PATCH v14 10/23] LSM: Use lsmblob in security_inode_getsecid Casey Schaufler
2020-01-24  0:22   ` [PATCH v14 11/23] LSM: Use lsmblob in security_cred_getsecid Casey Schaufler
2020-01-24  0:22   ` [PATCH v14 12/23] IMA: Change internal interfaces to use lsmblobs Casey Schaufler
2020-01-24  0:22   ` [PATCH v14 13/23] LSM: Specify which LSM to display Casey Schaufler
2020-01-24  0:22   ` [PATCH v14 14/23] LSM: Ensure the correct LSM context releaser Casey Schaufler
2020-01-24  0:22   ` [PATCH v14 15/23] LSM: Use lsmcontext in security_secid_to_secctx Casey Schaufler
2020-01-24  0:22   ` [PATCH v14 16/23] LSM: Use lsmcontext in security_inode_getsecctx Casey Schaufler
2020-01-24  0:23   ` [PATCH v14 17/23] LSM: security_secid_to_secctx in netlink netfilter Casey Schaufler
2020-01-24  0:23   ` [PATCH v14 18/23] NET: Store LSM netlabel data in a lsmblob Casey Schaufler
2020-01-24 14:36     ` Stephen Smalley
2020-01-24  0:23   ` [PATCH v14 19/23] LSM: Verify LSM display sanity in binder Casey Schaufler
2020-01-24  0:23   ` [PATCH v14 20/23] Audit: Add subj_LSM fields when necessary Casey Schaufler
2020-01-24  0:23   ` [PATCH v14 21/23] Audit: Include object data for all security modules Casey Schaufler
2020-01-24  0:23   ` [PATCH v14 22/23] LSM: Add /proc attr entry for full LSM context Casey Schaufler
2020-01-24 14:42     ` Stephen Smalley
2020-01-24 16:20       ` Stephen Smalley
2020-01-24 19:28         ` Casey Schaufler
2020-01-24 20:16           ` Stephen Smalley
2020-01-27 20:05             ` Simon McVittie
2020-02-03 20:54               ` John Johansen
2020-01-27 22:49             ` Casey Schaufler
2020-01-31 22:10             ` Casey Schaufler
2020-02-03 18:54               ` Stephen Smalley
2020-02-03 19:37                 ` Stephen Smalley
2020-02-03 21:39                   ` Casey Schaufler
2020-02-04 13:37                     ` Stephen Smalley
2020-02-04 17:14                       ` Casey Schaufler
2020-02-10 11:56                 ` Simon McVittie
2020-02-10 13:25                   ` Stephen Smalley
2020-02-10 14:55                     ` Stephen Smalley
2020-02-10 18:32                       ` Casey Schaufler
2020-02-10 19:00                         ` John Johansen
2020-02-11 15:59                           ` Stephen Smalley
2020-02-11 17:58                             ` John Johansen
2020-02-11 18:35                               ` Casey Schaufler [this message]
2020-02-11 19:11                                 ` John Johansen
2020-02-10 18:56                       ` John Johansen
2020-02-03 21:02             ` John Johansen
2020-02-03 21:43               ` Casey Schaufler
2020-02-03 22:49                 ` John Johansen
2020-02-03 20:59           ` John Johansen
2020-01-24  0:23   ` [PATCH v14 23/23] AppArmor: Remove the exclusive flag Casey Schaufler
2020-01-24 15:05   ` [PATCH v14 00/23] LSM: Module stacking for AppArmor Stephen Smalley
2020-01-24 21:04   ` Stephen Smalley
2020-01-24 21:49     ` Casey Schaufler
2020-01-27 16:14       ` Stephen Smalley
2020-01-27 16:56         ` KASAN slab-out-of-bounds in tun_chr_open/sock_init_data (Was: Re: [PATCH v14 00/23] LSM: Module stacking for AppArmor) Stephen Smalley
2020-01-27 17:34           ` Casey Schaufler
2020-01-27 17:16         ` [PATCH v14 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=397af078-a44b-6fcd-e125-8fdb0b441097@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=casey.schaufler@intel.com \
    --cc=jmorris@namei.org \
    --cc=john.johansen@canonical.com \
    --cc=keescook@chromium.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    --cc=smcv@collabora.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).