Re: [refpolicy] map permission in can_exec() but not in domain_transition_pattern()
On Thu, Jul 19, 2018 at 07:54:22PM +0200, Lukas Vrabec via refpolicy wrote: > On 07/19/2018 07:47 PM, Dominick Grift wrote: > > On Thu, Jul 19, 2018 at 07:42:53PM +0200, Lukas Vrabec via refpolicy wrote: > >> On 07/19/2018 06:51 PM, Dominick Grift via refpolicy wrote: > >>> On Thu, Jul 19, 2018 at 06:40:25PM +0200, Dominick Grift wrote: > On Thu, Jul 19, 2018 at 06:17:46PM +0200, Lukas Vrabec via refpolicy > wrote: > > Hi All, > > > > I found one thing in refpolicy which I don't completely understand. > > > > In "policy/support/misc_patterns.spt" there is definition of > > "domain_transition_pattern" and this contains line: > > allow $1 $2:file { getattr open read execute }; > > > > There is missing map permission. > > > > However in "policy/support/misc_macros.spt" there is definition of > > "can_exec" and it contains allow rule: > > define(`can_exec',`allow $1 $2:file { mmap_exec_file_perms ioctl lock > > execute_no_trans };') > >>> > >>> Sorry can_exec() should just use exec_file_perms which would should be > >>> mmap_exec_file_perms + execute_no_trans IMHO > >>> > > This should just use mmap_exec_file_perms > > >> > >> Should we remove lock permission? > > > > I would say yes, but i am not sure why it was added in the first place > > > > It could be dangerous to remove it in such general macro. Let's test it > before. You might also just add it to mmap_exec_file_perms, even though i do not believe that either mmap_exec_file_perms or exec_file_perms need it, its not such a big deal. > > >> > > > > There is a mmap_exec_file_perms which contains: > > define(`mmap_exec_file_perms',`{ getattr open map read execute ioctl }') > > > > Map is present in can_exec(). > > > > So for domain transitions we don't allow map permission from calling > > domain on binary type but in can_exec macro there is map permission. > > > > I think this is a bug and in "domain_transition_pattern" there should be > > this line: > > allow $1 $2:file { getattr open read execute map }; > > This should just use mmap_exec_file_perms as well > > > > > instead of: > > allow $1 $2:file { getattr open read execute }; > > > > Am I right or missing something? > > > > Thanks for help! > > Lukas. > > permission sets provide a single point of failure and should used as > much as possible > > These were overlooked and because of this we now have a good example > what the purpose of permission sets and patterns is. > > >> > >> Thanks, I'll prepare patch. > >> > >> Lukas. > >> > > > > -- > > Lukas Vrabec > > Software Engineer, Security Technologies > > Red Hat, Inc. > > > > > > > > ___ > > refpolicy mailing list > > refpol...@oss.tresys.com > > http://oss.tresys.com/mailman/listinfo/refpolicy > > > -- > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > Dominick Grift > >>> > >>> > >>> > >>> > >>> > >>> ___ > >>> refpolicy mailing list > >>> refpol...@oss.tresys.com > >>> http://oss.tresys.com/mailman/listinfo/refpolicy > >>> > >> > >> > >> -- > >> Lukas Vrabec > >> Software Engineer, Security Technologies > >> Red Hat, Inc. > >> > > > > > > > > > >> ___ > >> refpolicy mailing list > >> refpol...@oss.tresys.com > >> http://oss.tresys.com/mailman/listinfo/refpolicy > > > > > > > > > > ___ > > Selinux mailing list > > Selinux@tycho.nsa.gov > > To unsubscribe, send email to selinux-le...@tycho.nsa.gov. > > To get help, send an email containing "help" to > > selinux-requ...@tycho.nsa.gov. > > > > > -- > Lukas Vrabec > Software Engineer, Security Technologies > Red Hat, Inc. > > ___ > refpolicy mailing list > refpol...@oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [refpolicy] map permission in can_exec() but not in domain_transition_pattern()
On 07/19/2018 07:47 PM, Dominick Grift wrote: > On Thu, Jul 19, 2018 at 07:42:53PM +0200, Lukas Vrabec via refpolicy wrote: >> On 07/19/2018 06:51 PM, Dominick Grift via refpolicy wrote: >>> On Thu, Jul 19, 2018 at 06:40:25PM +0200, Dominick Grift wrote: On Thu, Jul 19, 2018 at 06:17:46PM +0200, Lukas Vrabec via refpolicy wrote: > Hi All, > > I found one thing in refpolicy which I don't completely understand. > > In "policy/support/misc_patterns.spt" there is definition of > "domain_transition_pattern" and this contains line: > allow $1 $2:file { getattr open read execute }; > > There is missing map permission. > > However in "policy/support/misc_macros.spt" there is definition of > "can_exec" and it contains allow rule: > define(`can_exec',`allow $1 $2:file { mmap_exec_file_perms ioctl lock > execute_no_trans };') >>> >>> Sorry can_exec() should just use exec_file_perms which would should be >>> mmap_exec_file_perms + execute_no_trans IMHO >>> This should just use mmap_exec_file_perms >> >> Should we remove lock permission? > > I would say yes, but i am not sure why it was added in the first place > It could be dangerous to remove it in such general macro. Let's test it before. >> > > There is a mmap_exec_file_perms which contains: > define(`mmap_exec_file_perms',`{ getattr open map read execute ioctl }') > > Map is present in can_exec(). > > So for domain transitions we don't allow map permission from calling > domain on binary type but in can_exec macro there is map permission. > > I think this is a bug and in "domain_transition_pattern" there should be > this line: > allow $1 $2:file { getattr open read execute map }; This should just use mmap_exec_file_perms as well > > instead of: > allow $1 $2:file { getattr open read execute }; > > Am I right or missing something? > > Thanks for help! > Lukas. permission sets provide a single point of failure and should used as much as possible These were overlooked and because of this we now have a good example what the purpose of permission sets and patterns is. >> >> Thanks, I'll prepare patch. >> >> Lukas. >> > > -- > Lukas Vrabec > Software Engineer, Security Technologies > Red Hat, Inc. > > ___ > refpolicy mailing list > refpol...@oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift >>> >>> >>> >>> >>> >>> ___ >>> refpolicy mailing list >>> refpol...@oss.tresys.com >>> http://oss.tresys.com/mailman/listinfo/refpolicy >>> >> >> >> -- >> Lukas Vrabec >> Software Engineer, Security Technologies >> Red Hat, Inc. >> > > > > >> ___ >> refpolicy mailing list >> refpol...@oss.tresys.com >> http://oss.tresys.com/mailman/listinfo/refpolicy > > > > > ___ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to selinux-le...@tycho.nsa.gov. > To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov. > -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. signature.asc Description: OpenPGP digital signature ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [refpolicy] map permission in can_exec() but not in domain_transition_pattern()
On Thu, Jul 19, 2018 at 07:42:53PM +0200, Lukas Vrabec via refpolicy wrote: > On 07/19/2018 06:51 PM, Dominick Grift via refpolicy wrote: > > On Thu, Jul 19, 2018 at 06:40:25PM +0200, Dominick Grift wrote: > >> On Thu, Jul 19, 2018 at 06:17:46PM +0200, Lukas Vrabec via refpolicy wrote: > >>> Hi All, > >>> > >>> I found one thing in refpolicy which I don't completely understand. > >>> > >>> In "policy/support/misc_patterns.spt" there is definition of > >>> "domain_transition_pattern" and this contains line: > >>> allow $1 $2:file { getattr open read execute }; > >>> > >>> There is missing map permission. > >>> > >>> However in "policy/support/misc_macros.spt" there is definition of > >>> "can_exec" and it contains allow rule: > >>> define(`can_exec',`allow $1 $2:file { mmap_exec_file_perms ioctl lock > >>> execute_no_trans };') > > > > Sorry can_exec() should just use exec_file_perms which would should be > > mmap_exec_file_perms + execute_no_trans IMHO > > > >> > >> This should just use mmap_exec_file_perms > >> > > Should we remove lock permission? I would say yes, but i am not sure why it was added in the first place > > >>> > >>> There is a mmap_exec_file_perms which contains: > >>> define(`mmap_exec_file_perms',`{ getattr open map read execute ioctl }') > >>> > >>> Map is present in can_exec(). > >>> > >>> So for domain transitions we don't allow map permission from calling > >>> domain on binary type but in can_exec macro there is map permission. > >>> > >>> I think this is a bug and in "domain_transition_pattern" there should be > >>> this line: > >>> allow $1 $2:file { getattr open read execute map }; > >> > >> This should just use mmap_exec_file_perms as well > >> > >>> > >>> instead of: > >>> allow $1 $2:file { getattr open read execute }; > >>> > >>> Am I right or missing something? > >>> > >>> Thanks for help! > >>> Lukas. > >> > >> permission sets provide a single point of failure and should used as much > >> as possible > >> > >> These were overlooked and because of this we now have a good example what > >> the purpose of permission sets and patterns is. > >> > > Thanks, I'll prepare patch. > > Lukas. > > >>> > >>> -- > >>> Lukas Vrabec > >>> Software Engineer, Security Technologies > >>> Red Hat, Inc. > >>> > >> > >> > >> > >> > >>> ___ > >>> refpolicy mailing list > >>> refpol...@oss.tresys.com > >>> http://oss.tresys.com/mailman/listinfo/refpolicy > >> > >> > >> -- > >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > >> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > >> Dominick Grift > > > > > > > > > > > > ___ > > refpolicy mailing list > > refpol...@oss.tresys.com > > http://oss.tresys.com/mailman/listinfo/refpolicy > > > > > -- > Lukas Vrabec > Software Engineer, Security Technologies > Red Hat, Inc. > > ___ > refpolicy mailing list > refpol...@oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [refpolicy] map permission in can_exec() but not in domain_transition_pattern()
On 07/19/2018 06:51 PM, Dominick Grift via refpolicy wrote: > On Thu, Jul 19, 2018 at 06:40:25PM +0200, Dominick Grift wrote: >> On Thu, Jul 19, 2018 at 06:17:46PM +0200, Lukas Vrabec via refpolicy wrote: >>> Hi All, >>> >>> I found one thing in refpolicy which I don't completely understand. >>> >>> In "policy/support/misc_patterns.spt" there is definition of >>> "domain_transition_pattern" and this contains line: >>> allow $1 $2:file { getattr open read execute }; >>> >>> There is missing map permission. >>> >>> However in "policy/support/misc_macros.spt" there is definition of >>> "can_exec" and it contains allow rule: >>> define(`can_exec',`allow $1 $2:file { mmap_exec_file_perms ioctl lock >>> execute_no_trans };') > > Sorry can_exec() should just use exec_file_perms which would should be > mmap_exec_file_perms + execute_no_trans IMHO > >> >> This should just use mmap_exec_file_perms >> Should we remove lock permission? >>> >>> There is a mmap_exec_file_perms which contains: >>> define(`mmap_exec_file_perms',`{ getattr open map read execute ioctl }') >>> >>> Map is present in can_exec(). >>> >>> So for domain transitions we don't allow map permission from calling >>> domain on binary type but in can_exec macro there is map permission. >>> >>> I think this is a bug and in "domain_transition_pattern" there should be >>> this line: >>> allow $1 $2:file { getattr open read execute map }; >> >> This should just use mmap_exec_file_perms as well >> >>> >>> instead of: >>> allow $1 $2:file { getattr open read execute }; >>> >>> Am I right or missing something? >>> >>> Thanks for help! >>> Lukas. >> >> permission sets provide a single point of failure and should used as much as >> possible >> >> These were overlooked and because of this we now have a good example what >> the purpose of permission sets and patterns is. >> Thanks, I'll prepare patch. Lukas. >>> >>> -- >>> Lukas Vrabec >>> Software Engineer, Security Technologies >>> Red Hat, Inc. >>> >> >> >> >> >>> ___ >>> refpolicy mailing list >>> refpol...@oss.tresys.com >>> http://oss.tresys.com/mailman/listinfo/refpolicy >> >> >> -- >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 >> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 >> Dominick Grift > > > > > > ___ > refpolicy mailing list > refpol...@oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy > -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. signature.asc Description: OpenPGP digital signature ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [refpolicy] map permission in can_exec() but not in domain_transition_pattern()
On Thu, Jul 19, 2018 at 06:40:25PM +0200, Dominick Grift wrote: > On Thu, Jul 19, 2018 at 06:17:46PM +0200, Lukas Vrabec via refpolicy wrote: > > Hi All, > > > > I found one thing in refpolicy which I don't completely understand. > > > > In "policy/support/misc_patterns.spt" there is definition of > > "domain_transition_pattern" and this contains line: > > allow $1 $2:file { getattr open read execute }; > > > > There is missing map permission. > > > > However in "policy/support/misc_macros.spt" there is definition of > > "can_exec" and it contains allow rule: > > define(`can_exec',`allow $1 $2:file { mmap_exec_file_perms ioctl lock > > execute_no_trans };') Sorry can_exec() should just use exec_file_perms which would should be mmap_exec_file_perms + execute_no_trans IMHO > > This should just use mmap_exec_file_perms > > > > > There is a mmap_exec_file_perms which contains: > > define(`mmap_exec_file_perms',`{ getattr open map read execute ioctl }') > > > > Map is present in can_exec(). > > > > So for domain transitions we don't allow map permission from calling > > domain on binary type but in can_exec macro there is map permission. > > > > I think this is a bug and in "domain_transition_pattern" there should be > > this line: > > allow $1 $2:file { getattr open read execute map }; > > This should just use mmap_exec_file_perms as well > > > > > instead of: > > allow $1 $2:file { getattr open read execute }; > > > > Am I right or missing something? > > > > Thanks for help! > > Lukas. > > permission sets provide a single point of failure and should used as much as > possible > > These were overlooked and because of this we now have a good example what the > purpose of permission sets and patterns is. > > > > > -- > > Lukas Vrabec > > Software Engineer, Security Technologies > > Red Hat, Inc. > > > > > > > > ___ > > refpolicy mailing list > > refpol...@oss.tresys.com > > http://oss.tresys.com/mailman/listinfo/refpolicy > > > -- > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > Dominick Grift -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [refpolicy] map permission in can_exec() but not in domain_transition_pattern()
On Thu, Jul 19, 2018 at 06:17:46PM +0200, Lukas Vrabec via refpolicy wrote: > Hi All, > > I found one thing in refpolicy which I don't completely understand. > > In "policy/support/misc_patterns.spt" there is definition of > "domain_transition_pattern" and this contains line: > allow $1 $2:file { getattr open read execute }; > > There is missing map permission. > > However in "policy/support/misc_macros.spt" there is definition of > "can_exec" and it contains allow rule: > define(`can_exec',`allow $1 $2:file { mmap_exec_file_perms ioctl lock > execute_no_trans };') This should just use mmap_exec_file_perms > > There is a mmap_exec_file_perms which contains: > define(`mmap_exec_file_perms',`{ getattr open map read execute ioctl }') > > Map is present in can_exec(). > > So for domain transitions we don't allow map permission from calling > domain on binary type but in can_exec macro there is map permission. > > I think this is a bug and in "domain_transition_pattern" there should be > this line: > allow $1 $2:file { getattr open read execute map }; This should just use mmap_exec_file_perms as well > > instead of: > allow $1 $2:file { getattr open read execute }; > > Am I right or missing something? > > Thanks for help! > Lukas. permission sets provide a single point of failure and should used as much as possible These were overlooked and because of this we now have a good example what the purpose of permission sets and patterns is. > > -- > Lukas Vrabec > Software Engineer, Security Technologies > Red Hat, Inc. > > ___ > refpolicy mailing list > refpol...@oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.