* On Fedora 24 I am seeing something strange with CIL
@ 2016-03-29 14:53 Daniel J Walsh
2016-03-29 18:00 ` Daniel J Walsh
0 siblings, 1 reply; 8+ messages in thread
From: Daniel J Walsh @ 2016-03-29 14:53 UTC (permalink / raw)
To: SELinux
When I compile and install this policy
---------------------------------------------------------------
# cat /tmp/container.te
policy_module(container, 1.0)
virt_sandbox_domain_template(container)
----------------------------------------------------------------
I end up with mknod capability.
sesearch -A -s container_t -t container_t -c capability
Found 1 semantic av rules:
allow container_t container_t : capability mknod ;
But I didn't add mknod to the policy.
grep mknod tmp/container.tmp
class capability { chown dac_override dac_read_search fowner fsetid
kill setgid setuid setpcap linux_immutable net_bind_service
net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio
sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource
sys_time sys_tty_config mknod lease audit_write audit_control setfcap };
Any ideas?
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: On Fedora 24 I am seeing something strange with CIL 2016-03-29 14:53 On Fedora 24 I am seeing something strange with CIL Daniel J Walsh @ 2016-03-29 18:00 ` Daniel J Walsh 2016-04-04 19:15 ` Dominick Grift 0 siblings, 1 reply; 8+ messages in thread From: Daniel J Walsh @ 2016-03-29 18:00 UTC (permalink / raw) To: SELinux, James Carter I investigated this a little further. If I write a policy file like =============================================== policy_module(container, 1.0) gen_require(` attribute svirt_sandbox_domain; ') type foobar_t; domain_type(foobar_t) typeattribute foobar_t svirt_sandbox_domain; =============================================== I get sesearch -A -s foobar_t | grep capa allow foobar_t foobar_t : capability mknod ; If I remove the typeattribute line foobar_t no longer has mknod. I think this is a compiler problem. On 03/29/2016 10:53 AM, Daniel J Walsh wrote: > When I compile and install this policy > > --------------------------------------------------------------- > # cat /tmp/container.te > policy_module(container, 1.0) > > virt_sandbox_domain_template(container) > > ---------------------------------------------------------------- > I end up with mknod capability. > > sesearch -A -s container_t -t container_t -c capability > Found 1 semantic av rules: > allow container_t container_t : capability mknod ; > > But I didn't add mknod to the policy. > > grep mknod tmp/container.tmp > class capability { chown dac_override dac_read_search fowner > fsetid kill setgid setuid setpcap linux_immutable net_bind_service > net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module > sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice > sys_resource sys_time sys_tty_config mknod lease audit_write > audit_control setfcap }; > > Any ideas? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On Fedora 24 I am seeing something strange with CIL 2016-03-29 18:00 ` Daniel J Walsh @ 2016-04-04 19:15 ` Dominick Grift 2016-04-04 19:46 ` Daniel J Walsh 0 siblings, 1 reply; 8+ messages in thread From: Dominick Grift @ 2016-04-04 19:15 UTC (permalink / raw) To: selinux -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/29/2016 08:00 PM, Daniel J Walsh wrote: > I investigated this a little further. > manage_chr_files_pattern(svirt_sandbox_domain, svirt_sandbox_file_t, svirt_sandbox_file_t) define(`manage_chr_files_pattern',` allow $1 self:capability mknod; allow $1 $2:dir rw_dir_perms; allow $1 $3:chr_file manage_chr_file_perms; ') > If I write a policy file like > > =============================================== > policy_module(container, 1.0) gen_require(` attribute > svirt_sandbox_domain; ') > > type foobar_t; domain_type(foobar_t) typeattribute foobar_t > svirt_sandbox_domain; > =============================================== > > I get > > > sesearch -A -s foobar_t | grep capa allow foobar_t foobar_t : > capability mknod ; > > If I remove the typeattribute line foobar_t no longer has mknod. > > I think this is a compiler problem. > > On 03/29/2016 10:53 AM, Daniel J Walsh wrote: >> When I compile and install this policy >> >> --------------------------------------------------------------- # >> cat /tmp/container.te policy_module(container, 1.0) >> >> virt_sandbox_domain_template(container) >> >> ---------------------------------------------------------------- >> I end up with mknod capability. >> >> sesearch -A -s container_t -t container_t -c capability Found 1 >> semantic av rules: allow container_t container_t : capability >> mknod ; >> >> But I didn't add mknod to the policy. >> >> grep mknod tmp/container.tmp class capability { chown >> dac_override dac_read_search fowner fsetid kill setgid setuid >> setpcap linux_immutable net_bind_service net_broadcast net_admin >> net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot >> sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource >> sys_time sys_tty_config mknod lease audit_write audit_control >> setfcap }; >> >> Any ideas? > > _______________________________________________ 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 iQGcBAEBCAAGBQJXAr1YAAoJECV0jlU3+Udp15kL/igUkHF8kUkSzGaEVnFbArtR l63tgknNlnzoRF+s0bjSFYuYBRTefQpa/G23j/sIEQmKvVkRz8DlGQERqtSpPLZ2 sRNRlA3UA3vLqhk+RhGwxoEjdm8/MA/weU9VGhSHWsd0XrhYtOnI3metotgm422Q YuQEtib+YQ/ldnEZ/2987DJy6Pg3leOBMn1JE+e7v3mFZDyzEfYI6IGR6VR+WEau MooO6slYI7ftac4YnqzvUdTeANhYG4h2wfNA0qVxNVty4jS4mT3uCOhu/UmssnX/ fMviLYA2YJAkg0g6rvUnJJqFe0uCHMiVsMDwmR03I324BakxWCDpqnRhj5vxmYfx ZW8gh3Xg+ZPyVoC5njgm9KkD0/6pgzwGEB3ayBIVgIVi8sVsNvzhJM2dILphT46K OhFcSWX98xQY4G5P3/vOXx86nN4leP+Uw25eyZbStOFNscBK2LnZArQq65y4i6he Qqv4V6xwCBRT+3u8VbjtgGzByeKEvkWvk7GMC17tgA== =28BA -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On Fedora 24 I am seeing something strange with CIL 2016-04-04 19:15 ` Dominick Grift @ 2016-04-04 19:46 ` Daniel J Walsh 2016-04-04 19:51 ` Dominick Grift 0 siblings, 1 reply; 8+ messages in thread From: Daniel J Walsh @ 2016-04-04 19:46 UTC (permalink / raw) To: Dominick Grift, selinux On 04/04/2016 03:15 PM, Dominick Grift wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 03/29/2016 08:00 PM, Daniel J Walsh wrote: >> I investigated this a little further. >> > manage_chr_files_pattern(svirt_sandbox_domain, svirt_sandbox_file_t, > svirt_sandbox_file_t) > > define(`manage_chr_files_pattern',` > allow $1 self:capability mknod; > allow $1 $2:dir rw_dir_perms; > allow $1 $3:chr_file manage_chr_file_perms; > ') > Ok Makes sense but why didn't this come up with the svirt_sandbox_domain attribute as opposed to container_t? Maybe this is a change in cil. I guess I should not make this the default for svirt_sandbox_domain, and only add it for specific domains. Thanks Dominick. > > > >> If I write a policy file like >> >> =============================================== >> policy_module(container, 1.0) gen_require(` attribute >> svirt_sandbox_domain; ') >> >> type foobar_t; domain_type(foobar_t) typeattribute foobar_t >> svirt_sandbox_domain; >> =============================================== >> >> I get >> >> >> sesearch -A -s foobar_t | grep capa allow foobar_t foobar_t : >> capability mknod ; >> >> If I remove the typeattribute line foobar_t no longer has mknod. >> >> I think this is a compiler problem. >> >> On 03/29/2016 10:53 AM, Daniel J Walsh wrote: >>> When I compile and install this policy >>> >>> --------------------------------------------------------------- # >>> cat /tmp/container.te policy_module(container, 1.0) >>> >>> virt_sandbox_domain_template(container) >>> >>> ---------------------------------------------------------------- >>> I end up with mknod capability. >>> >>> sesearch -A -s container_t -t container_t -c capability Found 1 >>> semantic av rules: allow container_t container_t : capability >>> mknod ; >>> >>> But I didn't add mknod to the policy. >>> >>> grep mknod tmp/container.tmp class capability { chown >>> dac_override dac_read_search fowner fsetid kill setgid setuid >>> setpcap linux_immutable net_bind_service net_broadcast net_admin >>> net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot >>> sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource >>> sys_time sys_tty_config mknod lease audit_write audit_control >>> setfcap }; >>> >>> Any ideas? >> _______________________________________________ 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 > > iQGcBAEBCAAGBQJXAr1YAAoJECV0jlU3+Udp15kL/igUkHF8kUkSzGaEVnFbArtR > l63tgknNlnzoRF+s0bjSFYuYBRTefQpa/G23j/sIEQmKvVkRz8DlGQERqtSpPLZ2 > sRNRlA3UA3vLqhk+RhGwxoEjdm8/MA/weU9VGhSHWsd0XrhYtOnI3metotgm422Q > YuQEtib+YQ/ldnEZ/2987DJy6Pg3leOBMn1JE+e7v3mFZDyzEfYI6IGR6VR+WEau > MooO6slYI7ftac4YnqzvUdTeANhYG4h2wfNA0qVxNVty4jS4mT3uCOhu/UmssnX/ > fMviLYA2YJAkg0g6rvUnJJqFe0uCHMiVsMDwmR03I324BakxWCDpqnRhj5vxmYfx > ZW8gh3Xg+ZPyVoC5njgm9KkD0/6pgzwGEB3ayBIVgIVi8sVsNvzhJM2dILphT46K > OhFcSWX98xQY4G5P3/vOXx86nN4leP+Uw25eyZbStOFNscBK2LnZArQq65y4i6he > Qqv4V6xwCBRT+3u8VbjtgGzByeKEvkWvk7GMC17tgA== > =28BA > -----END PGP SIGNATURE----- > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On Fedora 24 I am seeing something strange with CIL 2016-04-04 19:46 ` Daniel J Walsh @ 2016-04-04 19:51 ` Dominick Grift 2016-04-04 20:32 ` Steve Lawrence 0 siblings, 1 reply; 8+ messages in thread From: Dominick Grift @ 2016-04-04 19:51 UTC (permalink / raw) To: Daniel J Walsh, selinux -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/04/2016 09:46 PM, Daniel J Walsh wrote: > > > On 04/04/2016 03:15 PM, Dominick Grift wrote: On 03/29/2016 08:00 > PM, Daniel J Walsh wrote: >>>> I investigated this a little further. >>>> > manage_chr_files_pattern(svirt_sandbox_domain, > svirt_sandbox_file_t, svirt_sandbox_file_t) > > define(`manage_chr_files_pattern',` allow $1 self:capability > mknod; allow $1 $2:dir rw_dir_perms; allow $1 $3:chr_file > manage_chr_file_perms; ') > >> Ok Makes sense but why didn't this come up with the >> svirt_sandbox_domain attribute as opposed to container_t? Maybe >> this is a change in cil. > >> I guess I should not make this the default for >> svirt_sandbox_domain, and only add it for specific domains. > >> Thanks Dominick. Yes that may indeed well be a CIL thing. CIL does optimization, and this may make policy analysis a bit different. So yes, be careful when using type attributes to query the policy. Because CIL may have "moved rules around" for the sake of efficiency. Best to alway's, atleast also check the rules associated with the type. > > > >>>> If I write a policy file like >>>> >>>> =============================================== >>>> policy_module(container, 1.0) gen_require(` attribute >>>> svirt_sandbox_domain; ') >>>> >>>> type foobar_t; domain_type(foobar_t) typeattribute foobar_t >>>> svirt_sandbox_domain; >>>> =============================================== >>>> >>>> I get >>>> >>>> >>>> sesearch -A -s foobar_t | grep capa allow foobar_t foobar_t >>>> : capability mknod ; >>>> >>>> If I remove the typeattribute line foobar_t no longer has >>>> mknod. >>>> >>>> I think this is a compiler problem. >>>> >>>> On 03/29/2016 10:53 AM, Daniel J Walsh wrote: >>>>> When I compile and install this policy >>>>> >>>>> --------------------------------------------------------------- >>>>> # cat /tmp/container.te policy_module(container, 1.0) >>>>> >>>>> virt_sandbox_domain_template(container) >>>>> >>>>> ---------------------------------------------------------------- >>>>> >>>>> I end up with mknod capability. >>>>> >>>>> sesearch -A -s container_t -t container_t -c capability >>>>> Found 1 semantic av rules: allow container_t container_t : >>>>> capability mknod ; >>>>> >>>>> But I didn't add mknod to the policy. >>>>> >>>>> grep mknod tmp/container.tmp class capability { chown >>>>> dac_override dac_read_search fowner fsetid kill setgid >>>>> setuid setpcap linux_immutable net_bind_service >>>>> net_broadcast net_admin net_raw ipc_lock ipc_owner >>>>> sys_module sys_rawio sys_chroot sys_ptrace sys_pacct >>>>> sys_admin sys_boot sys_nice sys_resource sys_time >>>>> sys_tty_config mknod lease audit_write audit_control >>>>> setfcap }; >>>>> >>>>> Any ideas? >>>> _______________________________________________ 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 >> _______________________________________________ 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 iQGcBAEBCAAGBQJXAsW9AAoJECV0jlU3+Udp+7MMAIsBvo/FLOkUY0/099TmY/bU x/97Td+N+ebHciTa/r69j2A7823s9tIJ3HwSPkLfO4ujMfTaG+7+RjjGKH7Sof2U ZTboko964kqfdJnXmrcpkpXwDdfTzpCQ3M0h3T7r23WuZr8LfWoExHnNFv6C+6aq Z1ZavApkd7eS69+rhn9sP9jqf8cdILlTax0EyR9GIdh41uSjVUjuw2LlH42SPdGU xx8KUWJrG0CnGYDFkRpubOTARPoo/kmMLet1bZZnIRIeYslGFhU0QR4PazNE7ffh nfYm+tT4mQTMf3d29oIlYVC+EH4xNxyKhxyUCBUXMNo9HyHiz/oPwxYdxsC5+AUm Iuzc03ic4P6SDPdedyKlLyGHe3k/xfotyDZFKw20SuAA+axkKRe5q+9ZJdT8zLj4 OxJu9+E92zk3T8ZVCSGfdUhnDIwYKn8goP/4MX19MDTco3TCQETbk2Zvdx0GLw1W pRs72qC9/gtB3dBwIX51p32b+zg+HX1eyqHGYwK73g== =B09e -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On Fedora 24 I am seeing something strange with CIL 2016-04-04 19:51 ` Dominick Grift @ 2016-04-04 20:32 ` Steve Lawrence 2016-04-04 20:44 ` Steve Lawrence 0 siblings, 1 reply; 8+ messages in thread From: Steve Lawrence @ 2016-04-04 20:32 UTC (permalink / raw) To: Dominick Grift, Daniel J Walsh, selinux On 04/04/2016 03:51 PM, Dominick Grift wrote: > On 04/04/2016 09:46 PM, Daniel J Walsh wrote: > > >> On 04/04/2016 03:15 PM, Dominick Grift wrote: On 03/29/2016 08:00 >> PM, Daniel J Walsh wrote: >>>>> I investigated this a little further. >>>>> >> manage_chr_files_pattern(svirt_sandbox_domain, >> svirt_sandbox_file_t, svirt_sandbox_file_t) > >> define(`manage_chr_files_pattern',` allow $1 self:capability >> mknod; allow $1 $2:dir rw_dir_perms; allow $1 $3:chr_file >> manage_chr_file_perms; ') > >>> Ok Makes sense but why didn't this come up with the >>> svirt_sandbox_domain attribute as opposed to container_t? Maybe >>> this is a change in cil. > >>> I guess I should not make this the default for >>> svirt_sandbox_domain, and only add it for specific domains. > >>> Thanks Dominick. > > Yes that may indeed well be a CIL thing. CIL does optimization, and > this may make policy analysis a bit different. So yes, be careful when > using type attributes to query the policy. Because CIL may have "moved > rules around" for the sake of efficiency. Best to alway's, atleast > also check the rules associated with the type. > I think this is actually the expected behavior. The issue here is that a typeattribute is used with the 'self' keyword. When this happens, the avrule is expanded to the individual rules. For example: allow attr self : file read; becomes: allow type1 type1 : file read; allow type2 type2 : file read; The original avrule never makes it into the policy. Using the -d flag with sesearch will show this is the case. I don't know if 'self' with typeattributes is a kernel limitation or not, but both CIL and checkpolicy have the same behavior. - Steve > >>>>> If I write a policy file like >>>>> >>>>> =============================================== >>>>> policy_module(container, 1.0) gen_require(` attribute >>>>> svirt_sandbox_domain; ') >>>>> >>>>> type foobar_t; domain_type(foobar_t) typeattribute foobar_t >>>>> svirt_sandbox_domain; >>>>> =============================================== >>>>> >>>>> I get >>>>> >>>>> >>>>> sesearch -A -s foobar_t | grep capa allow foobar_t foobar_t >>>>> : capability mknod ; >>>>> >>>>> If I remove the typeattribute line foobar_t no longer has >>>>> mknod. >>>>> >>>>> I think this is a compiler problem. >>>>> >>>>> On 03/29/2016 10:53 AM, Daniel J Walsh wrote: >>>>>> When I compile and install this policy >>>>>> >>>>>> --------------------------------------------------------------- >>>>>> # cat /tmp/container.te policy_module(container, 1.0) >>>>>> >>>>>> virt_sandbox_domain_template(container) >>>>>> >>>>>> ---------------------------------------------------------------- >>>>>> >>>>>> > I end up with mknod capability. >>>>>> >>>>>> sesearch -A -s container_t -t container_t -c capability >>>>>> Found 1 semantic av rules: allow container_t container_t : >>>>>> capability mknod ; >>>>>> >>>>>> But I didn't add mknod to the policy. >>>>>> >>>>>> grep mknod tmp/container.tmp class capability { chown >>>>>> dac_override dac_read_search fowner fsetid kill setgid >>>>>> setuid setpcap linux_immutable net_bind_service >>>>>> net_broadcast net_admin net_raw ipc_lock ipc_owner >>>>>> sys_module sys_rawio sys_chroot sys_ptrace sys_pacct >>>>>> sys_admin sys_boot sys_nice sys_resource sys_time >>>>>> sys_tty_config mknod lease audit_write audit_control >>>>>> setfcap }; >>>>>> >>>>>> Any ideas? >>>>> _______________________________________________ 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 >>> _______________________________________________ Selinux mailing >>> list Selinux@tycho.nsa.gov To unsubscribe, send email to >>> Selinux-leave@tycho.nsa.gov. To get help, send an email >>> containing "help" to Selinux-request@tycho.nsa.gov. > > > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On Fedora 24 I am seeing something strange with CIL 2016-04-04 20:32 ` Steve Lawrence @ 2016-04-04 20:44 ` Steve Lawrence 2016-04-04 21:26 ` Daniel J Walsh 0 siblings, 1 reply; 8+ messages in thread From: Steve Lawrence @ 2016-04-04 20:44 UTC (permalink / raw) To: Dominick Grift, Daniel J Walsh, selinux On 04/04/2016 04:32 PM, Steve Lawrence wrote: > On 04/04/2016 03:51 PM, Dominick Grift wrote: >> On 04/04/2016 09:46 PM, Daniel J Walsh wrote: >> >> >>> On 04/04/2016 03:15 PM, Dominick Grift wrote: On 03/29/2016 08:00 >>> PM, Daniel J Walsh wrote: >>>>>> I investigated this a little further. >>>>>> >>> manage_chr_files_pattern(svirt_sandbox_domain, >>> svirt_sandbox_file_t, svirt_sandbox_file_t) >> >>> define(`manage_chr_files_pattern',` allow $1 self:capability >>> mknod; allow $1 $2:dir rw_dir_perms; allow $1 $3:chr_file >>> manage_chr_file_perms; ') >> >>>> Ok Makes sense but why didn't this come up with the >>>> svirt_sandbox_domain attribute as opposed to container_t? Maybe >>>> this is a change in cil. >> >>>> I guess I should not make this the default for >>>> svirt_sandbox_domain, and only add it for specific domains. >> >>>> Thanks Dominick. >> >> Yes that may indeed well be a CIL thing. CIL does optimization, and >> this may make policy analysis a bit different. So yes, be careful when >> using type attributes to query the policy. Because CIL may have "moved >> rules around" for the sake of efficiency. Best to alway's, atleast >> also check the rules associated with the type. >> > > I think this is actually the expected behavior. The issue here is that a > typeattribute is used with the 'self' keyword. When this happens, the > avrule is expanded to the individual rules. For example: > > allow attr self : file read; > > becomes: > > allow type1 type1 : file read; > allow type2 type2 : file read; > > The original avrule never makes it into the policy. Using the -d flag > with sesearch will show this is the case. I don't know if 'self' with > typeattributes is a kernel limitation or not, but both CIL and > checkpolicy have the same behavior. > Ah, actually, I think the binary policy/kernel does not have a concept of 'self' at all. Once put in the binary, this allow type1 self : file read; becomes allow type1 type1 : file read; So 'self' is essentially replaced with the source type. However, you cannot do this replacement when source is an attribute because this allow attr self : file read; and this allow attr attr : file read; have very different meanings. So since the kernel has no concept of self, attributes with self must be expanded. >> >>>>>> If I write a policy file like >>>>>> >>>>>> =============================================== >>>>>> policy_module(container, 1.0) gen_require(` attribute >>>>>> svirt_sandbox_domain; ') >>>>>> >>>>>> type foobar_t; domain_type(foobar_t) typeattribute foobar_t >>>>>> svirt_sandbox_domain; >>>>>> =============================================== >>>>>> >>>>>> I get >>>>>> >>>>>> >>>>>> sesearch -A -s foobar_t | grep capa allow foobar_t foobar_t >>>>>> : capability mknod ; >>>>>> >>>>>> If I remove the typeattribute line foobar_t no longer has >>>>>> mknod. >>>>>> >>>>>> I think this is a compiler problem. >>>>>> >>>>>> On 03/29/2016 10:53 AM, Daniel J Walsh wrote: >>>>>>> When I compile and install this policy >>>>>>> >>>>>>> --------------------------------------------------------------- >>>>>>> # cat /tmp/container.te policy_module(container, 1.0) >>>>>>> >>>>>>> virt_sandbox_domain_template(container) >>>>>>> >>>>>>> ---------------------------------------------------------------- >>>>>>> >>>>>>> >> I end up with mknod capability. >>>>>>> >>>>>>> sesearch -A -s container_t -t container_t -c capability >>>>>>> Found 1 semantic av rules: allow container_t container_t : >>>>>>> capability mknod ; >>>>>>> >>>>>>> But I didn't add mknod to the policy. >>>>>>> >>>>>>> grep mknod tmp/container.tmp class capability { chown >>>>>>> dac_override dac_read_search fowner fsetid kill setgid >>>>>>> setuid setpcap linux_immutable net_bind_service >>>>>>> net_broadcast net_admin net_raw ipc_lock ipc_owner >>>>>>> sys_module sys_rawio sys_chroot sys_ptrace sys_pacct >>>>>>> sys_admin sys_boot sys_nice sys_resource sys_time >>>>>>> sys_tty_config mknod lease audit_write audit_control >>>>>>> setfcap }; >>>>>>> >>>>>>> Any ideas? >>>>>> _______________________________________________ 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 >>>> _______________________________________________ Selinux mailing >>>> list Selinux@tycho.nsa.gov To unsubscribe, send email to >>>> Selinux-leave@tycho.nsa.gov. To get help, send an email >>>> containing "help" to Selinux-request@tycho.nsa.gov. >> >> >> _______________________________________________ >> Selinux mailing list >> Selinux@tycho.nsa.gov >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. >> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. >> > > _______________________________________________ > 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. > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On Fedora 24 I am seeing something strange with CIL 2016-04-04 20:44 ` Steve Lawrence @ 2016-04-04 21:26 ` Daniel J Walsh 0 siblings, 0 replies; 8+ messages in thread From: Daniel J Walsh @ 2016-04-04 21:26 UTC (permalink / raw) To: Steve Lawrence, Dominick Grift, selinux On 04/04/2016 04:44 PM, Steve Lawrence wrote: > On 04/04/2016 04:32 PM, Steve Lawrence wrote: >> On 04/04/2016 03:51 PM, Dominick Grift wrote: >>> On 04/04/2016 09:46 PM, Daniel J Walsh wrote: >>> >>> >>>> On 04/04/2016 03:15 PM, Dominick Grift wrote: On 03/29/2016 08:00 >>>> PM, Daniel J Walsh wrote: >>>>>>> I investigated this a little further. >>>>>>> >>>> manage_chr_files_pattern(svirt_sandbox_domain, >>>> svirt_sandbox_file_t, svirt_sandbox_file_t) >>>> define(`manage_chr_files_pattern',` allow $1 self:capability >>>> mknod; allow $1 $2:dir rw_dir_perms; allow $1 $3:chr_file >>>> manage_chr_file_perms; ') >>>>> Ok Makes sense but why didn't this come up with the >>>>> svirt_sandbox_domain attribute as opposed to container_t? Maybe >>>>> this is a change in cil. >>>>> I guess I should not make this the default for >>>>> svirt_sandbox_domain, and only add it for specific domains. >>>>> Thanks Dominick. >>> Yes that may indeed well be a CIL thing. CIL does optimization, and >>> this may make policy analysis a bit different. So yes, be careful when >>> using type attributes to query the policy. Because CIL may have "moved >>> rules around" for the sake of efficiency. Best to alway's, atleast >>> also check the rules associated with the type. >>> >> I think this is actually the expected behavior. The issue here is that a >> typeattribute is used with the 'self' keyword. When this happens, the >> avrule is expanded to the individual rules. For example: >> >> allow attr self : file read; >> >> becomes: >> >> allow type1 type1 : file read; >> allow type2 type2 : file read; >> >> The original avrule never makes it into the policy. Using the -d flag >> with sesearch will show this is the case. I don't know if 'self' with >> typeattributes is a kernel limitation or not, but both CIL and >> checkpolicy have the same behavior. >> > Ah, actually, I think the binary policy/kernel does not have a concept > of 'self' at all. Once put in the binary, this > > allow type1 self : file read; > > becomes > > allow type1 type1 : file read; > > So 'self' is essentially replaced with the source type. However, you > cannot do this replacement when source is an attribute because this > > allow attr self : file read; > > and this > > allow attr attr : file read; > > have very different meanings. So since the kernel has no concept of > self, attributes with self must be expanded. > That makes sense, so it probably worked the same was as before, anyways I was confused, and now I have a fix to get what I want which is a container process with no caps. >>>>>>> If I write a policy file like >>>>>>> >>>>>>> =============================================== >>>>>>> policy_module(container, 1.0) gen_require(` attribute >>>>>>> svirt_sandbox_domain; ') >>>>>>> >>>>>>> type foobar_t; domain_type(foobar_t) typeattribute foobar_t >>>>>>> svirt_sandbox_domain; >>>>>>> =============================================== >>>>>>> >>>>>>> I get >>>>>>> >>>>>>> >>>>>>> sesearch -A -s foobar_t | grep capa allow foobar_t foobar_t >>>>>>> : capability mknod ; >>>>>>> >>>>>>> If I remove the typeattribute line foobar_t no longer has >>>>>>> mknod. >>>>>>> >>>>>>> I think this is a compiler problem. >>>>>>> >>>>>>> On 03/29/2016 10:53 AM, Daniel J Walsh wrote: >>>>>>>> When I compile and install this policy >>>>>>>> >>>>>>>> --------------------------------------------------------------- >>>>>>>> # cat /tmp/container.te policy_module(container, 1.0) >>>>>>>> >>>>>>>> virt_sandbox_domain_template(container) >>>>>>>> >>>>>>>> ---------------------------------------------------------------- >>>>>>>> >>>>>>>> >>> I end up with mknod capability. >>>>>>>> sesearch -A -s container_t -t container_t -c capability >>>>>>>> Found 1 semantic av rules: allow container_t container_t : >>>>>>>> capability mknod ; >>>>>>>> >>>>>>>> But I didn't add mknod to the policy. >>>>>>>> >>>>>>>> grep mknod tmp/container.tmp class capability { chown >>>>>>>> dac_override dac_read_search fowner fsetid kill setgid >>>>>>>> setuid setpcap linux_immutable net_bind_service >>>>>>>> net_broadcast net_admin net_raw ipc_lock ipc_owner >>>>>>>> sys_module sys_rawio sys_chroot sys_ptrace sys_pacct >>>>>>>> sys_admin sys_boot sys_nice sys_resource sys_time >>>>>>>> sys_tty_config mknod lease audit_write audit_control >>>>>>>> setfcap }; >>>>>>>> >>>>>>>> Any ideas? >>>>>>> _______________________________________________ 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 >>>>> _______________________________________________ Selinux mailing >>>>> list Selinux@tycho.nsa.gov To unsubscribe, send email to >>>>> Selinux-leave@tycho.nsa.gov. To get help, send an email >>>>> containing "help" to Selinux-request@tycho.nsa.gov. >>> >>> _______________________________________________ >>> Selinux mailing list >>> Selinux@tycho.nsa.gov >>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. >>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. >>> >> _______________________________________________ >> Selinux mailing list >> Selinux@tycho.nsa.gov >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. >> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. >> > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. > > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-04-04 21:26 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-03-29 14:53 On Fedora 24 I am seeing something strange with CIL Daniel J Walsh 2016-03-29 18:00 ` Daniel J Walsh 2016-04-04 19:15 ` Dominick Grift 2016-04-04 19:46 ` Daniel J Walsh 2016-04-04 19:51 ` Dominick Grift 2016-04-04 20:32 ` Steve Lawrence 2016-04-04 20:44 ` Steve Lawrence 2016-04-04 21:26 ` Daniel J Walsh
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.