From: jason@perfinion.com (Jason Zaman) Date: Sun, 14 Aug 2016 00:19:22 +0800 Subject: [refpolicy] [PATCH] fc_sort must be explicitly labeled as executable upon creation In-Reply-To: <1e6a127c-78ff-2387-a5d7-534b3e943592@gmail.com> References: <1470669970.10405.3.camel@trentalancia.net> <1471092620.21480.3.camel@trentalancia.net> <41868e4e-b084-eae3-80c0-a3fe4cf2fc26@ieee.org> <1860468357.5602.1471104524357.JavaMail.open-xchange@popper04.register.it> <1e6a127c-78ff-2387-a5d7-534b3e943592@gmail.com> Message-ID: <20160813161922.GA17831@meriadoc.perfinion.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Sat, Aug 13, 2016 at 06:16:43PM +0200, Dominick Grift wrote: > On 08/13/2016 06:08 PM, guido guido wrote: > > Hello Chris. > > > >> On 13th August 2016 at 15.00 Chris PeBenito wrote: > >>> On Sat, 13/08/2016 at 08.32 -0400, Chris PeBenito wrote: > >>>> On 08/08/16 11:26, Guido Trentalancia wrote: > >>>>> Force a bin_t label on the fc_sort executable after creating it, to > >>>>> avoid execution > >>>>> denials (e.g. misplaced generic default labels). > >>>>> > >>>>> Signed-off-by: Guido Trentalancia > >>>>> --- > >>>>> Makefile | 1 + > >>>>> 1 file changed, 1 insertion(+) > >>>>> > >>>>> --- refpolicy-04062012/Makefile 2012-05-29 > >>>>> 21:13:09.413703575 +0200 > >>>>> +++ refpolicy-04062012-chcon-fc_sort/Makefile 2012-08-04 > >>>>> 21:35:57.396092798 +0200 > >>>>> @@ -400,6 +400,7 @@ $(mod_conf) $(booleans): $(polxml) > >>>>> # > >>>>> $(fcsort) : $(support)/fc_sort.c > >>>>> $(verbose) $(CC) $(CFLAGS) $^ -o $@ > >>>>> + chcon system_u:object_r:bin_t:s0 $(tmpdir)/fc_sort > >>>>> > >>>>> ######################################## > >>>>> # > >>>> > >>>> I'd prefer not to hard code any labeling into make targets except > >>>> for > >>>> those that are explicitly for labeling. > >>> > >>> Can we determine it at runtime then ? > >>> > >>> For example by using grep "^/bin/\." on the corecommands.fc file and > >>> then with a little bit more processing ? > >>> > >>> Otherwise the fc_sort binary cannot, in general, be executed ! > >> > >> I don't want to make assumptions about where the policy is being > >> compiled. I don't think that you can assume it is not executable, in > >> general. e.g. if I build refpolicy in my home dir, then I can execute > >> fc_sort, and in that case you may not even be able to chcon to bin_t. > > > > As far as I know, system-wide sources are usually installed in /usr/src... > > > > That's why I suppose it ends up mislabeling the executable file context in most > > cases... > > > > What do you say ? > > > > How about adding an fc spec for that in refpolicy, and then just run > restorecon in the makefile? What is that? like restorecon $DEST/?/support src_t is executable tho? why would it need to be changed? sesearch shows: allow sysadm_t src_t : file { ioctl read getattr execute execute_no_trans open } ; -- Jason > > > Regards, > > > > Guido > > _______________________________________________ > > 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