On 2/6/19 12:44 PM, Casey Schaufler wrote:

On 2/6/2019 9:06 AM, Stephen Smalley wrote:

quoted

On 2/6/19 11:30 AM, Casey Schaufler wrote:

quoted

On 2/5/2019 5:11 PM, James Morris wrote:

quoted

On Tue, 5 Feb 2019, Paul Moore wrote:

quoted

I believe that will always be a problem, no matter what we do.  The
point I was trying to make was that everyone, especially the
maintainers, need to watch for this when patches are posted and make
sure the patch author posts to the LSM list in addition to any of the
relevant LSM specific lists.

Right, and there is no way a new LSM hook should ever be added to the
kernel without review and ack/signoffs from folks on the LSM list
(especially those who are maintainers of in-tree LSMs).

Casey, do you have any examples of this happening?

overlayfs (according to my records - which may be flawed)
is a prime example. Inifiniband hooks were reviewed/acked
for SELinux, but there was never an attempt made to work
with other security module maintainers. Yes, they were posted
to LSM, but under the title "SELinux support for Infiniband".

overlayfs hooks were also posted to and discussed on lsm list, including comments from you.  Admittedly the cover patch said Overlayfs SELinux Support but the individual patches for the hooks were "security, overlayfs: provide copy up security hook for unioned files" and "security,overlayfs: Provide security hook for copy up of xattrs for overlay file".

OK, apologies all around. My records are still better
than my memory, but neither is perfect.

quoted

In either case, did you request a change that was ignored?

Smack support was definitely not included. I started
getting complaints almost immediately when overlayfs
hit upstream.

You can't expect the developer to supply a Smack implementation of the 
hook if they aren't using Smack themselves.

On the other hand, absence of a hook implementation shouldn't break 
existing users.  So if that was the case, then there was a bug in the 
hook's fallback behavior.