From: Casey Schaufler <casey@schaufler-ca.com>
To: Stephen Smalley <sds@tycho.nsa.gov>,
casey.schaufler@intel.com, jmorris@namei.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org
Cc: keescook@chromium.org, john.johansen@canonical.com,
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, 4 Feb 2020 09:14:45 -0800 [thread overview]
Message-ID: <913132fa-7318-bc6b-1ebb-5463291dd916@schaufler-ca.com> (raw)
In-Reply-To: <9a07bf65-c0a8-6295-a3a5-ac1817385891@tycho.nsa.gov>
On 2/4/2020 5:37 AM, Stephen Smalley wrote:
> On 2/3/20 4:39 PM, Casey Schaufler wrote:
>> On 2/3/2020 11:37 AM, Stephen Smalley wrote:
>>> BTW, I think the above guarantees with the exception of no trailing whitespace and whether the NUL byte is included or excluded from length are in reality also required for "current" (and SO_PEERSEC) or existing userspace will break.
>>
>> The behavior of interfaces (e.g. "current", "exec") that are module defined
>> is only of concern with respect to to "display" behavior. If a security module
>> wants to provide a variable size binary blob in "current" I would object on
>> principle, but policy as I understand it has long been that if the authors want
>> to do that, it's their call.
>
> Doing so would break existing userspace (not just LSM-specific userspace), so I think it would be a deal breaker even for new security modules to move away from those guarantees for "current" at least. procps-ng (and I think procps before it) directly reads /proc/pid/attr/current and truncates at the first unprintable character.
An user-space that makes invalid assumptions about an interface
can't implicitly define the behavior of that interface. You can't
declare that "current" is defined to be a string just because a
developer looked at how one security module uses it and coded the
application accordingly. You can't declare that "current" will
always be a SELinux context. That horse left the barn in 2007,
and there are still people writing code assuming that is what
they're getting.
If the sub-system maintainer, James Morris, is willing to state that
"current" must have a particular format that would be different.
> systemd's sd-bus reads /proc/pid/attr/current directly and treats \n, \r, or \0 byte as terminators and truncated on first occurrence. A variety of userspace code uses the value obtained from /proc/pid/attr/current and/or SO_PEERSEC as something that it can pass to printf-like functions using a %s specifier for inclusion in logs and audit messages.
Yup. And so far no security module has been foolish enough to export
a binary blob in a /proc/.../attr interface. That doesn't mean that
the interface is defined as a string. It's certainly the convention,
but nowhere is it documented as a requirement.
That's why I'm putting in the effort to define the format for "context"
and SO_PEERCONTEXT. Interfaces at the LSM level need to be defined so as
to allow the underlying security modules to provide the information they
want in a way that is unambiguous and application non-hostile. The help
I've gotten from you and the rest of the reviewers over the life of this
effort has been extremely helpful, if not always easy to swallow.
>
>> The "context" has a defined format, and it would
>> be up to the authors to come up with a printable ASCII representation of the
>> binary blob. If they care. They're not required to provide a "context".
>
>
next prev parent reply other threads:[~2020-02-04 17:14 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 [this message]
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
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=913132fa-7318-bc6b-1ebb-5463291dd916@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 \
/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).