New SELinux userspace release supporting extended ioctl permissions?

New SELinux userspace release supporting extended ioctl permissions?

[Paul Moore]

Now that Linux 4.3 has been released with the extended ioctl permissions, are 
we planning to make a new userspace release so that we can take advantage of 
this new functionality?  I believe all the necessary patches have been merged, 
no?

-- 
paul moore
security @ redhat

Re: New SELinux userspace release supporting extended ioctl permissions?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Fri, Nov 06, 2015 at 10:37:35AM -0500, Paul Moore wrote:
> Now that Linux 4.3 has been released with the extended ioctl permissions, are 
> we planning to make a new userspace release so that we can take advantage of 
> this new functionality?  I believe all the necessary patches have been merged, 
> no?
> 

Are you referring to anything in particular?

There is already some support: https://github.com/SELinuxProject/selinux/commit/ef93dfe0393c4a60483c3f7729dd98a2f886606a

Applying ioctl whitelisting on GNU/Linux systems looks to me pretty hard
to do though. Many drivers, and their ioctls to support.

I also had a hard time determining what is what. This tool[1] helped a
little but it is still very hard to add support for the appropriate
ioctls to the appropriate interfaces.

- From a policy perspective I am just going to wait it out for now, see where
androids' sepolicy goes with this. I think they have the benefit of
limited hardware to support.

[1] https://bitbucket.org/billcroberts/fixup/src/0e49a67015a98f856199e41d1681117b4ae179b5/ioctl.c?at=master

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWPNS3AAoJENAR6kfG5xmcp+4MAJX3wIdQElrLifArveurVbOD
WVzcdFPtPVw9AL3SBM8A8Crjkc463STcwlv8S+lGpQWo3fpes60uIYK/+0sxN1r7
BFFYdisf+WtRQvC070kCBB+bmNejs8zX6Tz4XoV1yXG5EpuoPecn4EPT7vylg8Gm
+3s0gkqrOeTDZ+MW+HfKOZgxNHASvHDSwnCt+U9f9a2TINx1ceoN/r5vGLCB0dvQ
EXBtPjHSKFGAPGLF7xqq397OdofHxMBEfZbogsxyPXAJeF9/CuAIhKHQOcSA3waV
k5cAF7snEcYD9NpU965An+a1TcjAotxwYSj1SoTeJns6ZxQmZHfI1STKMaJBQpAv
GGJD7aNxBwzYYiUt4v9SIGVq+B0hrJpa/vm+rGNyc/f6ra3LZdRz9BpM9rwFV0eS
Qv2uYrkkcB3XC7t4gfYtmaa0ERRolsMfwDufAwhXFWrmgLktGB1RKWbwEc/TytKp
C6NmP3VunZzA0RwbQIMccuWQSKj+DxCtVmQQ7GYX+w==
=PTyE
-----END PGP SIGNATURE-----

Re: New SELinux userspace release supporting extended ioctl permissions?

[Joshua Brindle]

Dominick Grift wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On Fri, Nov 06, 2015 at 10:37:35AM -0500, Paul Moore wrote:
>> Now that Linux 4.3 has been released with the extended ioctl permissions, are
>> we planning to make a new userspace release so that we can take advantage of
>> this new functionality?  I believe all the necessary patches have been merged,
>> no?
>>
>
> Are you referring to anything in particular?
>
> There is already some support: https://github.com/SELinuxProject/selinux/commit/ef93dfe0393c4a60483c3f7729dd98a2f886606a
>

I think he means actually making a release, though I don't know of any 
distribution that only uses releases other than Gentoo (if that is still 
true...)

> Applying ioctl whitelisting on GNU/Linux systems looks to me pretty hard
> to do though. Many drivers, and their ioctls to support.
>
> I also had a hard time determining what is what. This tool[1] helped a
> little but it is still very hard to add support for the appropriate
> ioctls to the appropriate interfaces.
>
> - From a policy perspective I am just going to wait it out for now, see where
> androids' sepolicy goes with this. I think they have the benefit of
> limited hardware to support.
>
> [1] https://bitbucket.org/billcroberts/fixup/src/0e49a67015a98f856199e41d1681117b4ae179b5/ioctl.c?at=master
>
> - --
> 02DFF788
> 4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
> https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
> Dominick Grift
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQGcBAEBCgAGBQJWPNS3AAoJENAR6kfG5xmcp+4MAJX3wIdQElrLifArveurVbOD
> WVzcdFPtPVw9AL3SBM8A8Crjkc463STcwlv8S+lGpQWo3fpes60uIYK/+0sxN1r7
> BFFYdisf+WtRQvC070kCBB+bmNejs8zX6Tz4XoV1yXG5EpuoPecn4EPT7vylg8Gm
> +3s0gkqrOeTDZ+MW+HfKOZgxNHASvHDSwnCt+U9f9a2TINx1ceoN/r5vGLCB0dvQ
> EXBtPjHSKFGAPGLF7xqq397OdofHxMBEfZbogsxyPXAJeF9/CuAIhKHQOcSA3waV
> k5cAF7snEcYD9NpU965An+a1TcjAotxwYSj1SoTeJns6ZxQmZHfI1STKMaJBQpAv
> GGJD7aNxBwzYYiUt4v9SIGVq+B0hrJpa/vm+rGNyc/f6ra3LZdRz9BpM9rwFV0eS
> Qv2uYrkkcB3XC7t4gfYtmaa0ERRolsMfwDufAwhXFWrmgLktGB1RKWbwEc/TytKp
> C6NmP3VunZzA0RwbQIMccuWQSKj+DxCtVmQQ7GYX+w==
> =PTyE
> -----END PGP SIGNATURE-----
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

RE: New SELinux userspace release supporting extended ioctl permissions?

[Roberts, William C]

> -----Original Message-----
> From: Selinux [mailto:selinux-bounces@tycho.nsa.gov] On Behalf Of Joshua
> Brindle
> Sent: Friday, November 6, 2015 8:32 AM
> To: Paul Moore <pmoore@redhat.com>; selinux@tycho.nsa.gov
> Subject: Re: New SELinux userspace release supporting extended ioctl
> permissions?
> 
> Dominick Grift wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > On Fri, Nov 06, 2015 at 10:37:35AM -0500, Paul Moore wrote:
> >> Now that Linux 4.3 has been released with the extended ioctl
> >> permissions, are we planning to make a new userspace release so that
> >> we can take advantage of this new functionality?  I believe all the
> >> necessary patches have been merged, no?
> >>
> >
> > Are you referring to anything in particular?
> >
> > There is already some support:
> > https://github.com/SELinuxProject/selinux/commit/ef93dfe0393c4a60483c3
> > f7729dd98a2f886606a
> >
> 
> I think he means actually making a release, though I don't know of any
> distribution that only uses releases other than Gentoo (if that is still
> true...)
> 
> > Applying ioctl whitelisting on GNU/Linux systems looks to me pretty
> > hard to do though. Many drivers, and their ioctls to support.
> >
> > I also had a hard time determining what is what. This tool[1] helped a
> > little but it is still very hard to add support for the appropriate
> > ioctls to the appropriate interfaces.
> >
> > - From a policy perspective I am just going to wait it out for now,
> > see where androids' sepolicy goes with this. I think they have the
> > benefit of limited hardware to support.

I plan on eventually adding support for domains of interest within Intel's OEM policy.
For the first crack I'd like to get anything with graphics related support under /dev sorted
out and then go from there. However, it's a large undertaking.

> >
> > [1]
> > https://bitbucket.org/billcroberts/fixup/src/0e49a67015a98f856199e41d1
> > 681117b4ae179b5/ioctl.c?at=master
> >
> > - --
> > 02DFF788
> > 4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
> > Dominick Grift
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2
> >
> >
> iQGcBAEBCgAGBQJWPNS3AAoJENAR6kfG5xmcp+4MAJX3wIdQElrLifArveurVbOD
> > WVzcdFPtPVw9AL3SBM8A8Crjkc463STcwlv8S+lGpQWo3fpes60uIYK/+0sxN1r7
> > BFFYdisf+WtRQvC070kCBB+bmNejs8zX6Tz4XoV1yXG5EpuoPecn4EPT7vylg8Gm
> >
> +3s0gkqrOeTDZ+MW+HfKOZgxNHASvHDSwnCt+U9f9a2TINx1ceoN/r5vGLCB0dv
> Q
> >
> EXBtPjHSKFGAPGLF7xqq397OdofHxMBEfZbogsxyPXAJeF9/CuAIhKHQOcSA3waV
> > k5cAF7snEcYD9NpU965An+a1TcjAotxwYSj1SoTeJns6ZxQmZHfI1STKMaJBQpAv
> > GGJD7aNxBwzYYiUt4v9SIGVq+B0hrJpa/vm+rGNyc/f6ra3LZdRz9BpM9rwFV0eS
> >
> Qv2uYrkkcB3XC7t4gfYtmaa0ERRolsMfwDufAwhXFWrmgLktGB1RKWbwEc/TytKp
> > C6NmP3VunZzA0RwbQIMccuWQSKj+DxCtVmQQ7GYX+w==
> > =PTyE
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > Selinux mailing list
> > Selinux@tycho.nsa.gov
> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

Re: New SELinux userspace release supporting extended ioctl permissions?

[Paul Moore]

On Friday, November 06, 2015 11:32:13 AM Joshua Brindle wrote:
> Dominick Grift wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> > 
> > On Fri, Nov 06, 2015 at 10:37:35AM -0500, Paul Moore wrote:
> >> Now that Linux 4.3 has been released with the extended ioctl permissions,
> >> are we planning to make a new userspace release so that we can take
> >> advantage of this new functionality?  I believe all the necessary
> >> patches have been merged, no?
> > 
> > Are you referring to anything in particular?
> > 
> > There is already some support:
> > https://github.com/SELinuxProject/selinux/commit/ef93dfe0393c4a60483c3f77
> > 29dd98a2f886606a
>
> I think he means actually making a release...

Yes, exactly.  I'm old fashioned that way.

-- 
paul moore
security @ redhat

Re: New SELinux userspace release supporting extended ioctl permissions?

[Jeffrey Vander Stoep]

> Applying ioctl whitelisting on GNU/Linux systems looks to me pretty hard
> to do though. Many drivers, and their ioctls to support.

Agreed.

On Android we use ioctl whitelisting only in a targeted manner. I
think the same approach could (should) be applied to GNU/Linux.

The example that went out in the M release focused on restricting the
leakage of privacy sensitive information from socket ioctls. Apps are
blocked from using socket ioctls to access the wifi MAC address, wifi
SSID and layer 2 encryption protocol. I could see a similar policy
applied to the GNU/Linux browser. Ioctl policies on GPU access also
seem practical albeit device specific.

Constructing a comprehensive list of ioctls and the
source/target/class sets that require access does not strike me as
practical. In many cases these ioctls are already properly restricted
via the ioctl permission.

Re: New SELinux userspace release supporting extended ioctl permissions?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Fri, Nov 06, 2015 at 09:51:08AM -0800, Jeffrey Vander Stoep wrote:
> > Applying ioctl whitelisting on GNU/Linux systems looks to me pretty hard
> > to do though. Many drivers, and their ioctls to support.
> 
> Agreed.
> 
> On Android we use ioctl whitelisting only in a targeted manner. I
> think the same approach could (should) be applied to GNU/Linux.
> 
> The example that went out in the M release focused on restricting the
> leakage of privacy sensitive information from socket ioctls. Apps are
> blocked from using socket ioctls to access the wifi MAC address, wifi
> SSID and layer 2 encryption protocol. I could see a similar policy
> applied to the GNU/Linux browser. Ioctl policies on GPU access also
> seem practical albeit device specific.

Thanks. that prompted me to see what happened to the seandroid
repository on bitbucket because it has been stale for a while now.

found
https://android.googlesource.com/platform/external/sepolicy/+/master/ioctl_macros

That should be easy to implement on GNU/Linux indeed. Will try that soon

> 
> Constructing a comprehensive list of ioctls and the
> source/target/class sets that require access does not strike me as
> practical. In many cases these ioctls are already properly restricted
> via the ioctl permission.
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWPO0yAAoJENAR6kfG5xmcmoEL/0ldXc6lSpW/ztGGDPmgEZkc
MqUi5l8bze1oyPiFVYlcXNe7ht9wHc8B6kZXH6k0XHOCpXO7hHO0PGp1hlb2JkHI
qdEGGjPEPob0N7meDA8MV9WRXO2eTkBhJ0CU8mEtx9FjGplDqvWKpDi28SG+9h3S
1WhEKbsSoqJ8jcd//X9IxVcFsQHLmu+HfNxyGYI33VdBxyqJWrVEq2OYyXdOYmM5
MjCHb/oDLuzKhuKrejCl+ecHcAA6iCf2PYfS6PQAbfi7Fooa9r3gocrVmMzvjXR8
TfNJeIceK+PclF7830ByPeInJ0FE1DxrZGGKMAnbYLAT4tFl5E9BzKEADJicLEqH
2pRxAsYf1qMs5Zfxul/LQWhu3E9HBRRpnijVCmcnJ5PjCPVWUd5olcS2rKMtkBsf
OC16SQO1Zsgv//xzumvGGTeyJEVR94Uoukh5uQnCjdJz9UZApIW/0wm/sbgnAEqz
tclJiiE1oZqT1khg8uhRh/AAl91nptYqCmlYBplp0w==
=+KkK
-----END PGP SIGNATURE-----

Re: New SELinux userspace release supporting extended ioctl permissions?

[Jeffrey Vander Stoep]

> Thanks. that prompted me to see what happened to the seandroid
> repository on bitbucket because it has been stale for a while now.
>
> found
> https://android.googlesource.com/platform/external/sepolicy/+/master/ioctl_macros
>
> That should be easy to implement on GNU/Linux indeed. Will try that soon

It's currently more of a blacklist - just disallow a few operations.
It would be nice to whittle it down to an actual whitelist.

RE: New SELinux userspace release supporting extended ioctl permissions?

[Roberts, William C]

> -----Original Message-----
> From: Selinux [mailto:selinux-bounces@tycho.nsa.gov] On Behalf Of Jeffrey
> Vander Stoep
> Sent: Friday, November 6, 2015 9:51 AM
> To: Paul Moore <pmoore@redhat.com>; SELinux <selinux@tycho.nsa.gov>
> Subject: Re: New SELinux userspace release supporting extended ioctl
> permissions?
> 
> > Applying ioctl whitelisting on GNU/Linux systems looks to me pretty
> > hard to do though. Many drivers, and their ioctls to support.
> 
> Agreed.
> 
> On Android we use ioctl whitelisting only in a targeted manner. I think the same
> approach could (should) be applied to GNU/Linux.
> 
> The example that went out in the M release focused on restricting the leakage of
> privacy sensitive information from socket ioctls. Apps are blocked from using
> socket ioctls to access the wifi MAC address, wifi SSID and layer 2 encryption
> protocol. I could see a similar policy applied to the GNU/Linux browser. Ioctl
> policies on GPU access also seem practical albeit device specific.
> 
> Constructing a comprehensive list of ioctls and the source/target/class sets that
> require access does not strike me as practical. In many cases these ioctls are
> already properly restricted via the ioctl permission.

I think a good example of what could be targeted are perhaps video devices implementing
The Video 4 Linux and V4L2 api's. Since those ioctl's are well documented, hopefully things
adhere to them. However, based on my experience, there is the standard and then what
people do, and they are not one in the same.


> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.