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 <[email protected]>
---
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
########################################
#
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 <[email protected]>
> ---
> 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.
--
Chris PeBenito
Hello Christopher !
Thanks for getting back on this...
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 <[email protected]>
> > ---
> > ?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 !
Best regards,
Guido
On 08/13/16 08:50, Guido Trentalancia wrote:
> Hello Christopher !
>
> Thanks for getting back on this...
Sorry for the delay.
> 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 <[email protected]>
>>> ---
>>> 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.
--
Chris PeBenito
Hello Chris.
> On 13th August 2016 at 15.00 Chris PeBenito <[email protected]> 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 <[email protected]>
> >>> ---
> >>> 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 ?
Regards,
Guido
On 08/13/2016 06:08 PM, guido guido wrote:
> Hello Chris.
>
>> On 13th August 2016 at 15.00 Chris PeBenito <[email protected]> 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 <[email protected]>
>>>>> ---
>>>>> 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
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160813/2829522d/attachment-0001.bin
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 <[email protected]> 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 <[email protected]>
> >>>>> ---
> >>>>> 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
On 08/13/2016 06:19 PM, Jason Zaman wrote:
> 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 <[email protected]> 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 <[email protected]>
>>>>>>> ---
>>>>>>> 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
>>
Good call
>>> 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
>
--
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: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160813/3973f697/attachment.bin
Install the fc_sort executable system-wide during the make target
"install-src" (i.e. prior to make "policy") to avoid execution denials,
due to misplaced generic non-executable default file labels, if the
Reference Policy is installed in system-wide directories such as
/usr/src.
Signed-off-by: Guido Trentalancia <[email protected]>
---
Makefile | 4 +++-
Rules.modular | 4 ++--
Rules.monolithic | 4 ++--
3 files changed, 7 insertions(+), 5 deletions(-)
--- refpolicy-git-06082016-orig/Makefile 2016-08-06 21:26:43.257773849 +0200
+++ refpolicy-git-06082016/Makefile 2016-08-13 18:31:37.005598127 +0200
@@ -99,6 +99,7 @@ gendoc := $(PYTHON) -E $(support)/sedoct
genperm := $(PYTHON) -E $(support)/genclassperms.py
policyvers := $(PYTHON) -E $(support)/policyvers.py
fcsort := $(tmpdir)/fc_sort
+fcsortexe := $(BINDIR)/fc_sort
setbools := $(AWK) -f $(support)/set_bools_tuns.awk
get_type_attr_decl := $(SED) -r -f $(support)/get_type_attr_decl.sed
comment_move_decl := $(SED) -r -f $(support)/comment_move_decl.sed
@@ -547,11 +548,12 @@ install-docs: $(tmpdir)/html
#
# Install policy sources
#
-install-src:
+install-src: $(fcsort)
rm -rf $(srcpath)/policy.old
-mv $(srcpath)/policy $(srcpath)/policy.old
mkdir -p $(srcpath)/policy
cp -R . $(srcpath)/policy
+ install tmp/fc_sort $(fcsortexe)
########################################
#
--- refpolicy-git-06082016-orig/Rules.modular 2016-08-06 21:26:43.257773849
+0200
+++ refpolicy-git-06082016/Rules.modular 2016-08-13 18:32:09.211057621 +0200
@@ -174,8 +174,8 @@ $(tmpdir)/only_te_rules.conf: $(tmpdir)/
#
# Construct a base.fc
#
-$(base_fc): $(tmpdir)/$(notdir $(base_fc)).tmp $(fcsort)
- $(verbose) $(fcsort) $< $@
+$(base_fc): $(tmpdir)/$(notdir $(base_fc)).tmp $(fcsortexe)
+ $(verbose) $(fcsortexe) $< $@
$(tmpdir)/$(notdir $(base_fc)).tmp: $(m4support)
$(tmpdir)/generated_definitions.conf $(base_fc_files)
ifeq ($(base_fc_files),)
--- refpolicy-git-06082016-orig/Rules.monolithic 2016-08-06 21:26:43.258773860
+0200
+++ refpolicy-git-06082016/Rules.monolithic 2016-08-13 18:32:40.188493779 +0200
@@ -168,8 +168,8 @@ enableaudit: $(policy_conf)
#
# Construct file_contexts
#
-$(fc): $(tmpdir)/$(notdir $(fc)).tmp $(fcsort)
- $(verbose) $(fcsort) $< $@
+$(fc): $(tmpdir)/$(notdir $(fc)).tmp $(fcsortexe)
+ $(verbose) $(fcsortexe) $< $@
$(verbose) $(GREP) -e HOME -e ROLE -e USER $@ > $(homedir_template)
$(verbose) $(SED) -i -e /HOME/d -e /ROLE/d -e /USER/d $@
On 08/13/16 12:40, guido guido wrote:
> Install the fc_sort executable system-wide during the make target
> "install-src" (i.e. prior to make "policy") to avoid execution denials,
> due to misplaced generic non-executable default file labels, if the
> Reference Policy is installed in system-wide directories such as
> /usr/src.
I suspect that this will break the case where one simply clones the repo
or unpacks a release and simply tries to build it wherever it is,
especially if they can't or don't want to run the install-src target.
> Signed-off-by: Guido Trentalancia <[email protected]>
> ---
> Makefile | 4 +++-
> Rules.modular | 4 ++--
> Rules.monolithic | 4 ++--
> 3 files changed, 7 insertions(+), 5 deletions(-)
>
> --- refpolicy-git-06082016-orig/Makefile 2016-08-06 21:26:43.257773849 +0200
> +++ refpolicy-git-06082016/Makefile 2016-08-13 18:31:37.005598127 +0200
> @@ -99,6 +99,7 @@ gendoc := $(PYTHON) -E $(support)/sedoct
> genperm := $(PYTHON) -E $(support)/genclassperms.py
> policyvers := $(PYTHON) -E $(support)/policyvers.py
> fcsort := $(tmpdir)/fc_sort
> +fcsortexe := $(BINDIR)/fc_sort
> setbools := $(AWK) -f $(support)/set_bools_tuns.awk
> get_type_attr_decl := $(SED) -r -f $(support)/get_type_attr_decl.sed
> comment_move_decl := $(SED) -r -f $(support)/comment_move_decl.sed
> @@ -547,11 +548,12 @@ install-docs: $(tmpdir)/html
> #
> # Install policy sources
> #
> -install-src:
> +install-src: $(fcsort)
> rm -rf $(srcpath)/policy.old
> -mv $(srcpath)/policy $(srcpath)/policy.old
> mkdir -p $(srcpath)/policy
> cp -R . $(srcpath)/policy
> + install tmp/fc_sort $(fcsortexe)
>
> ########################################
> #
> --- refpolicy-git-06082016-orig/Rules.modular 2016-08-06 21:26:43.257773849
> +0200
> +++ refpolicy-git-06082016/Rules.modular 2016-08-13 18:32:09.211057621 +0200
> @@ -174,8 +174,8 @@ $(tmpdir)/only_te_rules.conf: $(tmpdir)/
> #
> # Construct a base.fc
> #
> -$(base_fc): $(tmpdir)/$(notdir $(base_fc)).tmp $(fcsort)
> - $(verbose) $(fcsort) $< $@
> +$(base_fc): $(tmpdir)/$(notdir $(base_fc)).tmp $(fcsortexe)
> + $(verbose) $(fcsortexe) $< $@
>
> $(tmpdir)/$(notdir $(base_fc)).tmp: $(m4support)
> $(tmpdir)/generated_definitions.conf $(base_fc_files)
> ifeq ($(base_fc_files),)
> --- refpolicy-git-06082016-orig/Rules.monolithic 2016-08-06 21:26:43.258773860
> +0200
> +++ refpolicy-git-06082016/Rules.monolithic 2016-08-13 18:32:40.188493779 +0200
> @@ -168,8 +168,8 @@ enableaudit: $(policy_conf)
> #
> # Construct file_contexts
> #
> -$(fc): $(tmpdir)/$(notdir $(fc)).tmp $(fcsort)
> - $(verbose) $(fcsort) $< $@
> +$(fc): $(tmpdir)/$(notdir $(fc)).tmp $(fcsortexe)
> + $(verbose) $(fcsortexe) $< $@
> $(verbose) $(GREP) -e HOME -e ROLE -e USER $@ > $(homedir_template)
> $(verbose) $(SED) -i -e /HOME/d -e /ROLE/d -e /USER/d $@
>
--
Chris PeBenito