Date:	Fri, 23 Jan 2015 13:56:28 -0800
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Greg KH <gregkh@...uxfoundation.org>,
	Stephen Smalley <stephen.smalley@...il.com>
CC:	Stephen Smalley <sds@...ho.nsa.gov>,
	Linux Kernel <linux-kernel@...r.kernel.org>, arve@...roid.com,
	Nick Kralevich <nnk@...gle.com>,
	Paul Moore <paul@...l-moore.com>,
	selinux <selinux@...ho.nsa.gov>,
	linux-security-module@...r.kernel.org,
	James Morris <jmorris@...ei.org>,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH] Add security hooks to binder and implement the hooks
 for SELinux.

On 1/22/2015 6:30 PM, Greg KH wrote:
> On Thu, Jan 22, 2015 at 01:47:29PM -0500, Stephen Smalley wrote:
>> On Thu, Jan 22, 2015 at 1:09 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
>>> On 1/22/2015 12:51 AM, Greg KH wrote:
>>>> On Wed, Jan 21, 2015 at 10:54:10AM -0500, Stephen Smalley wrote:
>>>>> Add security hooks to the binder and implement the hooks for SELinux.
>>>>> The security hooks enable security modules such as SELinux to implement
>>>>> controls over binder IPC.  The security hooks include support for
>>>>> controlling what process can become the binder context manager
>>>>> (binder_set_context_mgr), controlling the ability of a process
>>>>> to invoke a binder transaction/IPC to another process (binder_transaction),
>>>>> controlling the ability of a process to transfer a binder reference to
>>>>> another process (binder_transfer_binder), and controlling the ability
>>>>> of a process to transfer an open file to another process (binder_transfer_file).
>>>>>
>>>>> These hooks have been included in the Android kernel trees since Android 4.3.
>>>> Very interesting, I missed the fact that these were added in that tree,
>>>> thanks for digging it out and submitting it.
>>>>
>>>> I'd like some acks from some Android developers before I take these.
>>>> Or, if it's easier for them to go through the security tree, that's fine
>>>> with me as well.
>>> My only concern is that we're about to see a set of hooks proposed
>>> for kdbus as well, and it would be a shame if we had two sets of hooks
>>> that do roughly the same thing (ok, *very roughly*) introduced back to back.
>> Not sure how much commonality there truly is among them (based on the
>> last set of proposed kdbus lsm hooks that I saw, admittedly a while
>> ago) and modules may want to distinguish between the two
>> forms of IPC regardless.  The binder hooks have been in place in the
>> Android kernel trees for quite some time, so this patch is just making
>> the mainline binder driver consistent with what is already in Android.
>> If it turns out that there is significant duplication when the kdbus
>> lsm hooks land, I'd be happy to help coalesce them.
> Yeah, I would wait and see what happens with how the kdbus hooks look
> before worrying about this all that much.  As people are using the
> binder hooks today, and binder is in the kernel tree, but kdbus isn't,
> let's not worry about kdbus until that is merged.

That seems like a sane plan to me in light of the situation. I am somewhat
concerned about the growth in special case security behavior. The tun hooks,
now the binder hooks and later the kdbus hooks. It looks like we're going
in the direction of special policies for each kind of communication rather
than a system IPC policy. On the other hand, that appears to be the trend in
system security overall, so even I can see that it may be prudent.


>
> thanks,
>
> greg k-h
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists