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 };')
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 };
instead of:
allow $1 $2:file { getattr open read execute };
Am I right or missing something?
Thanks for help!
Lukas.
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20180719/b16f0660/attachment.bin
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
> refpolicy at 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&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20180719/2b7c7e51/attachment.bin
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
> > refpolicy at 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&search=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20180719/07a7326f/attachment.bin
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
>>> refpolicy at 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&search=0x3B6C5F1D2C7B6B02
>> Dominick Grift
>
>
>
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20180719/303703b4/attachment-0001.bin
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
> >>> refpolicy at 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&search=0x3B6C5F1D2C7B6B02
> >> Dominick Grift
> >
> >
> >
> >
> >
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> >
>
>
> --
> Lukas Vrabec
> Software Engineer, Security Technologies
> Red Hat, Inc.
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at 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&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20180719/64cdf37a/attachment.bin
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
>>>>> refpolicy at 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&search=0x3B6C5F1D2C7B6B02
>>>> Dominick Grift
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> refpolicy mailing list
>>> refpolicy at oss.tresys.com
>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>>
>>
>>
>> --
>> Lukas Vrabec
>> Software Engineer, Security Technologies
>> Red Hat, Inc.
>>
>
>
>
>
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>
>
>
>
> _______________________________________________
> Selinux mailing list
> Selinux at tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave at tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request at tycho.nsa.gov.
>
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20180719/a5f68c2b/attachment.bin
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
> >>>>> refpolicy at 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&search=0x3B6C5F1D2C7B6B02
> >>>> Dominick Grift
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> refpolicy mailing list
> >>> refpolicy at oss.tresys.com
> >>> http://oss.tresys.com/mailman/listinfo/refpolicy
> >>>
> >>
> >>
> >> --
> >> Lukas Vrabec
> >> Software Engineer, Security Technologies
> >> Red Hat, Inc.
> >>
> >
> >
> >
> >
> >> _______________________________________________
> >> refpolicy mailing list
> >> refpolicy at oss.tresys.com
> >> http://oss.tresys.com/mailman/listinfo/refpolicy
> >
> >
> >
> >
> > _______________________________________________
> > Selinux mailing list
> > Selinux at tycho.nsa.gov
> > To unsubscribe, send email to Selinux-leave at tycho.nsa.gov.
> > To get help, send an email containing "help" to Selinux-request at tycho.nsa.gov.
> >
>
>
> --
> Lukas Vrabec
> Software Engineer, Security Technologies
> Red Hat, Inc.
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at 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&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20180719/971cde57/attachment.bin