Problem building CIL module with new class

Problem building CIL module with new class

[Richard Haines]

Using Fedora 23 targeted policy.

Problem: When adding a new class via the CIL module listed below, the allow
rule is not being resolved if the new class references a common set of
permissions.

Viewing with apol shows that the new class has been allocated the unique and
common permissions, however the allow rule is missing.

Note 1: If the 'all' expression is replaced in the 'classpermissionset' with
the actual permissions, then the allow rule is resolved.

Note 2: If I use the latest 2.5 libsepol with the
(classorder (unordered sctp_socket)) statement I get the same result.

The example CIL policy module is:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(classorder (proxy sctp_socket))  ; 'proxy' is the last class defined in F-23
                                                                  ; and required when using libsepol 2.4

(classcommon sctp_socket socket)
(class sctp_socket (node_bind name_connect association bindx_add bindx_rem
connectx peeloff set_addr set_params))

(classpermission sctp_socket_all_perms)
(classpermissionset sctp_socket_all_perms (sctp_socket (all)))

(allow unconfined_t self sctp_socket_all_perms)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

And is built with the following command:

semodule --priority 400 -i sctp_test_module.cil

Any ideas !!!
Richard

Re: Problem building CIL module with new class

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/17/2016 04:25 PM, Richard Haines wrote:
> Using Fedora 23 targeted policy.
> 
> Problem: When adding a new class via the CIL module listed below, 
> the allow rule is not being resolved if the new class references a 
> common set of permissions.
> 
> Viewing with apol shows that the new class has been allocated the 
> unique and common permissions, however the allow rule is missing.
> 
> Note 1: If the 'all' expression is replaced in the 
> 'classpermissionset' with the actual permissions, then the allow 
> rule is resolved.
> 
> Note 2: If I use the latest 2.5 libsepol with the (classorder 
> (unordered sctp_socket)) statement I get the same result.
> 
> The example CIL policy module is: 
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (classorder (proxy 
> sctp_socket))  ; 'proxy' is the last class defined in F-23 ; and 
> required when using libsepol 2.4
> 
> (classcommon sctp_socket socket) (class sctp_socket (node_bind 
> name_connect association bindx_add bindx_rem connectx peeloff 
> set_addr set_params))
> 
> (classpermission sctp_socket_all_perms) (classpermissionset 
> sctp_socket_all_perms (sctp_socket (all)))
> 
> (allow unconfined_t self sctp_socket_all_perms) 
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> 
> And is built with the following command:
> 
> semodule --priority 400 -i sctp_test_module.cil

Maybe it is related to semodule? Seems to work fine when tested with DSS
P:

https://www.youtube.com/watch?v=NYMoPUNTqes

[root@void kcinimod]# rpm -qa | grep libselinux
libselinux-2.4-4.fc23.x86_64
libselinux-utils-2.4-4.fc23.x86_64
libselinux-python3-2.4-4.fc23.x86_64
libselinux-2.4-4.fc23.i686
[root@void kcinimod]# rpm -qa | grep libsepol
libsepol-2.5-9999.gitb3b5ede.fc24.x86_64
[root@void kcinimod]# rpm -qa | grep setools
setools-4.0-9999.gitac4f846.fc23.x86_64
setools-gui-4.0-9999.gitac4f846.fc23.x86_64
[root@void kcinimod]# rpm -qa | grep secilc
secilc-2.5-9999.gitb3b5ede.fc24.x86_64

> 
> Any ideas !!! Richard 
> _______________________________________________ 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.
> 


- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJW6tOvAAoJECV0jlU3+UdpijYL+gPumCA7OVEC4MlZ7gqBj7+P
EXaWX7MKUC4FUdyKljd416/l1aj0y5m3ihKmx/Iiyk9ZJim//BIQCoKtySXooo3w
RmAIFx1vRd3qet88W9L9zhfq+q+wPnXSOBsbBwSylVQdC5dLMtxYnZwAgm1Jraxp
LRw92wz5rn1OS33M5+/v7sLwfP5sx8yakoD//DN2hJO0FmOmrbB+/I77iXMjoIjH
jDIKSqBufS4IgQO+xN5a42hjfzxVlhrKX4wCDaafagkQQBOQpD4Il5xHx70ZzE55
mvVzyCyIGZ8QpVGM4MhyaKIvXPwffCFNwivCSPjiEz5AMDc2IbbNDEb4cH6br7SR
4DCHyGWwyO3QhbW2BALGFp3mH4lYoFNyetRE6xVKqDYf6OZ5jLJaQZwqHuUpSkvG
XGb3fzLsSFFQo/0X8Et9yGLyvsFNf/Gb5K85mYOSKDhYFMQ9ZIL56rQKK+GXZtrA
+54icfOw1f8laVISosIuoCX4T/W5U+4ap90bpHbdRQ==
=r/id
-----END PGP SIGNATURE-----

Re: Problem building CIL module with new class

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/17/2016 04:56 PM, Dominick Grift wrote:
> On 03/17/2016 04:25 PM, Richard Haines wrote:
>> Using Fedora 23 targeted policy.
> 
>> Problem: When adding a new class via the CIL module listed below,
>>  the allow rule is not being resolved if the new class references
>> a common set of permissions.
> 
>> Viewing with apol shows that the new class has been allocated the
>>  unique and common permissions, however the allow rule is
>> missing.
> 
>> Note 1: If the 'all' expression is replaced in the 
>> 'classpermissionset' with the actual permissions, then the allow
>>  rule is resolved.
> 
>> Note 2: If I use the latest 2.5 libsepol with the (classorder 
>> (unordered sctp_socket)) statement I get the same result.
> 
>> The example CIL policy module is: 
>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (classorder (proxy 
>> sctp_socket))  ; 'proxy' is the last class defined in F-23 ; and
>>  required when using libsepol 2.4
> 
>> (classcommon sctp_socket socket) (class sctp_socket (node_bind 
>> name_connect association bindx_add bindx_rem connectx peeloff 
>> set_addr set_params))
> 
>> (classpermission sctp_socket_all_perms) (classpermissionset 
>> sctp_socket_all_perms (sctp_socket (all)))
> 
>> (allow unconfined_t self sctp_socket_all_perms) 
>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> 
>> And is built with the following command:
> 
>> semodule --priority 400 -i sctp_test_module.cil
> 
> Maybe it is related to semodule? Seems to work fine when tested
> with DSS P:
> 
> https://www.youtube.com/watch?v=NYMoPUNTqes
> 
> [root@void kcinimod]# rpm -qa | grep libselinux 
> libselinux-2.4-4.fc23.x86_64 libselinux-utils-2.4-4.fc23.x86_64 
> libselinux-python3-2.4-4.fc23.x86_64 libselinux-2.4-4.fc23.i686 
> [root@void kcinimod]# rpm -qa | grep libsepol 
> libsepol-2.5-9999.gitb3b5ede.fc24.x86_64 [root@void kcinimod]# rpm
> -qa | grep setools setools-4.0-9999.gitac4f846.fc23.x86_64 
> setools-gui-4.0-9999.gitac4f846.fc23.x86_64 [root@void kcinimod]#
> rpm -qa | grep secilc secilc-2.5-9999.gitb3b5ede.fc24.x86_64
> 
> 

What truly sucks though is that when you add a new access vector you
have to reboot because else you get issues like this:

avc:  denied  { send_msg } for msgtype=method_return dest=:1.186
spid=2137 tpid=17186
scontext=wheel.id:wheel.role:wheel_evosr.subj:s0-s0:c0.c1023
tcontext=wheel.id:wheel.role:wheel_evocf.subj:s0-s0:c0.c1023 tclass=dbus

[root@void kcinimod]# sesearch -A -s wheel_evocf.subj -t
wheel_evosr.subj -c dbus
allow wheel_evosr.sessbus_chat_client_subj_type_attribute
wheel_evosr.subj:dbus send_msg;

I.E. the user space access vectors/object managers get confused...
There is a rule to allow the above avc denials (as per the sesearch
output) but dbus still denies access.

>> Any ideas !!! Richard 
>> _______________________________________________ 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.
> 
> 
> 
> 

- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJW6tVuAAoJECV0jlU3+UdpaOUL/0lvAexcEmd3Nmiqs3M2S/wE
vCL9598nZk03uZgZub7qpCszCgmK3D5KV61Z6qIgnuIkCOFouFwohEEEMZt61fzb
bJUmUCCLvJZM0kO+RQ86J0VtZoDKE+dqcCmsOfxh+U+EyGGVPKyLWMQTb+NQ7HrG
ZgscKkU9Ujc901pPnyhTbXV/cO3okV9WEd5IvpxSn2DarNC4X++BInfZYqlFo8+n
9rk9ty3awFNwm5rUwcFSepnRAQQ+rRQRZjw9X50nMpQ9bigf7mON9xleUg+1Cjyz
ECcrxZDwjY4ne7y5DiJi/xHT3fAGRFfsyiJmFV1jOt/xMGla0c8mL7iUlbwbOMXv
aoQe+c/4VDuDStvGcXWCsbf6gZBKmjd02kuFlq+zEYXzUdTav2P1MjCvVhzj3VFf
Zenz/UPLB/y310D1ck+0zicq9sGiP5Rt7nTV9G0WxbGN05JqkXzacFsT5nKPPSQc
EQ09GsUTLGBxKhCdBkHQvy8gYBRZ06wOGX8rVDbhBw==
=OOvB
-----END PGP SIGNATURE-----

Re: Problem building CIL module with new class

[Steve Lawrence]

On 03/17/2016 11:25 AM, Richard Haines wrote:
> Using Fedora 23 targeted policy.
> 
> Problem: When adding a new class via the CIL module listed below, the allow
> rule is not being resolved if the new class references a common set of
> permissions.
> 
> Viewing with apol shows that the new class has been allocated the unique and
> common permissions, however the allow rule is missing.
> 
> Note 1: If the 'all' expression is replaced in the 'classpermissionset' with
> the actual permissions, then the allow rule is resolved.
> 
> Note 2: If I use the latest 2.5 libsepol with the
> (classorder (unordered sctp_socket)) statement I get the same result.
> 
> The example CIL policy module is:
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> (classorder (proxy sctp_socket))  ; 'proxy' is the last class defined in F-23
>                                                                   ; and required when using libsepol 2.4
> 
> (classcommon sctp_socket socket)
> (class sctp_socket (node_bind name_connect association bindx_add bindx_rem
> connectx peeloff set_addr set_params))
> 
> (classpermission sctp_socket_all_perms)
> (classpermissionset sctp_socket_all_perms (sctp_socket (all)))
> 
> (allow unconfined_t self sctp_socket_all_perms)
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> 
> And is built with the following command:
> 
> semodule --priority 400 -i sctp_test_module.cil
> 
> Any ideas !!!
> Richard

I am able reproduce the issue. Looking into it now.

Thanks,
- Steve