IronPort-PHdr: =?us-ascii?q?9a23=3AlpwAGRcIKOl2mdPJYYYbfCyalGMj4u6mDksu8pMi?=
 =?us-ascii?q?zoh2WeGdxc24YBaN2/xhgRfzUJnB7Loc0qyN4v+mBzVLvMzJmUtBWaQEbwUCh8?=
 =?us-ascii?q?QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYdFRrlKAV6?=
 =?us-ascii?q?OPn+FJLMgMSrzeCy/IDYbxlViDanb75/KBe7oR/Qu8ULjodvKrg9wQbVr3VVfO?=
 =?us-ascii?q?hb2XlmLk+JkRbm4cew8p9j8yBOtP8k6sVNT6b0cbkmQLJBFDgpPHw768PttRnY?=
 =?us-ascii?q?UAuA/WAcXXkMkhpJGAfK8hf3VYrsvyTgt+p93C6aPdDqTb0xRD+v4btnRAPuhS?=
 =?us-ascii?q?waLDMy7n3ZhdJsg6JauBKhpgJww4jIYIGOKfFyerrRcc4GSWZdW8pcUSJOApm4?=
 =?us-ascii?q?b4ASEeQPO+hWpJT5q1cXsxeyGQygCeXywTFKm3D2x7U33ec8Hw/GwgIuEdABsH?=
 =?us-ascii?q?rTrNrpM6kdXu+7wbLUzTjAdf5axS3w5JTKfx0nvPqCXahwcc3UyUQ3Cg3Fkkuf?=
 =?us-ascii?q?qZTlPzyL0OQGrnWV7+96WuKrj24otQFwqSWoy8c3l4bJnZkYykzE9CplwIY1Is?=
 =?us-ascii?q?e0SEhgYdG+CpdQuCaaN5VvT84kXmpmuz46x6UbtZO0cyUG0pQqywPFZ/CZfIWE?=
 =?us-ascii?q?/AjvWPuXLDxlnnxqYqi/iAy38UW4z+38UdS730hSoypel9nMqmgN1xvO6sibUv?=
 =?us-ascii?q?d9/lmu2TKI1w3L9uFLO1o0lavGK5462LIwipoSvljDHi/xgkn2irOZdl449eSy?=
 =?us-ascii?q?7uTnY7HmqoedN49ylA7+LrwjltGwDOk3KAQDX3WX9f6i2LDs40H1WqhGguUzkq?=
 =?us-ascii?q?bDsZDaIcobprS+Aw9Qyosj8AuwDyy93dQEnXgIMFJFeBWdg4jvIFHBOur0Dfi4?=
 =?us-ascii?q?g1SyiDtr3ezJPqX9ApXRKXjOiK3hfbFm5EJGyAo808pf54hVCrEHL/L+QUvxtN?=
 =?us-ascii?q?3eDhAjKQy0xPzrCNJn1oMRQWiPGLOWMLvOsV+U4eIiO/KMa5UJuDb8MPgl5+Ti?=
 =?us-ascii?q?jWcjll8BY6ap2YAaaHS5HvRgOUqZe33sjs0GEWcQsQo0VPbqh0GaUT5Pe3ayWL?=
 =?us-ascii?q?ox5jU6CIKgEIfCSZmhgL+f0yehGJ1ZeGRGB0uSEXfnaYqEQe0AaCGMLc97lDwL?=
 =?us-ascii?q?S7yhR5Um1RG0uw/w06BnIfbM+i0EqZLj08B45+vVlREx7jF0AMOd02aCT2FwgG?=
 =?us-ascii?q?wEXSM53Kd6oUZl0FeMzbB4g+BEFdxU//5JURk1NYTaz+NkD9D+Qx7BccmTR1aj?=
 =?us-ascii?q?WdipGzcxQc8rw98JYkZyBs+ugQzE3yqvG7UVjaCEBIQo8qLA2Hj8P8R9xGjI1K?=
 =?us-ascii?q?kvkVkrWcRPNWqhhq5w8wjcGZTFnFmel6avba4cxjLC9H+fzWqSu0FVSBZwXr/Y?=
 =?us-ascii?q?XXAbfUbWtc725l7GT7O3DLQnNQxBydScJadQdtLpilBGTu/5ONvCe2Kxh3uwBR?=
 =?us-ascii?q?GQy7OOa4rqe2Md0D/GCEgYjgAT+WqGNAklCyelomLeCiZhFUjoY0/29ul+sny7?=
 =?us-ascii?q?HQcIyFSoaE1nn4Gp5xoJl7TISfQT2PQfpDoltydcGFe71sjRTd2aqFwlNJ1VfN?=
 =?us-ascii?q?d1xVBAz2+R4xR0I5iIN6l/ghsbdANtsgXl0BAhWatals1/l28n1Ap/L+qj1VpF?=
 =?us-ascii?q?cz6JlcTrNqb/Nnj5/BfpbbXfnF7ZzoDFqe809P0kpgC770mSHU04/iAiioMN3g?=
 =?us-ascii?q?=3D=3D?=
Message-ID: <1496839230.15470.1.camel@tycho.nsa.gov>
Subject: Re: "selinux: support distinctions among all network address
 families" causing existing bluetooth sepolicies to not work properly with
 Android?
From: Stephen Smalley <sds@tycho.nsa.gov>
To: John Stultz <john.stultz@linaro.org>, Paul Moore <paul@paul-moore.com>
Cc: Jeffrey Vander Stoep <jeffv@google.com>,
        Android Kernel Team <kernel-team@android.com>,
        Nick Kralevich <nnk@google.com>, lkml <linux-kernel@vger.kernel.org>,
        Satish Patel <satish.patel@linaro.org>,
        Rob Herring <rob.herring@linaro.org>
Date: Wed, 07 Jun 2017 08:40:30 -0400
In-Reply-To: <CALAqxLVyVoiusPdHYceubWnnw+DTzU55MMdtHxhA=2w4FqxC_A@mail.gmail.com>
References: <CALAqxLVyVoiusPdHYceubWnnw+DTzU55MMdtHxhA=2w4FqxC_A@mail.gmail.com>
Organization: National Security Agency
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2615
Lines: 55

On Tue, 2017-06-06 at 17:45 -0700, John Stultz wrote:
> Hey folks,
> 
> Recently I was working to validate/enable a new bluetooth HAL on
> HiKey
> with Android, and after getting it working properly with a 4.9 based
> kernel, I found that I was seeing failures trying to run with an
> upstream (4.12-rc3 based) kernel.
> 
> It seemed a call to:
>    socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI);
> 
> was suddenly failing, and running "setenforce 0" would allow it to
> continue properly.
> 
> I chased the issue down to  da69a5306ab9 ("selinux: support
> distinctions among all network address families"). And work around it
> with the following (whitespace corrupted, sorry) hack:
> 
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index e67a526..42dfd0f 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1379,8 +1379,8 @@ static inline u16
> socket_type_to_security_class(int family, int type, int protoc
>                         return SECCLASS_CAN_SOCKET;
>                 case PF_TIPC:
>                         return SECCLASS_TIPC_SOCKET;
> -               case PF_BLUETOOTH:
> -                       return SECCLASS_BLUETOOTH_SOCKET;
> +//             case PF_BLUETOOTH:
> +//                     return SECCLASS_BLUETOOTH_SOCKET;
>                 case PF_IUCV:
>                         return SECCLASS_IUCV_SOCKET;
>                 case PF_RXRPC:
> 
> Obviously this isn't ideal. The commit message claims that " Backward
> compatibility is provided by only enabling the finer-grained socket
> classes if a new policy capability is set in the policy; older
> policies will behave as before."
> 
> Which makes it seem like the older sepolicy should be fine with newer
> kernels, but this doesn't seem to be the case here? Am I missing
> something? Is Android doing something odd with their POLICYDB that is
> causing the kernel to think the sepolicy is newer?

The code above is only enabled if the policy enables the
extended_socket_class policy capability.  I added that to AOSP policy
in 431bdd9f2f344ecde4cd3fe0109bd70eab0a394c.  The correct fix is not to
change the kernel but rather to add allow rules to policy for the
finer-grained socket classes.  Your dmesg or logcat output will show
you the denials, and audit2allow can help with an initial cut at rules,
although you should refine them to use the macros and, where
appropriate, attributes.