linux-kernel - Re: [PATCH] Add security hooks to binder and implement the hooks for SELinux.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20150123234559.GA11112@kroah.com>
Date:	Sat, 24 Jan 2015 07:45:59 +0800
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	Stephen Smalley <stephen.smalley@...il.com>,
	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>
Subject: Re: [PATCH] Add security hooks to binder and implement the hooks for
 SELinux.

On Fri, Jan 23, 2015 at 01:56:28PM -0800, Casey Schaufler wrote:
> 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.

If you know of some way to make a more "unified" system IPC policy, that
would be great to have, I don't know if anyone is even considering that
work, as it seems people are just more concerned about addressing the
more real issues of the different IPC methods these days.

Maybe it would be a good research project for someone to write a thesis
on?  :)

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/