Re: [refpolicy] map permission in can_exec() but not in domain_transition_pattern()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx
> >>>>> 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@xxxxxxxxxxxxxx
> >>> http://oss.tresys.com/mailman/listinfo/refpolicy
> >>>
> >>
> >>
> >> -- 
> >> Lukas Vrabec
> >> Software Engineer, Security Technologies
> >> Red Hat, Inc.
> >>
> > 
> > 
> > 
> > 
> >> _______________________________________________
> >> refpolicy mailing list
> >> refpolicy@xxxxxxxxxxxxxx
> >> http://oss.tresys.com/mailman/listinfo/refpolicy
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Selinux mailing list
> > Selinux@xxxxxxxxxxxxx
> > To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
> > To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
> > 
> 
> 
> -- 
> Lukas Vrabec
> Software Engineer, Security Technologies
> Red Hat, Inc.
> 




> _______________________________________________
> refpolicy mailing list
> refpolicy@xxxxxxxxxxxxxx
> 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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux