From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p7NAReBg019334 for ; Tue, 23 Aug 2011 06:27:42 -0400 Received: from snt0-omc1-s18.snt0.hotmail.com (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p7NARfBW017496 for ; Tue, 23 Aug 2011 10:27:42 GMT Message-ID: Content-Type: multipart/mixed; boundary="_0d12c44c-e38c-457a-9ae3-2a846a914d70_" From: HarryCiao To: , Subject: [refpolicy] My patchset to test "Separating tunables from booleans" Date: Tue, 23 Aug 2011 10:27:36 +0000 MIME-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov --_0d12c44c-e38c-457a-9ae3-2a846a914d70_ Content-Type: multipart/alternative; boundary="_48608c80-cb1b-4126-8700-7e4628a72974_" --_48608c80-cb1b-4126-8700-7e4628a72974_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi, This is the refpolicy patchset to test along with new toolchain feature of separating tunables from booleans, generally speaking a "tunable" keyword is introduced and made use of by tunable_policy(), whereas a new boolean_policy() macro would make use of the "bool" keyword. tunable is indeed a boolean, except that the COND_BOOL_FLAGS_TUNABLE bit would be set in the newly added member of flags in the cond_bool_datum_t structure. Once the new toolchain feature is welcomed and merged, we could change refpolicy to shrink policy.X size significantly. Any comments or suggestions as for how to better this new toolchain feature are greatly welcomed. Thanks! Harry --_48608c80-cb1b-4126-8700-7e4628a72974_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit

Hi,

This is the refpolicy patchset to test along with new toolchain feature of separating tunables from booleans, generally speaking a "tunable" keyword is introduced and made use of by tunable_policy(), whereas a new boolean_policy() macro would make use of the "bool" keyword.

tunable is indeed a boolean, except that the COND_BOOL_FLAGS_TUNABLE bit would be set in the newly added member of flags in the cond_bool_datum_t structure.

Once the new toolchain feature is welcomed and merged, we could change refpolicy to shrink policy.X size significantly.

Any comments or suggestions as for how to better this new toolchain feature are greatly welcomed.

Thanks!

Harry

--_48608c80-cb1b-4126-8700-7e4628a72974_-- --_0d12c44c-e38c-457a-9ae3-2a846a914d70_ Content-Type: text/x-patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0001-Add-the-definition-of-the-boolean_policy-marcro.patch" RnJvbSA3N2NlMTgyMTg0NDY3ZDQzNDI4MWM1YWJhMmM4NmM5ZWUxNDQwYTU3IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBIYXJyeSBDaWFvIDxxaW5ndGFvLmNhb0B3aW5kcml2ZXIuY29t PgpEYXRlOiBTdW4sIDIxIEF1ZyAyMDExIDE4OjE5OjQxICswODAwClN1YmplY3Q6IFtyZWZwb2xp Y3ldW3YwIFBBVENIIDEvNF0gQWRkIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBib29sZWFuX3BvbGlj eSBtYXJjcm8uCgpib29sZWFuX3BvbGljeSBtYWNybyB3b3VsZCBtYWtlIHVzZSBvZiBib29sZWFu IGZvciBydW50aW1lIGNvbmRpdGlvbmFscywKd2hpbGUgdHVuYWJsZV9wb2xpY3kgbWFjcm8gd291 bGQgdXNlIHR1bmFibGUgcmF0aGVyIHRoYW4gYm9vbGVhbiBmb3IKYnVpbGQtdGltZSBjb25kaXRp b25hbHMuCgpTaWduZWQtb2ZmLWJ5OiBIYXJyeSBDaWFvIDxxaW5ndGFvLmNhb0B3aW5kcml2ZXIu Y29tPgotLS0KIHBvbGljeS9zdXBwb3J0L2xvYWRhYmxlX21vZHVsZS5zcHQgfCAgIDM4ICsrKysr KysrKysrKysrKysrKysrKysrKysrKysrKystLS0tCiAxIGZpbGVzIGNoYW5nZWQsIDMzIGluc2Vy dGlvbnMoKyksIDUgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvcG9saWN5L3N1cHBvcnQvbG9h ZGFibGVfbW9kdWxlLnNwdCBiL3BvbGljeS9zdXBwb3J0L2xvYWRhYmxlX21vZHVsZS5zcHQKaW5k ZXggMWZlM2FiMy4uMjUxYTVmOSAxMDA2NDQKLS0tIGEvcG9saWN5L3N1cHBvcnQvbG9hZGFibGVf bW9kdWxlLnNwdAorKysgYi9wb2xpY3kvc3VwcG9ydC9sb2FkYWJsZV9tb2R1bGUuc3B0CkBAIC0x MjAsMTAgKzEyMCwyMyBAQCBkZWZpbmUoYGRmbHRfb3Jfb3ZlcnInLGBpZmRlZihgJDEnLCQxLCQy KScpCiAjIFRoaXMgbmVlZHMgdG8gYmUgcmV3b3JrZWQgc28gZXhwcmVzc2lvbnMKICMgd2l0aCBw YXJlbnRoZXNlcyBjYW4gd29yay4KIAotZGVmaW5lKGBkZWNsYXJlX3JlcXVpcmVkX3N5bWJvbHMn LGAKK2RlZmluZShgZGVjbGFyZV9yZXF1aXJlZF9ib29sZWFucycsYAogaWZlbHNlKHJlZ2V4cCgk MSwgYFx3JyksIC0xLCBgJywgYGRubAogYm9vbCByZWdleHAoJDEsIGBcKFx3K1wpJywgYFwxJyk7 Ci1kZWNsYXJlX3JlcXVpcmVkX3N5bWJvbHMocmVnZXhwKCQxLCBgXHcrXCguKlwpJywgYFwxJykp ZG5sCitkZWNsYXJlX3JlcXVpcmVkX2Jvb2xlYW5zKHJlZ2V4cCgkMSwgYFx3K1woLipcKScsIGBc MScpKWRubAorJykgZG5sCisnKQorCisjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKKyMK KyMgRXh0cmFjdCB0dW5hYmxlcyBvdXQgb2YgYW4gZXhwcmVzc2lvbi4KKyMgVGhpcyBuZWVkcyB0 byBiZSByZXdvcmtlZCBzbyBleHByZXNzaW9ucworIyB3aXRoIHBhcmVudGhlc2VzIGNhbiB3b3Jr LgorCitkZWZpbmUoYGRlY2xhcmVfcmVxdWlyZWRfdHVuYWJsZXMnLGAKK2lmZWxzZShyZWdleHAo JDEsIGBcdycpLCAtMSwgYCcsIGBkbmwKK3R1bmFibGUgcmVnZXhwKCQxLCBgXChcdytcKScsIGBc MScpOworZGVjbGFyZV9yZXF1aXJlZF90dW5hYmxlcyhyZWdleHAoJDEsIGBcdytcKC4qXCknLCBg XDEnKSlkbmwKICcpIGRubAogJykKIApAQCAtMTMyLDE2ICsxNDUsMzEgQEAgZGVjbGFyZV9yZXF1 aXJlZF9zeW1ib2xzKHJlZ2V4cCgkMSwgYFx3K1woLipcKScsIGBcMScpKWRubAogIyBUdW5hYmxl IGRlY2xhcmF0aW9uCiAjCiBkZWZpbmUoYGdlbl90dW5hYmxlJyxgCi0JYm9vbCAkMSBkZmx0X29y X292ZXJyKGAkMSdfY29uZiwkMik7CisJdHVuYWJsZSAkMSBkZmx0X29yX292ZXJyKGAkMSdfY29u ZiwkMik7CiAnKQogCiAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKICMKLSMgVHVuYWJs ZSBwb2xpY3kgaGFuZGxpbmcKKyMgQnVpbGQtdGltZSB0dW5hYmxlIHBvbGljeSBoYW5kbGluZwog IwogZGVmaW5lKGB0dW5hYmxlX3BvbGljeScsYAogCWdlbl9yZXF1aXJlKGAKLQkJZGVjbGFyZV9y ZXF1aXJlZF9zeW1ib2xzKGAkMScpCisJCWRlY2xhcmVfcmVxdWlyZWRfdHVuYWJsZXMoYCQxJykK KwknKQorCWlmIChgJDEnKSB7CisJCSQyCisJaWZlbHNlKGAkMycsYCcsYCcsYH0gZWxzZSB7CisJ CSQzCisJJyl9CisnKQorCisjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKKyMKKyMgUnVu dGltZSBib29sZWFuIHBvbGljeSBoYW5kbGluZworIworZGVmaW5lKGBib29sZWFuX3BvbGljeScs YAorCWdlbl9yZXF1aXJlKGAKKwkJZGVjbGFyZV9yZXF1aXJlZF9ib29sZWFucyhgJDEnKQogCScp CiAJaWYgKGAkMScpIHsKIAkJJDIKLS0gCjEuNy4wLjQKCg== --_0d12c44c-e38c-457a-9ae3-2a846a914d70_ Content-Type: text/x-patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0002-user_ping-is-a-tunable-use-tunable_policy-for-it.patch" RnJvbSAxN2I0MWI5ZWEwYjkyYWFkMTQ0YTJiODcxNzRkN2ViNmY5YzM4M2FlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBIYXJyeSBDaWFvIDxxaW5ndGFvLmNhb0B3aW5kcml2ZXIuY29t PgpEYXRlOiBTdW4sIDIxIEF1ZyAyMDExIDE5OjM4OjQ2ICswODAwClN1YmplY3Q6IFtyZWZwb2xp Y3ldW3YwIFBBVENIIDIvNF0gdXNlcl9waW5nIGlzIGEgdHVuYWJsZSwgdXNlIHR1bmFibGVfcG9s aWN5IGZvciBpdC4KCnVzZXJfcGluZyBpcyBhIHR1bmFibGUsIHVzZSB0dW5hYmxlX3BvbGljeSBm b3IgaXQuCgpTaWduZWQtb2ZmLWJ5OiBIYXJyeSBDaWFvIDxxaW5ndGFvLmNhb0B3aW5kcml2ZXIu Y29tPgotLS0KIHBvbGljeS9tb2R1bGVzL2FkbWluL25ldHV0aWxzLmlmIHwgICAxMCArKysrLS0t LS0tCiAxIGZpbGVzIGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygrKSwgNiBkZWxldGlvbnMoLSkKCmRp ZmYgLS1naXQgYS9wb2xpY3kvbW9kdWxlcy9hZG1pbi9uZXR1dGlscy5pZiBiL3BvbGljeS9tb2R1 bGVzL2FkbWluL25ldHV0aWxzLmlmCmluZGV4IGM2Y2E3NjEuLjQxNjQyOTIgMTAwNjQ0Ci0tLSBh L3BvbGljeS9tb2R1bGVzL2FkbWluL25ldHV0aWxzLmlmCisrKyBiL3BvbGljeS9tb2R1bGVzL2Fk bWluL25ldHV0aWxzLmlmCkBAIC0xODMsMTQgKzE4MywxMyBAQCBpbnRlcmZhY2UoYG5ldHV0aWxz X3J1bl9waW5nJyxgCiBpbnRlcmZhY2UoYG5ldHV0aWxzX3J1bl9waW5nX2NvbmQnLGAKIAlnZW5f cmVxdWlyZShgCiAJCXR5cGUgcGluZ190OwotCQlib29sIHVzZXJfcGluZzsKIAknKQogCiAJcm9s ZSAkMiB0eXBlcyBwaW5nX3Q7CiAKLQlpZiAoIHVzZXJfcGluZyApIHsKKwl0dW5hYmxlX3BvbGlj eShgdXNlcl9waW5nJyxgCiAJCW5ldHV0aWxzX2RvbXRyYW5zX3BpbmcoJDEpCi0JfQorCScpCiAn KQogCiAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCkBAIC0yNzcsMTQg KzI3NiwxMyBAQCBpbnRlcmZhY2UoYG5ldHV0aWxzX3J1bl90cmFjZXJvdXRlJyxgCiBpbnRlcmZh Y2UoYG5ldHV0aWxzX3J1bl90cmFjZXJvdXRlX2NvbmQnLGAKIAlnZW5fcmVxdWlyZShgCiAJCXR5 cGUgdHJhY2Vyb3V0ZV90OwotCQlib29sIHVzZXJfcGluZzsKIAknKQogCiAJcm9sZSAkMiB0eXBl cyB0cmFjZXJvdXRlX3Q7CiAKLQlpZiggdXNlcl9waW5nICkgeworCXR1bmFibGVfcG9saWN5KGB1 c2VyX3BpbmcnLGAKIAkJbmV0dXRpbHNfZG9tdHJhbnNfdHJhY2Vyb3V0ZSgkMSkKLQl9CisJJykK ICcpCiAKICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKLS0gCjEuNy4w LjQKCg== --_0d12c44c-e38c-457a-9ae3-2a846a914d70_ Content-Type: text/x-patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0003-mmap_low_allowed-is-a-tunable-use-tunable_policy-for.patch" RnJvbSBmNTBlYTkxMjUwOWU3MDc0NGY1NTAyMDg3OTNiZjM4YjFmOTM3NGU4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBIYXJyeSBDaWFvIDxxaW5ndGFvLmNhb0B3aW5kcml2ZXIuY29t PgpEYXRlOiBNb24sIDIyIEF1ZyAyMDExIDE0OjEyOjU1ICswODAwClN1YmplY3Q6IFtyZWZwb2xp Y3ldW3YwIFBBVENIIDMvNF0gbW1hcF9sb3dfYWxsb3dlZCBpcyBhIHR1bmFibGUsIHVzZSB0dW5h YmxlX3BvbGljeSBmb3IgaXQKCm1tYXBfbG93X2FsbG93ZWQgaXMgYSB0dW5hYmxlLCB1c2UgdHVu YWJsZV9wb2xpY3kgZm9yIGl0LgoKU2lnbmVkLW9mZi1ieTogSGFycnkgQ2lhbyA8cWluZ3Rhby5j YW9Ad2luZHJpdmVyLmNvbT4KLS0tCiBwb2xpY3kvbW9kdWxlcy9rZXJuZWwvZG9tYWluLmlmIHwg ICAgNSArKy0tLQogMSBmaWxlcyBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25z KC0pCgpkaWZmIC0tZ2l0IGEvcG9saWN5L21vZHVsZXMva2VybmVsL2RvbWFpbi5pZiBiL3BvbGlj eS9tb2R1bGVzL2tlcm5lbC9kb21haW4uaWYKaW5kZXggNmExZTRkMS4uODk5YzliZiAxMDA2NDQK LS0tIGEvcG9saWN5L21vZHVsZXMva2VybmVsL2RvbWFpbi5pZgorKysgYi9wb2xpY3kvbW9kdWxl cy9rZXJuZWwvZG9tYWluLmlmCkBAIC0xNDM0LDE0ICsxNDM0LDEzIEBAIGludGVyZmFjZShgZG9t YWluX2VudHJ5X2ZpbGVfc3BlY19kb210cmFucycsYAogaW50ZXJmYWNlKGBkb21haW5fbW1hcF9s b3cnLGAKIAlnZW5fcmVxdWlyZShgCiAJCWF0dHJpYnV0ZSBtbWFwX2xvd19kb21haW5fdHlwZTsK LQkJYm9vbCBtbWFwX2xvd19hbGxvd2VkOwogCScpCiAKIAl0eXBlYXR0cmlidXRlICQxIG1tYXBf bG93X2RvbWFpbl90eXBlOwogCi0JaWYgKCBtbWFwX2xvd19hbGxvd2VkICkgeworCXR1bmFibGVf cG9saWN5KGBtbWFwX2xvd19hbGxvd2VkJyxgCiAJCWFsbG93ICQxIHNlbGY6bWVtcHJvdGVjdCBt bWFwX3plcm87Ci0JfQorCScpCiAnKQogCiAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjCi0tIAoxLjcuMC40Cgo= --_0d12c44c-e38c-457a-9ae3-2a846a914d70_ Content-Type: text/x-patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0004-secure_mode_insmod-is-a-boolean-use-boolean_policy-f.patch" RnJvbSA0OWU0MTVlZmUxY2Y3ZDJhNGRkYTY2YTEyNDZiNGNmNzMwMzE4MjljIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBIYXJyeSBDaWFvIDxxaW5ndGFvLmNhb0B3aW5kcml2ZXIuY29t PgpEYXRlOiBNb24sIDIyIEF1ZyAyMDExIDE0OjE1OjUyICswODAwClN1YmplY3Q6IFtyZWZwb2xp Y3ldW3YwIFBBVENIIDQvNF0gc2VjdXJlX21vZGVfaW5zbW9kIGlzIGEgYm9vbGVhbiwgdXNlIGJv b2xlYW5fcG9saWN5IGZvciBpdC4KCnNlY3VyZV9tb2RlX2luc21vZCBpcyBhIGJvb2xlYW4sIHVz ZSBib29sZWFuX3BvbGljeSBmb3IgaXQuCgpTaWduZWQtb2ZmLWJ5OiBIYXJyeSBDaWFvIDxxaW5n dGFvLmNhb0B3aW5kcml2ZXIuY29tPgotLS0KIHBvbGljeS9tb2R1bGVzL3N5c3RlbS9tb2R1dGls cy5pZiB8ICAgIDggKystLS0tLS0KIHBvbGljeS9tb2R1bGVzL3N5c3RlbS9tb2R1dGlscy50ZSB8 ICAgIDggKystLS0tLS0KIDIgZmlsZXMgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCAxMiBkZWxl dGlvbnMoLSkKCmRpZmYgLS1naXQgYS9wb2xpY3kvbW9kdWxlcy9zeXN0ZW0vbW9kdXRpbHMuaWYg Yi9wb2xpY3kvbW9kdWxlcy9zeXN0ZW0vbW9kdXRpbHMuaWYKaW5kZXggOWMwZmFhYi4uNmU3ZTBl ZiAxMDA2NDQKLS0tIGEvcG9saWN5L21vZHVsZXMvc3lzdGVtL21vZHV0aWxzLmlmCisrKyBiL3Bv bGljeS9tb2R1bGVzL3N5c3RlbS9tb2R1dGlscy5pZgpAQCAtMTUyLDEzICsxNTIsOSBAQCBpbnRl cmZhY2UoYG1vZHV0aWxzX2RvbXRyYW5zX2luc21vZF91bmNvbmQnLGAKICMjIDwvcGFyYW0+CiAj CiBpbnRlcmZhY2UoYG1vZHV0aWxzX2RvbXRyYW5zX2luc21vZCcsYAotCWdlbl9yZXF1aXJlKGAK LQkJYm9vbCBzZWN1cmVfbW9kZV9pbnNtb2Q7Ci0JJykKLQotCWlmICghc2VjdXJlX21vZGVfaW5z bW9kKSB7CisJYm9vbGVhbl9wb2xpY3koYCFzZWN1cmVfbW9kZV9pbnNtb2QnLGAKIAkJbW9kdXRp bHNfZG9tdHJhbnNfaW5zbW9kX3VuY29uZCgkMSkKLQl9CisJJykKICcpCiAKICMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKZGlmZiAtLWdpdCBhL3BvbGljeS9tb2R1bGVz L3N5c3RlbS9tb2R1dGlscy50ZSBiL3BvbGljeS9tb2R1bGVzL3N5c3RlbS9tb2R1dGlscy50ZQpp bmRleCBkYTAxNGVkLi4xNDMxMTJhIDEwMDY0NAotLS0gYS9wb2xpY3kvbW9kdWxlcy9zeXN0ZW0v bW9kdXRpbHMudGUKKysrIGIvcG9saWN5L21vZHVsZXMvc3lzdGVtL21vZHV0aWxzLnRlCkBAIC0x LDkgKzEsNSBAQAogcG9saWN5X21vZHVsZShtb2R1dGlscywgMS4xMS4wKQogCi1nZW5fcmVxdWly ZShgCi0JYm9vbCBzZWN1cmVfbW9kZV9pbnNtb2Q7Ci0nKQotCiAjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjCiAjCiAjIERlY2xhcmF0aW9ucwpAQCAtMTc4LDkgKzE3NCw5 IEBAIHVzZXJkb21fdXNlX3VzZXJfdGVybWluYWxzKGluc21vZF90KQogCiB1c2VyZG9tX2RvbnRh dWRpdF9zZWFyY2hfdXNlcl9ob21lX2RpcnMoaW5zbW9kX3QpCiAKLWlmKCAhIHNlY3VyZV9tb2Rl X2luc21vZCApIHsKK2Jvb2xlYW5fcG9saWN5KGAhc2VjdXJlX21vZGVfaW5zbW9kJyxgCiAJa2Vy bmVsX2RvbXRyYW5zX3RvKGluc21vZF90LCBpbnNtb2RfZXhlY190KQotfQorJykKIAogb3B0aW9u YWxfcG9saWN5KGAKIAlhbHNhX2RvbXRyYW5zKGluc21vZF90KQotLSAKMS43LjAuNAoK --_0d12c44c-e38c-457a-9ae3-2a846a914d70_-- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p7NDiWVl029638 for ; Tue, 23 Aug 2011 09:44:33 -0400 Received: from exchange10.columbia.tresys.com (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p7NDiWpd028039 for ; Tue, 23 Aug 2011 13:44:33 GMT Message-ID: <4E53AEC0.7040009@tresys.com> Date: Tue, 23 Aug 2011 09:44:32 -0400 From: "Christopher J. PeBenito" MIME-Version: 1.0 To: HarryCiao CC: , Subject: Re: [refpolicy] My patchset to test "Separating tunables from booleans" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On 08/23/11 06:27, HarryCiao wrote: > This is the refpolicy patchset to test along with new toolchain feature > of separating tunables from booleans, generally speaking a "tunable" > keyword is introduced and made use of by tunable_policy(), whereas a new > boolean_policy() macro would make use of the "bool" keyword. > > tunable is indeed a boolean, except that the COND_BOOL_FLAGS_TUNABLE bit > would be set in the newly added member of flags in the cond_bool_datum_t > structure. > > Once the new toolchain feature is welcomed and merged, we could change > refpolicy to shrink policy.X size significantly. > > Any comments or suggestions as for how to better this new toolchain > feature are greatly welcomed. To make sure I understand correctly, a tunable block will have the same token in the raw policy as runtime conditional blocks? e.g. tunable foo false; if (foo) { .... } If tunable blocks use the same token, I think Refpolicy would just drop the tunable_policy() macro. There are no examples of this in Refpolicy, but can you mix Booleans and tunables in an expression? e.g. tunable foo true; boolean bar true; if (foo || bar) { .... } I'd say its not a requirement, I'm just trying to make sure I understand the features. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p7O5dopo012001 for ; Wed, 24 Aug 2011 01:39:50 -0400 Received: from snt0-omc4-s1.snt0.hotmail.com (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p7O5dnrO025196 for ; Wed, 24 Aug 2011 05:39:49 GMT Message-ID: Content-Type: multipart/alternative; boundary="_9267d11c-b9fe-4a28-ae30-3a890d40f6a0_" From: HarryCiao To: CC: , Subject: RE: [refpolicy] My patchset to test "Separating tunables from booleans" Date: Wed, 24 Aug 2011 05:39:48 +0000 In-Reply-To: <4E53AEC0.7040009@tresys.com> References: ,<4E53AEC0.7040009@tresys.com> MIME-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov --_9267d11c-b9fe-4a28-ae30-3a890d40f6a0_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi Chris, > Date: Tue, 23 Aug 2011 09:44:32 -0400 > From: cpebenito@tresys.com > To: harrytaurus2002@hotmail.com > CC: refpolicy@oss1.tresys.com; selinux@tycho.nsa.gov > Subject: Re: [refpolicy] My patchset to test "Separating tunables from booleans" > > On 08/23/11 06:27, HarryCiao wrote: > > This is the refpolicy patchset to test along with new toolchain feature > > of separating tunables from booleans, generally speaking a "tunable" > > keyword is introduced and made use of by tunable_policy(), whereas a new > > boolean_policy() macro would make use of the "bool" keyword. > > > > tunable is indeed a boolean, except that the COND_BOOL_FLAGS_TUNABLE bit > > would be set in the newly added member of flags in the cond_bool_datum_t > > structure. > > > > Once the new toolchain feature is welcomed and merged, we could change > > refpolicy to shrink policy.X size significantly. > > > > Any comments or suggestions as for how to better this new toolchain > > feature are greatly welcomed. > > To make sure I understand correctly, a tunable block will have the same > token in the raw policy as runtime conditional blocks? e.g. > > tunable foo false; > if (foo) { > .... > } > > If tunable blocks use the same token, I think Refpolicy would just drop > the tunable_policy() macro. > The tunable identifier won't be written to policy.X. During link, the logically "true" branch of its if-else branches would be treated as permanent rules and append to the end of decl->avrules list, resulting in expanded and registered into te_avtab hashtab. As for boolean, the identifier would be written to policy.X and both if-else branches would be expanded and registered to te_cond_avtab hashtab, so is the cond_node_t for boolean. Both tunable and boolean identifier would share the same cond_bool_datum_t structure, a flag(COND_BOOL_FLAGS_TUNABLE) has been introduced to differentiate them, which would be set only when the identifier is defined/required by "tunable" keyword. So both "tunable" and "bool" keywords would have to be supported by toolchain, so are tunable_policy() and boolean_policy() macros. > There are no examples of this in Refpolicy, but can you mix Booleans and > tunables in an expression? e.g. > > tunable foo true; > boolean bar true; > if (foo || bar) { > .... > } > > I'd say its not a requirement, I'm just trying to make sure I understand > the features. Yes, there is just one example in refpolicy. As showed in my test results, the pppd_can_ismod identifier is declared by gen_tunable(), however, it is used along with secure_mode_insmod boolean in ppp.te. Such hybird expression is not welcomed I guess, so some warning information would be printed out during link. In my test result, the secure_mode_insmod would be blamed, since it's declared by gen_bool() but used in tunable_policy(), which would require it as a tunable. (That's also why until all p_bools.table from all modules have been copied during link could we finally determine if a cond_bool_datum_t is indeed a boolean or tunable) For such situation since it would be difficult to correctly remove the cond_expr_t for tunables and related operators, I've decided to transform tunable to boolean(just by cleaning the TUNABLE flag bit) then the whole cond_node_t would be treated as normal. Thanks, Harry > > -- > Chris PeBenito > Tresys Technology, LLC > www.tresys.com | oss.tresys.com > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. --_9267d11c-b9fe-4a28-ae30-3a890d40f6a0_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit

Hi Chris,

> Date: Tue, 23 Aug 2011 09:44:32 -0400
> From: cpebenito@tresys.com
> To: harrytaurus2002@hotmail.com
> CC: refpolicy@oss1.tresys.com; selinux@tycho.nsa.gov
> Subject: Re: [refpolicy] My patchset to test "Separating tunables from booleans"
>
> On 08/23/11 06:27, HarryCiao wrote:
> > This is the refpolicy patchset to test along with new toolchain feature
> > of separating tunables from booleans, generally speaking a "tunable"
> > keyword is introduced and made use of by tunable_policy(), whereas a new
> > boolean_policy() macro would make use of the "bool" keyword.
> >
> > tunable is indeed a boolean, except that the COND_BOOL_FLAGS_TUNABLE bit
> > would be set in the newly added member of flags in the cond_bool_datum_t
> > structure.
> >
> > Once the new toolchain feature is welcomed and merged, we could change
> >! ; refpolicy to shrink policy.X size significantly.
> >
> > Any comments or suggestions as for how to better this new toolchain
> > feature are greatly welcomed.
>
> To make sure I understand correctly, a tunable block will have the same
> token in the raw policy as runtime conditional blocks? e.g.
>
> tunable foo false;
> if (foo) {
> ....
> }
>
> If tunable blocks use the same token, I think Refpolicy would just drop
> the tunable_policy() macro.
>

The tunable identifier won't be written to policy.X.

During link, the logically "true" branch of its if-else branches would be treated as permanent rules and append to the end of decl->avrules list, resulting in expanded and registered into te_avtab hashtab.

As for boolean, the identifier would be written to policy.X and both if-else branches would be expanded and registered to te_cond_avtab hashtab, ! so is the cond_node_t for boolean.

Both tunable and boolean ide ntifier would share the same cond_bool_datum_t structure, a flag(COND_BOOL_FLAGS_TUNABLE) has been introduced to differentiate them, which would be set only when the identifier is defined/required by "tunable" keyword.

So both "tunable" and "bool" keywords would have to be supported by toolchain, so are tunable_policy() and boolean_policy() macros.

> There are no examples of this in Refpolicy, but can you mix Booleans and
> tunables in an expression? e.g.
>
> tunable foo true;
> boolean bar true;
> if (foo || bar) {
> ....
> }
>
> I'd say its not a requirement, I'm just trying to make sure I understand
> the features.

Yes, there is just one example in refpolicy. As showed in my test results, the pppd_can_ismod identifier is declared by gen_tunable(), however, it is used along with secure_mode_insmod boolean in ppp.te.

Such hybird expression is not welcomed I guess, so some warnin! g information would be printed out during link. In my test result, the secure_mode_insmod would be blamed, since it's declared by gen_bool() but used in tunable_policy(), which would require it as a tunable. (That's also why until all p_bools.table from all modules have been copied during link could we finally determine if a cond_bool_datum_t is indeed a boolean or tunable)

For such situation since it would be difficult to correctly remove the cond_expr_t for tunables and related operators, I've decided to transform tunable to boolean(just by cleaning the TUNABLE flag bit) then the whole cond_node_t would be treated as normal.

Thanks,
Harry

>
> --
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys.com | oss.tresys.com
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the word! s "unsubscribe selinux" without quotes as the message.

--_9267d11c-b9fe-4a28-ae30-3a890d40f6a0_-- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p7OCNkfB031395 for ; Wed, 24 Aug 2011 08:23:46 -0400 Received: from exchange10.columbia.tresys.com (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p7OCNjet017768 for ; Wed, 24 Aug 2011 12:23:45 GMT Message-ID: <4E54ED50.3060802@tresys.com> Date: Wed, 24 Aug 2011 08:23:44 -0400 From: "Christopher J. PeBenito" MIME-Version: 1.0 To: HarryCiao CC: , Subject: Re: [refpolicy] My patchset to test "Separating tunables from booleans" References: ,<4E53AEC0.7040009@tresys.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On 08/24/11 01:39, HarryCiao wrote: >> Date: Tue, 23 Aug 2011 09:44:32 -0400 >> From: cpebenito@tresys.com >> To: harrytaurus2002@hotmail.com >> CC: refpolicy@oss1.tresys.com; selinux@tycho.nsa.gov >> Subject: Re: [refpolicy] My patchset to test "Separating tunables from > booleans" >> >> On 08/23/11 06:27, HarryCiao wrote: >> > This is the refpolicy patchset to test along with new toolchain feature >> > of separating tunables from booleans, generally speaking a "tunable" >> > keyword is introduced and made use of by tunable_policy(), whereas a new >> > boolean_policy() macro would make use of the "bool" keyword. >> > >> > tunable is indeed a boolean, except that the COND_BOOL_FLAGS_TUNABLE bit >> > would be set in the newly added member of flags in the cond_bool_datum_t >> > structure. >> > >> > Once the new toolchain feature is welcomed and merged, we could change >> > refpolicy to shrink policy.X size significantly. >> > >> > Any comments or suggestions as for how to better this new toolchain >> > feature are greatly welcomed. >> >> To make sure I understand correctly, a tunable block will have the same >> token in the raw policy as runtime conditional blocks? e.g. >> >> tunable foo false; >> if (foo) { >> .... >> } >> >> If tunable blocks use the same token, I think Refpolicy would just drop >> the tunable_policy() macro. >> > > The tunable identifier won't be written to policy.X. > > During link, the logically "true" branch of its if-else branches would > be treated as permanent rules and append to the end of decl->avrules > list, resulting in expanded and registered into te_avtab hashtab. > > As for boolean, the identifier would be written to policy.X and both > if-else branches would be expanded and registered to te_cond_avtab > hashtab, so is the cond_node_t for boolean. > > Both tunable and boolean identifier would share the same > cond_bool_datum_t structure, a flag(COND_BOOL_FLAGS_TUNABLE) has been > introduced to differentiate them, which would be set only when the > identifier is defined/required by "tunable" keyword. > > So both "tunable" and "bool" keywords would have to be supported by > toolchain, so are tunable_policy() and boolean_policy() macros. I don't understand why you say boolean_policy() and tunable_policy() macros are needed. Based on the implementation in your test patch, they are not different in the raw policy. Are you suggesting it for the automatic bool/tunable gen_require block generation? >> There are no examples of this in Refpolicy, but can you mix Booleans and >> tunables in an expression? e.g. >> >> tunable foo true; >> boolean bar true; >> if (foo || bar) { >> .... >> } >> >> I'd say its not a requirement, I'm just trying to make sure I understand >> the features. > > Yes, there is just one example in refpolicy. As showed in my test > results, the pppd_can_ismod identifier is declared by gen_tunable(), > however, it is used along with secure_mode_insmod boolean in ppp.te. > > Such hybird expression is not welcomed I guess, so some warning > information would be printed out during link. In my test result, the > secure_mode_insmod would be blamed, since it's declared by gen_bool() > but used in tunable_policy(), which would require it as a tunable. > (That's also why until all p_bools.table from all modules have been > copied during link could we finally determine if a cond_bool_datum_t is > indeed a boolean or tunable) The reason it has to be like this is because nested conditional policy is not supported. Otherwise it would be written like: tunable_policy(`pppd_can_insmod',` modutils_domtrans_insmod(pppd_t) ') > For such situation since it would be difficult to correctly remove the > cond_expr_t for tunables and related operators, I've decided to > transform tunable to boolean(just by cleaning the TUNABLE flag bit) then > the whole cond_node_t would be treated as normal. I think it would be better to error. Then the user can decided what to do about it. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p7P3ASMl007921 for ; Wed, 24 Aug 2011 23:10:35 -0400 Received: from snt0-omc4-s36.snt0.hotmail.com (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p7P3ASKK004682 for ; Thu, 25 Aug 2011 03:10:28 GMT Message-ID: Content-Type: multipart/alternative; boundary="_ec056b54-73d2-44b4-8e78-2af7f7893058_" From: HarryCiao To: CC: , Subject: RE: [refpolicy] My patchset to test "Separating tunables from booleans" Date: Thu, 25 Aug 2011 03:10:23 +0000 In-Reply-To: <4E54ED50.3060802@tresys.com> References: ,<4E53AEC0.7040009@tresys.com> ,<4E54ED50.3060802@tresys.com> MIME-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov --_ec056b54-73d2-44b4-8e78-2af7f7893058_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi Chris, > Date: Wed, 24 Aug 2011 08:23:44 -0400 > From: cpebenito@tresys.com > To: harrytaurus2002@hotmail.com > CC: refpolicy@oss1.tresys.com; selinux@tycho.nsa.gov > Subject: Re: [refpolicy] My patchset to test "Separating tunables from booleans" > > On 08/24/11 01:39, HarryCiao wrote: > >> Date: Tue, 23 Aug 2011 09:44:32 -0400 > >> From: cpebenito@tresys.com > >> To: harrytaurus2002@hotmail.com > >> CC: refpolicy@oss1.tresys.com; selinux@tycho.nsa.gov > >> Subject: Re: [refpolicy] My patchset to test "Separating tunables from > > booleans" > >> > >> On 08/23/11 06:27, HarryCiao wrote: > >> > This is the refpolicy patchset to test along with new toolchain feature > >> > of separating tunables from booleans, generally speaking a "tunable" > >> > keyword is introduced and made use of by tunable_policy(), whereas a new > >> > boolean_policy() macro would make use of the "bool" keyword. > >> > > >> > tunable is indeed a boolean, except that the COND_BOOL_FLAGS_TUNABLE bit > >> > would be set in the newly added member of flags in the cond_bool_datum_t > >> > structure. > >> > > >> > Once the new toolchain feature is welcomed and merged, we could change > >> > refpolicy to shrink policy.X size significantly. > >> > > >> > Any comments or suggestions as for how to better this new toolchain > >> > feature are greatly welcomed. > >> > >> To make sure I understand correctly, a tunable block will have the same > >> token in the raw policy as runtime conditional blocks? e.g. > >> > >> tunable foo false; > >> if (foo) { > >> .... > >> } > >> > >> If tunable blocks use the same token, I think Refpolicy would just drop > >> the tunable_policy() macro. > >> > > > > The tunable identifier won't be written to policy.X. > > > > During link, the logically "true" branch of its if-else branches would > > be treated as permanent rules and append to the end of decl->avrules > > list, resulting in expanded and registered into te_avtab hashtab. > > > > As for boolean, the identifier would be written to policy.X and both > > if-else branches would be expanded and registered to te_cond_avtab > > hashtab, so is the cond_node_t for boolean. > > > > Both tunable and boolean identifier would share the same > > cond_bool_datum_t structure, a flag(COND_BOOL_FLAGS_TUNABLE) has been > > introduced to differentiate them, which would be set only when the > > identifier is defined/required by "tunable" keyword. > > > > So both "tunable" and "bool" keywords would have to be supported by > > toolchain, so are tunable_policy() and boolean_policy() macros. > > I don't understand why you say boolean_policy() and tunable_policy() > macros are needed. Based on the implementation in your test patch, they > are not different in the raw policy. Are you suggesting it for the > automatic bool/tunable gen_require block generation? > boolean_policy() and tunable_policy() are not for raw policy, their goal is to tell toolchain the difference between a boolean and a tunable, and that's all. Then toolchain would handle boolean and tunable in different manner, for tunable, no identifiers written to policy.X and the logically true branch of its conditional would be expanded to policy.X permanently. In a nutshell, booleans provide the capability to switch on/off blocks of rules at run-time, whereas tunable are more about "once-and-for-all" situations: once the system administrator figures out the desirable branch in a tunable's conditional, he/she could set the tuanble's default value and very likely won't change it much, in such case only the effective branch of a tunable conditional should be written to raw policy. The automatic gen_require block generation is good to have, doesn't it? > >> There are no examples of this in Refpolicy, but can you mix Booleans and > >> tunables in an expression? e.g. > >> > >> tunable foo true; > >> boolean bar true; > >> if (foo || bar) { > >> .... > >> } > >> > >> I'd say its not a requirement, I'm just trying to make sure I understand > >> the features. > > > > Yes, there is just one example in refpolicy. As showed in my test > > results, the pppd_can_ismod identifier is declared by gen_tunable(), > > however, it is used along with secure_mode_insmod boolean in ppp.te. > > > > Such hybird expression is not welcomed I guess, so some warning > > information would be printed out during link. In my test result, the > > secure_mode_insmod would be blamed, since it's declared by gen_bool() > > but used in tunable_policy(), which would require it as a tunable. > > (That's also why until all p_bools.table from all modules have been > > copied during link could we finally determine if a cond_bool_datum_t is > > indeed a boolean or tunable) > > The reason it has to be like this is because nested conditional policy > is not supported. Otherwise it would be written like: > > tunable_policy(`pppd_can_insmod',` > modutils_domtrans_insmod(pppd_t) > ') > > > > For such situation since it would be difficult to correctly remove the > > cond_expr_t for tunables and related operators, I've decided to > > transform tunable to boolean(just by cleaning the TUNABLE flag bit) then > > the whole cond_node_t would be treated as normal. > > I think it would be better to error. Then the user can decided what to > do about it. > I understand this is for working around the need to nest tunable with tunable/boolean. Since pppd_can_insmod has been used with secure_mode_insmod in current refpolicy, error out would break the build, that's why I've chosen to just put some information. BTW, in this situation the toolchain would bump the pppd_can_insmod from tunable to boolean(by clearing it TUNABLE flag), then the policy writer won't even bother to change the declaration of pppd_can_insmod from gen_tunable() to gen_bool(). Thanks, Harry > -- > Chris PeBenito > Tresys Technology, LLC > www.tresys.com | oss.tresys.com > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. --_ec056b54-73d2-44b4-8e78-2af7f7893058_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit

Hi Chris,

> Date: Wed, 24 Aug 2011 08:23:44 -0400
> From: cpebenito@tresys.com
> To: harrytaurus2002@hotmail.com
> CC: refpolicy@oss1.tresys.com; selinux@tycho.nsa.gov
> Subject: Re: [refpolicy] My patchset to test "Separating tunables from booleans"
>
> On 08/24/11 01:39, HarryCiao wrote:
> >> Date: Tue, 23 Aug 2011 09:44:32 -0400
> >> From: cpebenito@tresys.com
> >> To: harrytaurus2002@hotmail.com
> >> CC: refpolicy@oss1.tresys.com; selinux@tycho.nsa.gov
> >> Subject: Re: [refpolicy] My patchset to test "Separating tunables from
> > booleans"
> >>
> >> On 08/23/11 06:27, HarryCiao wrote:
> >> > This is the refpolicy patchset to test along with new toolchain feature
> >> > of separating tunables from booleans, generally speaking a "tunable"
> >> > keyword is introduced and made use of by! tunable_policy(), whereas a new
> >> > boolean_policy() macro would make use of the "bool" keyword.
> >> >
> >> > tunable is indeed a boolean, except that the COND_BOOL_FLAGS_TUNABLE bit
> >> > would be set in the newly added member of flags in the cond_bool_datum_t
> >> > structure.
> >> >
> >> > Once the new toolchain feature is welcomed and merged, we could change
> >> > refpolicy to shrink policy.X size significantly.
> >> >
> >> > Any comments or suggestions as for how to better this new toolchain
> >> > feature are greatly welcomed.
> >>
> >> To make sure I understand correctly, a tunable block will have the same
> >> token in the raw policy as runtime conditional blocks? e.g.
> >>
> >> tunable foo false;
> >> if (foo) {
> >&! gt; ....
> >> }
> >>
> >> If tunab le blocks use the same token, I think Refpolicy would just drop
> >> the tunable_policy() macro.
> >>
> >
> > The tunable identifier won't be written to policy.X.
> >
> > During link, the logically "true" branch of its if-else branches would
> > be treated as permanent rules and append to the end of decl->avrules
> > list, resulting in expanded and registered into te_avtab hashtab.
> >
> > As for boolean, the identifier would be written to policy.X and both
> > if-else branches would be expanded and registered to te_cond_avtab
> > hashtab, so is the cond_node_t for boolean.
> >
> > Both tunable and boolean identifier would share the same
> > cond_bool_datum_t structure, a flag(COND_BOOL_FLAGS_TUNABLE) has been
> > introduced to differentiate them, which would be set only when the
> > identifier is defined/requir! ed by "tunable" keyword.
> >
> > So both "tunable" and "bool" keywords would have to be supported by
> > toolchain, so are tunable_policy() and boolean_policy() macros.
>
> I don't understand why you say boolean_policy() and tunable_policy()
> macros are needed. Based on the implementation in your test patch, they
> are not different in the raw policy. Are you suggesting it for the
> automatic bool/tunable gen_require block generation?
>

boolean_policy() and tunable_policy() are not for raw policy, their goal is to tell toolchain the difference between a boolean and a tunable, and that's all.

Then toolchain would handle boolean and tunable in different manner, for tunable, no identifiers written to policy.X and the logically true branch of its conditional would be expanded to policy.X permanently.

In a nutshell, booleans provide the capability to switch on/off blocks of rules at run-tim! e, whereas tunable are more about "once-and-for-all" situations: once the system administrator figures out the desirable branch in a tunable's conditional, he/she could set the tuanble's default value and very likely won't change it much, in such case only the effective branch of a tunable conditional should be written to raw policy.

The automatic gen_require block generation is good to have, doesn't it?

> >> There are no examples of this in Refpolicy, but can you mix Booleans and
> >> tunables in an expression? e.g.
> >>
> >> tunable foo true;
> >> boolean bar true;
> >> if (foo || bar) {
> >> ....
> >> }
> >>
> >> I'd say its not a requirement, I'm just trying to make sure I understand
> >> the features.
> >
> > Yes, there is just one example in refpolicy. As showed in my test
> > results, the pppd_can_ismod identifier is declared by gen_tunable(),
> > ho! wever, it is used along with secure_mode_insmod boolean in ppp.te.
> >
> > Such hybird expression is not welcomed I guess, so some warning
> > information would be printed out during link. In my test result, the
> > secure_mode_insmod would be blamed, since it's declared by gen_bool()
> > but used in tunable_policy(), which would require it as a tunable.
> > (That's also why until all p_bools.table from all modules have been
> > copied during link could we finally determine if a cond_bool_datum_t is
> > indeed a boolean or tunable)
>
> The reason it has to be like this is because nested conditional policy
> is not supported. Otherwise it would be written like:
>
> tunable_policy(`pppd_can_insmod',`
> modutils_domtrans_insmod(pppd_t)
> ')
>
>
> > For such situation since it would be difficult to correctly remove the
> > cond! _expr_t for tunables and related operators, I've decided to
> &g t; transform tunable to boolean(just by cleaning the TUNABLE flag bit) then
> > the whole cond_node_t would be treated as normal.
>
> I think it would be better to error. Then the user can decided what to
> do about it.
>

I understand this is for working around the need to nest tunable with tunable/boolean.

Since pppd_can_insmod has been used with secure_mode_insmod in current refpolicy, error out would break the build, that's why I've chosen to just put some information. BTW, in this situation the toolchain would bump the pppd_can_insmod from tunable to boolean(by clearing it TUNABLE flag), then the policy writer won't even bother to change the declaration of pppd_can_insmod from gen_tunable() to gen_bool().

Thanks,
Harry

> --
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys.com | oss.tresys.com
>
> --
> This message was distributed to subscribers of the selinux! mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.

--_ec056b54-73d2-44b4-8e78-2af7f7893058_-- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id p7PBGcc5028666 for ; Thu, 25 Aug 2011 07:16:38 -0400 Received: from exchange10.columbia.tresys.com (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p7PBGbUn009419 for ; Thu, 25 Aug 2011 11:16:37 GMT Message-ID: <4E562F14.8020405@tresys.com> Date: Thu, 25 Aug 2011 07:16:36 -0400 From: "Christopher J. PeBenito" MIME-Version: 1.0 To: HarryCiao CC: , Subject: Re: [refpolicy] My patchset to test "Separating tunables from booleans" References: ,<4E53AEC0.7040009@tresys.com> ,<4E54ED50.3060802@tresys.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On 08/24/11 23:10, HarryCiao wrote: > Hi Chris, > >> Date: Wed, 24 Aug 2011 08:23:44 -0400 >> From: cpebenito@tresys.com >> To: harrytaurus2002@hotmail.com >> CC: refpolicy@oss1.tresys.com; selinux@tycho.nsa.gov >> Subject: Re: [refpolicy] My patchset to test "Separating tunables from > booleans" >> >> On 08/24/11 01:39, HarryCiao wrote: >> >> Date: Tue, 23 Aug 2011 09:44:32 -0400 >> >> From: cpebenito@tresys.com >> >> To: harrytaurus2002@hotmail.com >> >> CC: refpolicy@oss1.tresys.com; selinux@tycho.nsa.gov >> >> Subject: Re: [refpolicy] My patchset to test "Separating tunables from >> > booleans" >> >> >> >> On 08/23/11 06:27, HarryCiao wrote: >> >> > This is the refpolicy patchset to test along with new toolchain > feature >> >> > of separating tunables from booleans, generally speaking a "tunable" >> >> > keyword is introduced and made use of by tunable_policy(), > whereas a new >> >> > boolean_policy() macro would make use of the "bool" keyword. >> >> > >> >> > tunable is indeed a boolean, except that the > COND_BOOL_FLAGS_TUNABLE bit >> >> > would be set in the newly added member of flags in the > cond_bool_datum_t >> >> > structure. >> >> > >> >> > Once the new toolchain feature is welcomed and merged, we could > change >> >> > refpolicy to shrink policy.X size significantly. >> >> > >> >> > Any comments or suggestions as for how to better this new toolchain >> >> > feature are greatly welcomed. >> >> >> >> To make sure I understand correctly, a tunable block will have the same >> >> token in the raw policy as runtime conditional blocks? e.g. >> >> >> >> tunable foo false; >> >> if (foo) { >> >> .... >> >> } >> >> >> >> If tunable blocks use the same token, I think Refpolicy would just drop >> >> the tunable_policy() macro. >> >> >> > >> > The tunable identifier won't be written to policy.X. >> > >> > During link, the logically "true" branch of its if-else branches would >> > be treated as permanent rules and append to the end of decl->avrules >> > list, resulting in expanded and registered into te_avtab hashtab. >> > >> > As for boolean, the identifier would be written to policy.X and both >> > if-else branches would be expanded and registered to te_cond_avtab >> > hashtab, so is the cond_node_t for boolean. >> > >> > Both tunable and boolean identifier would share the same >> > cond_bool_datum_t structure, a flag(COND_BOOL_FLAGS_TUNABLE) has been >> > introduced to differentiate them, which wo uld be set only when the >> > identifier is defined/required by "tunable" keyword. >> > >> > So both "tunable" and "bool" keywords would have to be supported by >> > toolchain, so are tunable_policy() and boolean_policy() macros. >> >> I don't understand why you say boolean_policy() and tunable_policy() >> macros are needed. Based on the implementation in your test patch, they >> are not different in the raw policy. Are you suggesting it for the >> automatic bool/tunable gen_require block generation? >> > > boolean_policy() and tunable_policy() are not for raw policy, their goal > is to tell toolchain the difference between a boolean and a tunable, and > that's all. Yes I know that. Please give an example of declaring a tunable and making a tunable block, in the raw policy. >> >> There are no examples of this in Refpolicy, but can you mix > Booleans and >> >> tunables in an expression? e.g. >> >> >> >> tunable foo true; >> >> boolean bar true; >> >> if (foo || bar) { >> >> .... >> >> } >> >> >> >> I'd say its not a requirement, I'm just trying to make sure I > understand >> >> the features. >> > >> > Yes, there is just one example in refpolicy. As showed in my test >> > results, the pppd_can_ismod identifier is declared by gen_tunable(), >> > however, it is used along with secure_mode_insmod boolean in ppp.te. >> > >> > Such hybird expression is not welcomed I guess, so some warning >> > information would be printed out during link. In my test result, the >> > secure_mode_insmod would be blamed, since it's declared by gen_bool() >> > but used in tunable_policy(), which would require it as a tunable. >> > (That's also why until all p_bools.table from all modules have been >> > copied during link could we finally determine if a cond_bool_datum_t is >> > indeed a boolean or tunable) >> >> The reason it has to be like this is because nested conditional policy >> is not supported. Otherwise it would be written like: >> >> tunable_policy(`pppd_can_insmod',` >> modutils_domtrans_insmod(pppd_t)*> ') >> >> >> > For such situation since it would be difficult to correctly remove the >> > cond_expr_t for tunables and related operators, I've decided to >> > transform tunable to boolean(just by cleaning the TUNABLE flag bit) then >> > the whole cond_node_t would be treated as normal. >> >> I think it would be better to error. Then the user can decided what to >> do about it. >> > > I understand this is for working around the need to nest tunable with > tunable/boolean. > > Since pppd_can_insmod has been used with secure_mode_insmod in current > refpolicy, error out would break the build, that's why I've chosen to > just put some information. BTW, in this situation the toolchain would > bump the pppd_can_insmod from tunable to boolean(by clearing it TUNABLE > flag), then the policy writer won't even bother to change the > declaration of pppd_can_insmod from gen_tunable() to gen_bool(). I still want this to error out. I'll fix the policy. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 From: harrytaurus2002@hotmail.com (HarryCiao) Date: Tue, 23 Aug 2011 10:27:36 +0000 Subject: [refpolicy] My patchset to test "Separating tunables from booleans" Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hi, This is the refpolicy patchset to test along with new toolchain feature of separating tunables from booleans, generally speaking a "tunable" keyword is introduced and made use of by tunable_policy(), whereas a new boolean_policy() macro would make use of the "bool" keyword. tunable is indeed a boolean, except that the COND_BOOL_FLAGS_TUNABLE bit would be set in the newly added member of flags in the cond_bool_datum_t structure. Once the new toolchain feature is welcomed and merged, we could change refpolicy to shrink policy.X size significantly. Any comments or suggestions as for how to better this new toolchain feature are greatly welcomed. Thanks! Harry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110823/b8ea915e/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-the-definition-of-the-boolean_policy-marcro.patch Type: text/x-patch Size: 2257 bytes Desc: not available Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110823/b8ea915e/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-user_ping-is-a-tunable-use-tunable_policy-for-it.patch Type: text/x-patch Size: 1315 bytes Desc: not available Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110823/b8ea915e/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-mmap_low_allowed-is-a-tunable-use-tunable_policy-for.patch Type: text/x-patch Size: 1049 bytes Desc: not available Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110823/b8ea915e/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-secure_mode_insmod-is-a-boolean-use-boolean_policy-f.patch Type: text/x-patch Size: 1704 bytes Desc: not available Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110823/b8ea915e/attachment-0003.bin From mboxrd@z Thu Jan 1 00:00:00 1970 From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Tue, 23 Aug 2011 09:44:32 -0400 Subject: [refpolicy] My patchset to test "Separating tunables from booleans" In-Reply-To: References: Message-ID: <4E53AEC0.7040009@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/23/11 06:27, HarryCiao wrote: > This is the refpolicy patchset to test along with new toolchain feature > of separating tunables from booleans, generally speaking a "tunable" > keyword is introduced and made use of by tunable_policy(), whereas a new > boolean_policy() macro would make use of the "bool" keyword. > > tunable is indeed a boolean, except that the COND_BOOL_FLAGS_TUNABLE bit > would be set in the newly added member of flags in the cond_bool_datum_t > structure. > > Once the new toolchain feature is welcomed and merged, we could change > refpolicy to shrink policy.X size significantly. > > Any comments or suggestions as for how to better this new toolchain > feature are greatly welcomed. To make sure I understand correctly, a tunable block will have the same token in the raw policy as runtime conditional blocks? e.g. tunable foo false; if (foo) { .... } If tunable blocks use the same token, I think Refpolicy would just drop the tunable_policy() macro. There are no examples of this in Refpolicy, but can you mix Booleans and tunables in an expression? e.g. tunable foo true; boolean bar true; if (foo || bar) { .... } I'd say its not a requirement, I'm just trying to make sure I understand the features. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: harrytaurus2002@hotmail.com (HarryCiao) Date: Wed, 24 Aug 2011 05:39:48 +0000 Subject: [refpolicy] My patchset to test "Separating tunables from booleans" In-Reply-To: <4E53AEC0.7040009@tresys.com> References: , <4E53AEC0.7040009@tresys.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hi Chris, > Date: Tue, 23 Aug 2011 09:44:32 -0400 > From: cpebenito at tresys.com > To: harrytaurus2002 at hotmail.com > CC: refpolicy at oss1.tresys.com; selinux at tycho.nsa.gov > Subject: Re: [refpolicy] My patchset to test "Separating tunables from booleans" > > On 08/23/11 06:27, HarryCiao wrote: > > This is the refpolicy patchset to test along with new toolchain feature > > of separating tunables from booleans, generally speaking a "tunable" > > keyword is introduced and made use of by tunable_policy(), whereas a new > > boolean_policy() macro would make use of the "bool" keyword. > > > > tunable is indeed a boolean, except that the COND_BOOL_FLAGS_TUNABLE bit > > would be set in the newly added member of flags in the cond_bool_datum_t > > structure. > > > > Once the new toolchain feature is welcomed and merged, we could change > > refpolicy to shrink policy.X size significantly. > > > > Any comments or suggestions as for how to better this new toolchain > > feature are greatly welcomed. > > To make sure I understand correctly, a tunable block will have the same > token in the raw policy as runtime conditional blocks? e.g. > > tunable foo false; > if (foo) { > .... > } > > If tunable blocks use the same token, I think Refpolicy would just drop > the tunable_policy() macro. > The tunable identifier won't be written to policy.X. During link, the logically "true" branch of its if-else branches would be treated as permanent rules and append to the end of decl->avrules list, resulting in expanded and registered into te_avtab hashtab. As for boolean, the identifier would be written to policy.X and both if-else branches would be expanded and registered to te_cond_avtab hashtab, so is the cond_node_t for boolean. Both tunable and boolean identifier would share the same cond_bool_datum_t structure, a flag(COND_BOOL_FLAGS_TUNABLE) has been introduced to differentiate them, which would be set only when the identifier is defined/required by "tunable" keyword. So both "tunable" and "bool" keywords would have to be supported by toolchain, so are tunable_policy() and boolean_policy() macros. > There are no examples of this in Refpolicy, but can you mix Booleans and > tunables in an expression? e.g. > > tunable foo true; > boolean bar true; > if (foo || bar) { > .... > } > > I'd say its not a requirement, I'm just trying to make sure I understand > the features. Yes, there is just one example in refpolicy. As showed in my test results, the pppd_can_ismod identifier is declared by gen_tunable(), however, it is used along with secure_mode_insmod boolean in ppp.te. Such hybird expression is not welcomed I guess, so some warning information would be printed out during link. In my test result, the secure_mode_insmod would be blamed, since it's declared by gen_bool() but used in tunable_policy(), which would require it as a tunable. (That's also why until all p_bools.table from all modules have been copied during link could we finally determine if a cond_bool_datum_t is indeed a boolean or tunable) For such situation since it would be difficult to correctly remove the cond_expr_t for tunables and related operators, I've decided to transform tunable to boolean(just by cleaning the TUNABLE flag bit) then the whole cond_node_t would be treated as normal. Thanks, Harry > > -- > Chris PeBenito > Tresys Technology, LLC > www.tresys.com | oss.tresys.com > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo at tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110824/58dca7ea/attachment.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Wed, 24 Aug 2011 08:23:44 -0400 Subject: [refpolicy] My patchset to test "Separating tunables from booleans" In-Reply-To: References: , <4E53AEC0.7040009@tresys.com> Message-ID: <4E54ED50.3060802@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/24/11 01:39, HarryCiao wrote: >> Date: Tue, 23 Aug 2011 09:44:32 -0400 >> From: cpebenito at tresys.com >> To: harrytaurus2002 at hotmail.com >> CC: refpolicy at oss1.tresys.com; selinux at tycho.nsa.gov >> Subject: Re: [refpolicy] My patchset to test "Separating tunables from > booleans" >> >> On 08/23/11 06:27, HarryCiao wrote: >> > This is the refpolicy patchset to test along with new toolchain feature >> > of separating tunables from booleans, generally speaking a "tunable" >> > keyword is introduced and made use of by tunable_policy(), whereas a new >> > boolean_policy() macro would make use of the "bool" keyword. >> > >> > tunable is indeed a boolean, except that the COND_BOOL_FLAGS_TUNABLE bit >> > would be set in the newly added member of flags in the cond_bool_datum_t >> > structure. >> > >> > Once the new toolchain feature is welcomed and merged, we could change >> > refpolicy to shrink policy.X size significantly. >> > >> > Any comments or suggestions as for how to better this new toolchain >> > feature are greatly welcomed. >> >> To make sure I understand correctly, a tunable block will have the same >> token in the raw policy as runtime conditional blocks? e.g. >> >> tunable foo false; >> if (foo) { >> .... >> } >> >> If tunable blocks use the same token, I think Refpolicy would just drop >> the tunable_policy() macro. >> > > The tunable identifier won't be written to policy.X. > > During link, the logically "true" branch of its if-else branches would > be treated as permanent rules and append to the end of decl->avrules > list, resulting in expanded and registered into te_avtab hashtab. > > As for boolean, the identifier would be written to policy.X and both > if-else branches would be expanded and registered to te_cond_avtab > hashtab, so is the cond_node_t for boolean. > > Both tunable and boolean identifier would share the same > cond_bool_datum_t structure, a flag(COND_BOOL_FLAGS_TUNABLE) has been > introduced to differentiate them, which would be set only when the > identifier is defined/required by "tunable" keyword. > > So both "tunable" and "bool" keywords would have to be supported by > toolchain, so are tunable_policy() and boolean_policy() macros. I don't understand why you say boolean_policy() and tunable_policy() macros are needed. Based on the implementation in your test patch, they are not different in the raw policy. Are you suggesting it for the automatic bool/tunable gen_require block generation? >> There are no examples of this in Refpolicy, but can you mix Booleans and >> tunables in an expression? e.g. >> >> tunable foo true; >> boolean bar true; >> if (foo || bar) { >> .... >> } >> >> I'd say its not a requirement, I'm just trying to make sure I understand >> the features. > > Yes, there is just one example in refpolicy. As showed in my test > results, the pppd_can_ismod identifier is declared by gen_tunable(), > however, it is used along with secure_mode_insmod boolean in ppp.te. > > Such hybird expression is not welcomed I guess, so some warning > information would be printed out during link. In my test result, the > secure_mode_insmod would be blamed, since it's declared by gen_bool() > but used in tunable_policy(), which would require it as a tunable. > (That's also why until all p_bools.table from all modules have been > copied during link could we finally determine if a cond_bool_datum_t is > indeed a boolean or tunable) The reason it has to be like this is because nested conditional policy is not supported. Otherwise it would be written like: tunable_policy(`pppd_can_insmod',` modutils_domtrans_insmod(pppd_t) ') > For such situation since it would be difficult to correctly remove the > cond_expr_t for tunables and related operators, I've decided to > transform tunable to boolean(just by cleaning the TUNABLE flag bit) then > the whole cond_node_t would be treated as normal. I think it would be better to error. Then the user can decided what to do about it. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: harrytaurus2002@hotmail.com (HarryCiao) Date: Thu, 25 Aug 2011 03:10:23 +0000 Subject: [refpolicy] My patchset to test "Separating tunables from booleans" In-Reply-To: <4E54ED50.3060802@tresys.com> References: , <4E53AEC0.7040009@tresys.com> , <4E54ED50.3060802@tresys.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hi Chris, > Date: Wed, 24 Aug 2011 08:23:44 -0400 > From: cpebenito at tresys.com > To: harrytaurus2002 at hotmail.com > CC: refpolicy at oss1.tresys.com; selinux at tycho.nsa.gov > Subject: Re: [refpolicy] My patchset to test "Separating tunables from booleans" > > On 08/24/11 01:39, HarryCiao wrote: > >> Date: Tue, 23 Aug 2011 09:44:32 -0400 > >> From: cpebenito at tresys.com > >> To: harrytaurus2002 at hotmail.com > >> CC: refpolicy at oss1.tresys.com; selinux at tycho.nsa.gov > >> Subject: Re: [refpolicy] My patchset to test "Separating tunables from > > booleans" > >> > >> On 08/23/11 06:27, HarryCiao wrote: > >> > This is the refpolicy patchset to test along with new toolchain feature > >> > of separating tunables from booleans, generally speaking a "tunable" > >> > keyword is introduced and made use of by tunable_policy(), whereas a new > >> > boolean_policy() macro would make use of the "bool" keyword. > >> > > >> > tunable is indeed a boolean, except that the COND_BOOL_FLAGS_TUNABLE bit > >> > would be set in the newly added member of flags in the cond_bool_datum_t > >> > structure. > >> > > >> > Once the new toolchain feature is welcomed and merged, we could change > >> > refpolicy to shrink policy.X size significantly. > >> > > >> > Any comments or suggestions as for how to better this new toolchain > >> > feature are greatly welcomed. > >> > >> To make sure I understand correctly, a tunable block will have the same > >> token in the raw policy as runtime conditional blocks? e.g. > >> > >> tunable foo false; > >> if (foo) { > >> .... > >> } > >> > >> If tunable blocks use the same token, I think Refpolicy would just drop > >> the tunable_policy() macro. > >> > > > > The tunable identifier won't be written to policy.X. > > > > During link, the logically "true" branch of its if-else branches would > > be treated as permanent rules and append to the end of decl->avrules > > list, resulting in expanded and registered into te_avtab hashtab. > > > > As for boolean, the identifier would be written to policy.X and both > > if-else branches would be expanded and registered to te_cond_avtab > > hashtab, so is the cond_node_t for boolean. > > > > Both tunable and boolean identifier would share the same > > cond_bool_datum_t structure, a flag(COND_BOOL_FLAGS_TUNABLE) has been > > introduced to differentiate them, which would be set only when the > > identifier is defined/required by "tunable" keyword. > > > > So both "tunable" and "bool" keywords would have to be supported by > > toolchain, so are tunable_policy() and boolean_policy() macros. > > I don't understand why you say boolean_policy() and tunable_policy() > macros are needed. Based on the implementation in your test patch, they > are not different in the raw policy. Are you suggesting it for the > automatic bool/tunable gen_require block generation? > boolean_policy() and tunable_policy() are not for raw policy, their goal is to tell toolchain the difference between a boolean and a tunable, and that's all. Then toolchain would handle boolean and tunable in different manner, for tunable, no identifiers written to policy.X and the logically true branch of its conditional would be expanded to policy.X permanently. In a nutshell, booleans provide the capability to switch on/off blocks of rules at run-time, whereas tunable are more about "once-and-for-all" situations: once the system administrator figures out the desirable branch in a tunable's conditional, he/she could set the tuanble's default value and very likely won't change it much, in such case only the effective branch of a tunable conditional should be written to raw policy. The automatic gen_require block generation is good to have, doesn't it? > >> There are no examples of this in Refpolicy, but can you mix Booleans and > >> tunables in an expression? e.g. > >> > >> tunable foo true; > >> boolean bar true; > >> if (foo || bar) { > >> .... > >> } > >> > >> I'd say its not a requirement, I'm just trying to make sure I understand > >> the features. > > > > Yes, there is just one example in refpolicy. As showed in my test > > results, the pppd_can_ismod identifier is declared by gen_tunable(), > > however, it is used along with secure_mode_insmod boolean in ppp.te. > > > > Such hybird expression is not welcomed I guess, so some warning > > information would be printed out during link. In my test result, the > > secure_mode_insmod would be blamed, since it's declared by gen_bool() > > but used in tunable_policy(), which would require it as a tunable. > > (That's also why until all p_bools.table from all modules have been > > copied during link could we finally determine if a cond_bool_datum_t is > > indeed a boolean or tunable) > > The reason it has to be like this is because nested conditional policy > is not supported. Otherwise it would be written like: > > tunable_policy(`pppd_can_insmod',` > modutils_domtrans_insmod(pppd_t) > ') > > > > For such situation since it would be difficult to correctly remove the > > cond_expr_t for tunables and related operators, I've decided to > > transform tunable to boolean(just by cleaning the TUNABLE flag bit) then > > the whole cond_node_t would be treated as normal. > > I think it would be better to error. Then the user can decided what to > do about it. > I understand this is for working around the need to nest tunable with tunable/boolean. Since pppd_can_insmod has been used with secure_mode_insmod in current refpolicy, error out would break the build, that's why I've chosen to just put some information. BTW, in this situation the toolchain would bump the pppd_can_insmod from tunable to boolean(by clearing it TUNABLE flag), then the policy writer won't even bother to change the declaration of pppd_can_insmod from gen_tunable() to gen_bool(). Thanks, Harry > -- > Chris PeBenito > Tresys Technology, LLC > www.tresys.com | oss.tresys.com > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo at tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110825/80f9e295/attachment.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Thu, 25 Aug 2011 07:16:36 -0400 Subject: [refpolicy] My patchset to test "Separating tunables from booleans" In-Reply-To: References: , <4E53AEC0.7040009@tresys.com> , <4E54ED50.3060802@tresys.com> Message-ID: <4E562F14.8020405@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/24/11 23:10, HarryCiao wrote: > Hi Chris, > >> Date: Wed, 24 Aug 2011 08:23:44 -0400 >> From: cpebenito at tresys.com >> To: harrytaurus2002 at hotmail.com >> CC: refpolicy at oss1.tresys.com; selinux at tycho.nsa.gov >> Subject: Re: [refpolicy] My patchset to test "Separating tunables from > booleans" >> >> On 08/24/11 01:39, HarryCiao wrote: >> >> Date: Tue, 23 Aug 2011 09:44:32 -0400 >> >> From: cpebenito at tresys.com >> >> To: harrytaurus2002 at hotmail.com >> >> CC: refpolicy at oss1.tresys.com; selinux at tycho.nsa.gov >> >> Subject: Re: [refpolicy] My patchset to test "Separating tunables from >> > booleans" >> >> >> >> On 08/23/11 06:27, HarryCiao wrote: >> >> > This is the refpolicy patchset to test along with new toolchain > feature >> >> > of separating tunables from booleans, generally speaking a "tunable" >> >> > keyword is introduced and made use of by tunable_policy(), > whereas a new >> >> > boolean_policy() macro would make use of the "bool" keyword. >> >> > >> >> > tunable is indeed a boolean, except that the > COND_BOOL_FLAGS_TUNABLE bit >> >> > would be set in the newly added member of flags in the > cond_bool_datum_t >> >> > structure. >> >> > >> >> > Once the new toolchain feature is welcomed and merged, we could > change >> >> > refpolicy to shrink policy.X size significantly. >> >> > >> >> > Any comments or suggestions as for how to better this new toolchain >> >> > feature are greatly welcomed. >> >> >> >> To make sure I understand correctly, a tunable block will have the same >> >> token in the raw policy as runtime conditional blocks? e.g. >> >> >> >> tunable foo false; >> >> if (foo) { >> >> .... >> >> } >> >> >> >> If tunable blocks use the same token, I think Refpolicy would just drop >> >> the tunable_policy() macro. >> >> >> > >> > The tunable identifier won't be written to policy.X. >> > >> > During link, the logically "true" branch of its if-else branches would >> > be treated as permanent rules and append to the end of decl->avrules >> > list, resulting in expanded and registered into te_avtab hashtab. >> > >> > As for boolean, the identifier would be written to policy.X and both >> > if-else branches would be expanded and registered to te_cond_avtab >> > hashtab, so is the cond_node_t for boolean. >> > >> > Both tunable and boolean identifier would share the same >> > cond_bool_datum_t structure, a flag(COND_BOOL_FLAGS_TUNABLE) has been >> > introduced to differentiate them, which wo uld be set only when the >> > identifier is defined/required by "tunable" keyword. >> > >> > So both "tunable" and "bool" keywords would have to be supported by >> > toolchain, so are tunable_policy() and boolean_policy() macros. >> >> I don't understand why you say boolean_policy() and tunable_policy() >> macros are needed. Based on the implementation in your test patch, they >> are not different in the raw policy. Are you suggesting it for the >> automatic bool/tunable gen_require block generation? >> > > boolean_policy() and tunable_policy() are not for raw policy, their goal > is to tell toolchain the difference between a boolean and a tunable, and > that's all. Yes I know that. Please give an example of declaring a tunable and making a tunable block, in the raw policy. >> >> There are no examples of this in Refpolicy, but can you mix > Booleans and >> >> tunables in an expression? e.g. >> >> >> >> tunable foo true; >> >> boolean bar true; >> >> if (foo || bar) { >> >> .... >> >> } >> >> >> >> I'd say its not a requirement, I'm just trying to make sure I > understand >> >> the features. >> > >> > Yes, there is just one example in refpolicy. As showed in my test >> > results, the pppd_can_ismod identifier is declared by gen_tunable(), >> > however, it is used along with secure_mode_insmod boolean in ppp.te. >> > >> > Such hybird expression is not welcomed I guess, so some warning >> > information would be printed out during link. In my test result, the >> > secure_mode_insmod would be blamed, since it's declared by gen_bool() >> > but used in tunable_policy(), which would require it as a tunable. >> > (That's also why until all p_bools.table from all modules have been >> > copied during link could we finally determine if a cond_bool_datum_t is >> > indeed a boolean or tunable) >> >> The reason it has to be like this is because nested conditional policy >> is not supported. Otherwise it would be written like: >> >> tunable_policy(`pppd_can_insmod',` >> modutils_domtrans_insmod(pppd_t)*> ') >> >> >> > For such situation since it would be difficult to correctly remove the >> > cond_expr_t for tunables and related operators, I've decided to >> > transform tunable to boolean(just by cleaning the TUNABLE flag bit) then >> > the whole cond_node_t would be treated as normal. >> >> I think it would be better to error. Then the user can decided what to >> do about it. >> > > I understand this is for working around the need to nest tunable with > tunable/boolean. > > Since pppd_can_insmod has been used with secure_mode_insmod in current > refpolicy, error out would break the build, that's why I've chosen to > just put some information. BTW, in this situation the toolchain would > bump the pppd_can_insmod from tunable to boolean(by clearing it TUNABLE > flag), then the policy writer won't even bother to change the > declaration of pppd_can_insmod from gen_tunable() to gen_bool(). I still want this to error out. I'll fix the policy. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com