* ioctl help
@ 2017-05-24 12:08 Dominick Grift
2017-05-24 20:11 ` Stephen Smalley
0 siblings, 1 reply; 6+ messages in thread
From: Dominick Grift @ 2017-05-24 12:08 UTC (permalink / raw)
To: selinux
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
I was looking again at ioctl whitelisting, and excuse me if I overlooked some documentation, but I am having a hard time implementing this.
what I did was I just wanted to basically test blacklisting a single ioctl (no particular one)
So i looked into androids sepolicy and just picked a semi-random ioctl from their "https://android.googlesource.com/platform/system/sepolicy/+/master/public/ioctl_defines"
for example: PHONE_CAPABILITIES_CHECK 0x40087182
However the xpermissions statement only allows 0x0000 to 0xFFFF when i tried: (xpermission alg_socket_ioctl (ioctl alg_socket (not (0x40087182))))
My question is how do i convert these to something i can use with the xpermission statement in CIL, and why can seandroid sepolicy get away with using 0x12345678 where i have to use 0x1234? I could not find any scripts that converts these in the android tree.
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ioctl help
2017-05-24 12:08 ioctl help Dominick Grift
@ 2017-05-24 20:11 ` Stephen Smalley
2017-05-25 5:49 ` Dominick Grift
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Smalley @ 2017-05-24 20:11 UTC (permalink / raw)
To: Dominick Grift, selinux
On Wed, 2017-05-24 at 14:08 +0200, Dominick Grift wrote:
> I was looking again at ioctl whitelisting, and excuse me if I
> overlooked some documentation, but I am having a hard time
> implementing this.
> what I did was I just wanted to basically test blacklisting a single
> ioctl (no particular one)
>
> So i looked into androids sepolicy and just picked a semi-random
> ioctl from their "https://android.googlesource.com/platform/system/se
> policy/+/master/public/ioctl_defines"
>
> for example: PHONE_CAPABILITIES_CHECK 0x40087182
>
> However the xpermissions statement only allows 0x0000 to 0xFFFF when
> i tried: (xpermission alg_socket_ioctl (ioctl alg_socket (not
> (0x40087182))))
>
> My question is how do i convert these to something i can use with the
> xpermission statement in CIL, and why can seandroid sepolicy get away
> with using 0x12345678 where i have to use 0x1234? I could not find
> any scripts that converts these in the android tree.
FWIW, I added a simple test of ioctl whitelisting to the selinux-
testsuite, although that was done in source policy and depends on the
binary module format support for xperms.
With regard to your question though, only the low 16 bits of the ioctl
value (the type/driver and number/function fields) are actually used;
the upper 16 bits encode the direction (read/write) and size of any
argument to the ioctl and are therefore not relevant for whitelisting.
So you can just use 0x7182. checkpolicy just ignores the upper bits,
which I guess is convenient so that they can use ioctl macro lists
generated from kernel header definitions, and Android builds by using
checkpolicy -C to convert policy.conf to CIL.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ioctl help
2017-05-24 20:11 ` Stephen Smalley
@ 2017-05-25 5:49 ` Dominick Grift
2017-05-25 9:19 ` Dominick Grift
0 siblings, 1 reply; 6+ messages in thread
From: Dominick Grift @ 2017-05-25 5:49 UTC (permalink / raw)
To: selinux
[-- Attachment #1: Type: text/plain, Size: 2140 bytes --]
On Wed, May 24, 2017 at 04:11:44PM -0400, Stephen Smalley wrote:
> On Wed, 2017-05-24 at 14:08 +0200, Dominick Grift wrote:
> > I was looking again at ioctl whitelisting, and excuse me if I
> > overlooked some documentation, but I am having a hard time
> > implementing this.
> > what I did was I just wanted to basically test blacklisting a single
> > ioctl (no particular one)
> >
> > So i looked into androids sepolicy and just picked a semi-random
> > ioctl from their "https://android.googlesource.com/platform/system/se
> > policy/+/master/public/ioctl_defines"
> >
> > for example: PHONE_CAPABILITIES_CHECK 0x40087182
> >
> > However the xpermissions statement only allows 0x0000 to 0xFFFF when
> > i tried: (xpermission alg_socket_ioctl (ioctl alg_socket (not
> > (0x40087182))))
> >
> > My question is how do i convert these to something i can use with the
> > xpermission statement in CIL, and why can seandroid sepolicy get away
> > with using 0x12345678 where i have to use 0x1234? I could not find
> > any scripts that converts these in the android tree.
>
> FWIW, I added a simple test of ioctl whitelisting to the selinux-
> testsuite, although that was done in source policy and depends on the
> binary module format support for xperms.
>
> With regard to your question though, only the low 16 bits of the ioctl
> value (the type/driver and number/function fields) are actually used;
> the upper 16 bits encode the direction (read/write) and size of any
> argument to the ioctl and are therefore not relevant for whitelisting.
> So you can just use 0x7182. checkpolicy just ignores the upper bits,
> which I guess is convenient so that they can use ioctl macro lists
> generated from kernel header definitions, and Android builds by using
> checkpolicy -C to convert policy.conf to CIL.
Thanks. I considered that but then I thought I saw various different ioctls with the same last 16 bits so that got me confused
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ioctl help
2017-05-25 5:49 ` Dominick Grift
@ 2017-05-25 9:19 ` Dominick Grift
2017-05-25 17:35 ` Jeffrey Vander Stoep
0 siblings, 1 reply; 6+ messages in thread
From: Dominick Grift @ 2017-05-25 9:19 UTC (permalink / raw)
To: selinux
[-- Attachment #1: Type: text/plain, Size: 2711 bytes --]
On Thu, May 25, 2017 at 07:49:19AM +0200, Dominick Grift wrote:
> On Wed, May 24, 2017 at 04:11:44PM -0400, Stephen Smalley wrote:
> > On Wed, 2017-05-24 at 14:08 +0200, Dominick Grift wrote:
> > > I was looking again at ioctl whitelisting, and excuse me if I
> > > overlooked some documentation, but I am having a hard time
> > > implementing this.
> > > what I did was I just wanted to basically test blacklisting a single
> > > ioctl (no particular one)
> > >
> > > So i looked into androids sepolicy and just picked a semi-random
> > > ioctl from their "https://android.googlesource.com/platform/system/se
> > > policy/+/master/public/ioctl_defines"
> > >
> > > for example: PHONE_CAPABILITIES_CHECK 0x40087182
> > >
> > > However the xpermissions statement only allows 0x0000 to 0xFFFF when
> > > i tried: (xpermission alg_socket_ioctl (ioctl alg_socket (not
> > > (0x40087182))))
> > >
> > > My question is how do i convert these to something i can use with the
> > > xpermission statement in CIL, and why can seandroid sepolicy get away
> > > with using 0x12345678 where i have to use 0x1234? I could not find
> > > any scripts that converts these in the android tree.
> >
> > FWIW, I added a simple test of ioctl whitelisting to the selinux-
> > testsuite, although that was done in source policy and depends on the
> > binary module format support for xperms.
> >
> > With regard to your question though, only the low 16 bits of the ioctl
> > value (the type/driver and number/function fields) are actually used;
> > the upper 16 bits encode the direction (read/write) and size of any
> > argument to the ioctl and are therefore not relevant for whitelisting.
> > So you can just use 0x7182. checkpolicy just ignores the upper bits,
> > which I guess is convenient so that they can use ioctl macro lists
> > generated from kernel header definitions, and Android builds by using
> > checkpolicy -C to convert policy.conf to CIL.
>
> Thanks. I considered that but then I thought I saw various different ioctls with the same last 16 bits so that got me confused
With the above in mind, how should i interpret the following
define(`CHIOEXCHANGE', `0x401c6302')
define(`CM_IOCSPTS', `0x40086302')
is "0x6203" CHIOEXCHANGE, is it CM_IOCSPTS, or are the two the same with exception of direction and/or size
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ioctl help
2017-05-25 9:19 ` Dominick Grift
@ 2017-05-25 17:35 ` Jeffrey Vander Stoep
2017-05-25 18:18 ` Stephen Smalley
0 siblings, 1 reply; 6+ messages in thread
From: Jeffrey Vander Stoep @ 2017-05-25 17:35 UTC (permalink / raw)
To: selinux
[-- Attachment #1: Type: text/plain, Size: 3084 bytes --]
The command number is just a uint16. It's up to each driver to interpret
it. So it's CHIOEXCHANGE for a particular driver and CM_IOCSPTS for a
different driver.
Ideally, you're whitelisting ioctls on a per-driver basis, so this model
works.
On Thu, May 25, 2017 at 2:21 AM Dominick Grift <dac.override@gmail.com>
wrote:
> On Thu, May 25, 2017 at 07:49:19AM +0200, Dominick Grift wrote:
> > On Wed, May 24, 2017 at 04:11:44PM -0400, Stephen Smalley wrote:
> > > On Wed, 2017-05-24 at 14:08 +0200, Dominick Grift wrote:
> > > > I was looking again at ioctl whitelisting, and excuse me if I
> > > > overlooked some documentation, but I am having a hard time
> > > > implementing this.
> > > > what I did was I just wanted to basically test blacklisting a single
> > > > ioctl (no particular one)
> > > >
> > > > So i looked into androids sepolicy and just picked a semi-random
> > > > ioctl from their "
> https://android.googlesource.com/platform/system/se
> > > > policy/+/master/public/ioctl_defines"
> > > >
> > > > for example: PHONE_CAPABILITIES_CHECK 0x40087182
> > > >
> > > > However the xpermissions statement only allows 0x0000 to 0xFFFF when
> > > > i tried: (xpermission alg_socket_ioctl (ioctl alg_socket (not
> > > > (0x40087182))))
> > > >
> > > > My question is how do i convert these to something i can use with the
> > > > xpermission statement in CIL, and why can seandroid sepolicy get away
> > > > with using 0x12345678 where i have to use 0x1234? I could not find
> > > > any scripts that converts these in the android tree.
> > >
> > > FWIW, I added a simple test of ioctl whitelisting to the selinux-
> > > testsuite, although that was done in source policy and depends on the
> > > binary module format support for xperms.
> > >
> > > With regard to your question though, only the low 16 bits of the ioctl
> > > value (the type/driver and number/function fields) are actually used;
> > > the upper 16 bits encode the direction (read/write) and size of any
> > > argument to the ioctl and are therefore not relevant for whitelisting.
> > > So you can just use 0x7182. checkpolicy just ignores the upper bits,
> > > which I guess is convenient so that they can use ioctl macro lists
> > > generated from kernel header definitions, and Android builds by using
> > > checkpolicy -C to convert policy.conf to CIL.
> >
> > Thanks. I considered that but then I thought I saw various different
> ioctls with the same last 16 bits so that got me confused
>
> With the above in mind, how should i interpret the following
>
> define(`CHIOEXCHANGE', `0x401c6302')
> define(`CM_IOCSPTS', `0x40086302')
>
> is "0x6203" CHIOEXCHANGE, is it CM_IOCSPTS, or are the two the same with
> exception of direction and/or size
>
> >
> > --
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > Dominick Grift
>
>
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift
>
[-- Attachment #2: Type: text/html, Size: 4254 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ioctl help
2017-05-25 17:35 ` Jeffrey Vander Stoep
@ 2017-05-25 18:18 ` Stephen Smalley
0 siblings, 0 replies; 6+ messages in thread
From: Stephen Smalley @ 2017-05-25 18:18 UTC (permalink / raw)
To: Jeffrey Vander Stoep, selinux
On Thu, 2017-05-25 at 17:35 +0000, Jeffrey Vander Stoep via Selinux
wrote:
> The command number is just a uint16. It's up to each driver to
> interpret it. So it's CHIOEXCHANGE for a particular driver
> and CM_IOCSPTS for a different driver.
>
> Ideally, you're whitelisting ioctls on a per-driver basis, so this
> model works.
Possibly to avoid user confusion, we should have checkpolicy only
accept values 0-0xffff (as with CIL), and the macros should be
truncated when they are generated. Otherwise, reading the policy could
be misleading.
>
> On Thu, May 25, 2017 at 2:21 AM Dominick Grift <dac.override@gmail.co
> m> wrote:
> > On Thu, May 25, 2017 at 07:49:19AM +0200, Dominick Grift wrote:
> > > On Wed, May 24, 2017 at 04:11:44PM -0400, Stephen Smalley wrote:
> > > > On Wed, 2017-05-24 at 14:08 +0200, Dominick Grift wrote:
> > > > > I was looking again at ioctl whitelisting, and excuse me if I
> > > > > overlooked some documentation, but I am having a hard time
> > > > > implementing this.
> > > > > what I did was I just wanted to basically test blacklisting a
> > single
> > > > > ioctl (no particular one)
> > > > >
> > > > > So i looked into androids sepolicy and just picked a semi-
> > random
> > > > > ioctl from their "https://android.googlesource.com/platform/s
> > ystem/se
> > > > > policy/+/master/public/ioctl_defines"
> > > > >
> > > > > for example: PHONE_CAPABILITIES_CHECK 0x40087182
> > > > >
> > > > > However the xpermissions statement only allows 0x0000 to
> > 0xFFFF when
> > > > > i tried: (xpermission alg_socket_ioctl (ioctl alg_socket (not
> > > > > (0x40087182))))
> > > > >
> > > > > My question is how do i convert these to something i can use
> > with the
> > > > > xpermission statement in CIL, and why can seandroid sepolicy
> > get away
> > > > > with using 0x12345678 where i have to use 0x1234? I could not
> > find
> > > > > any scripts that converts these in the android tree.
> > > >
> > > > FWIW, I added a simple test of ioctl whitelisting to the
> > selinux-
> > > > testsuite, although that was done in source policy and depends
> > on the
> > > > binary module format support for xperms.
> > > >
> > > > With regard to your question though, only the low 16 bits of
> > the ioctl
> > > > value (the type/driver and number/function fields) are actually
> > used;
> > > > the upper 16 bits encode the direction (read/write) and size of
> > any
> > > > argument to the ioctl and are therefore not relevant for
> > whitelisting.
> > > > So you can just use 0x7182. checkpolicy just ignores the upper
> > bits,
> > > > which I guess is convenient so that they can use ioctl macro
> > lists
> > > > generated from kernel header definitions, and Android builds by
> > using
> > > > checkpolicy -C to convert policy.conf to CIL.
> > >
> > > Thanks. I considered that but then I thought I saw various
> > different ioctls with the same last 16 bits so that got me confused
> >
> > With the above in mind, how should i interpret the following
> >
> > define(`CHIOEXCHANGE', `0x401c6302')
> > define(`CM_IOCSPTS', `0x40086302')
> >
> > is "0x6203" CHIOEXCHANGE, is it CM_IOCSPTS, or are the two the same
> > with exception of direction and/or size
> >
> > >
> > > --
> > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B
> > 6B02
> > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7
> > B6B02
> > > Dominick Grift
> >
> >
> >
> > --
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B
> > 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6
> > B02
> > Dominick Grift
> >
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-05-25 18:18 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-24 12:08 ioctl help Dominick Grift
2017-05-24 20:11 ` Stephen Smalley
2017-05-25 5:49 ` Dominick Grift
2017-05-25 9:19 ` Dominick Grift
2017-05-25 17:35 ` Jeffrey Vander Stoep
2017-05-25 18:18 ` Stephen Smalley
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.