Re: Fwd: [PATCH v4 15/23] LSM: Specify which LSM to display

From: Casey Schaufler <casey@schaufler-ca.com>
To: Stephen Smalley <stephen.smalley@gmail.com>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	"Schaufler, Casey" <casey.schaufler@intel.com>,
	James Morris <jmorris@namei.org>,
	LSM List <linux-security-module@vger.kernel.org>,
	selinux@vger.kernel.org, keescook@chromium.org,
	John Johansen <john.johansen@canonical.com>,
	penguin-kernel@i-love.sakura.ne.jp,
	Paul Moore <paul@paul-moore.com>
Subject: Re: Fwd: [PATCH v4 15/23] LSM: Specify which LSM to display
Date: Sat, 29 Jun 2019 12:45:03 -0700	[thread overview]
Message-ID: <fecdeb90-ccd5-9f23-525f-456ab325dd35@schaufler-ca.com> (raw)
In-Reply-To: <CAB9W1A29fCn=cH_Mx-g-P6M-5t+832ayhMmjy3PFZ-BOL3BuDQ@mail.gmail.com>

On 6/28/2019 6:01 PM, Stephen Smalley wrote:
> On Fri, Jun 28, 2019 at 12:15 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 6/28/2019 7:45 AM, Stephen Smalley wrote:
>>> On 6/26/19 3:22 PM, Casey Schaufler wrote:
>>>> Create a new entry "display" in /proc/.../attr for controlling
>>>> which LSM security information is displayed for a process.
>>>> The name of an active LSM that supplies hooks for human readable
>>>> data may be written to "display" to set the value. The name of
>>>> the LSM currently in use can be read from "display".
>>>> At this point there can only be one LSM capable of display
>>>> active.
>>> IIUC, presently, at the end of the entire series,
>>>
>>> 1) Any process can change its display attribute to any enabled security module, and no security module can veto that change.
>> That is correct. If a security module could hoard the display it
>> could prevent user space from functioning in a multiple module
>> environment.
>>
>>> 2) The display attribute is inherited across fork and exec, even execs that change credentials, and again no security module has control over the inheritance of this attribute.
>> Also correct. Scripts don't work otherwise.
> It's a security hole waiting to happen. Unprivileged caller sets its
> display value to Smack on a mostly SELinux system that happens to
> enable Smack too, then exec's a credential-changing SELinux-aware
> program that uses one of the libselinux APIs to set one of the
> /proc/self/attr attributes to a different SELinux context. Due to the
> change in display, the SELinux-aware program instead ends up setting
> one of the Smack attributes and therefore the desired SELinux context
> is never applied to the process or file or socket or whatever.

The credential-changing SELinux-aware program is getting
invoked by an unprivileged, Smack aware program? Would anyone
expect that to be a good idea? I'll admit it could happen,
but setting the Smack label of your SELinux-aware program
(which will need CAP_MAC_ADMIN, BTW) to "system_u:system_r:wheehee_t"
is unlikely to result in anything other than your SELinux-aware
program getting very frustrated. In the other direction, a
Smack-aware program that trys to set its SELinux context to "^"
is going to fail by SELinux policy. While I am willing to accept
that it is possible that there is a way to exploit this, it
would require convoluted SELinux and Smack policies. Anyone
who has reason to use a combination of Smack and SELinux on
a real system is already signing up for more configuration
headaches than I would wish on anyone.

I have strongly advocated addition of /proc/.../attr/
subdirectories for all LSMs, and that all user space migrate
to using them. /proc/.../attr/selinux/current would not be
affected by the display setting. We know, and have known for
years that so long as "current" is shared there will be this
sort of problem.

>
>>> 3) Setting the display attribute affects more than just the contexts read or written by the process itself:
>>> - Contexts reported in audit logs,
>>> - Contexts passed across binder (generated in sender context, delivered to receiver),
>>> - Contexts passed to NFS servers for new files,
>>> - Contexts returned by NFS servers for existing files,
>>> - Netlink-related contexts (?possibly generated in sender context rather than receiver context?),
>>> - This list may not be complete.
>> Any of which can be changed should a more rational behavior be proposed.
>> One possibility is to use lsm='value',lsm='value' encoding for internal
>> communications, but there's been considerable resistance to anything
>> like that.
> These are also security holes waiting to happen.  Processes can use it
> to hide their SELinux contexts from the audit logs, forge different
> SELinux contexts on binder IPC, forge file contexts to which they have
> no SELinux permissions on new files, ... All they need is stacking to
> be enabled and one other module that helpfully lets them set attribute
> values that look like SELinux contexts, and then they can set those
> and switch their display at the right time.

What would you propose as a more rational behavior?
Seriously, I could use some help here.

>>> 4) A security_secid_to_secctx() in one process' context (e.g. sender) or with one display value followed later by a security_secctx_to_secid() call in a different process' context (e.g. receiver) or with a different display value may ask a different security module to perform the reverse translation of the context than the forward translation.
>> Do you have an example of where this might happen?
>> Contexts are rarely used within the kernel. The usual
>> behavior is to generate them, send them out to user space,
>> and delete them. They get cached in some networking code,
>> but not in cases where more than one (existing) security
>> module will ever use them. Binder may be an exception, but
>> only SELinux (currently) supports binder.
> Haven't looked but I don't like the asymmetry of the interface.
> Doesn't matter that only SELinux supports binder if  you ever want any
> other security module other than SELinux enabled at the same time as
> SELinux.

Binder needs another look then.

>> Is that correct?  If so, it seems problematic.
>> Balancing backward compatibility with new behavior is hard!
>> What would you suggest for audit logs? Should we put all LSM
>> data in every record? Is NFS a concern for anyone not using
>> SELinux?
> Yes to all on audit if stacking is going to be real.  And yes, I think
> other security modules will care about NFS if they are serious.

I would love to get feedback from the audit maintainers about
how they would like the multiple LSM data formatted.

NFS is ... challenging. It was supposed to work with Smack
when it went in, but to the best of my understanding never
actually demonstrated.

>> There is no user space that uses display, and it's going
>> to take some time to work out all the kinks before we even
>> think about teaching systemd about it.
> That doesn't make it acceptable to introduce a mechanism that weakens
> security now.

Agreed in principle, not necessarily in detail.