From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id u8GIvIrJ029499 for ; Fri, 16 Sep 2016 14:57:20 -0400 Received: by mail-qk0-f181.google.com with SMTP id z190so97108921qkc.3 for ; Fri, 16 Sep 2016 11:57:16 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <77ceec87-5ce6-c7f6-9620-bf2ac045f21c@tycho.nsa.gov> References: <1473948269-143019-1-git-send-email-jdanis@android.com> <25614fcd-20d5-c8ed-2d8a-7f47ae7938de@tycho.nsa.gov> <20160916133146.GA8294@meriadoc.perfinion.com> <77ceec87-5ce6-c7f6-9620-bf2ac045f21c@tycho.nsa.gov> From: Janis Danisevskis Date: Fri, 16 Sep 2016 19:57:15 +0100 Message-ID: Subject: Re: [PATCH] libselinux: add support for pcre2 To: Stephen Smalley Cc: Jason Zaman , William Roberts , Janis Danisevskis , "seandroid-list@tycho.nsa.gov" , "selinux@tycho.nsa.gov" Content-Type: multipart/alternative; boundary=001a11488a42e6c70c053ca48775 List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --001a11488a42e6c70c053ca48775 Content-Type: text/plain; charset=UTF-8 I have started implementing an arch string patch. Unfortunately, i did not manage to finish it before I had to leave the office today. In essence I did this: The regex_arch_string has three components: the pointer width determined by sizeof(void*), PCRE2_SIZE width determined by sizeof(), and endianess determined by __BYTE_ORDER__==__ORDER_BIG/LITTEL_ENDIAN__ For example, the resulting string for x86_64 and aarch64el should look like this: "8-8-el". I bumped the compiled context version number and added the string right after the version in the output. Comments? On Fri, Sep 16, 2016 at 3:52 PM, Stephen Smalley wrote: > On 09/16/2016 09:31 AM, Jason Zaman wrote: > > On Fri, Sep 16, 2016 at 06:15:01AM -0700, William Roberts wrote: > >> On Fri, Sep 16, 2016 at 6:09 AM, Janis Danisevskis > wrote: > >>> I don't mind. Then before sefcontext_compile -r gets widely adapted we > >>> should change the semantic quickly. I'll prepare a patch. > >> > >> Did I miss something and this was merged? Iv'e been out recovering > >> from a surgery so I haven't been > >> following this as well as I normally would have, > >> > >> If its merged, just leave it. > > > > Its the very latest thing in master yeah, but I do also agree with > changing it. > > > > I just wanted to add that from a distro perspective, compiling things by > > default makes more sense. In gentoo, the package post_install runs > > sefcontext_compile. Using the fcontext files happens a lot more than any > > updates to libselinux (and thus potential format changes) so I'm pretty > > sure most people would prefer to have the speedup. > > > > Gentoo does it on the machine itself, I am not sure about redhat or > > debian but I wouldnt be surprised if they do it per-arch at the very > > least so cross-arch probably isnt an issue. > > In Red Hat, SELinux policy is noarch, and they switched to precompiling > both policy and file_contexts.bin at build time to minimize the cost at > package install time. Otherwise, in small VMs, they had issues with > running out of memory during semodule -B. So file_contexts.bin > presently has to be arch-independent, or we need the arch properties > detection logic and fallback. That said, none of this matters unless > you build with USE_PCRE2=y, and no one outside of Android is doing that > today. > > > Also, I think we should add the arch to the version string stored. I > > would rather have false negatives than positives especially since we are > > not 100% sure exactly what part of the arch is important. We can always > > loosen it up later if that gets locked down. > > We don't want the arch string itself, because that would invalidate use > of file_contexts.bin entirely on typical Android use cases (build on > x86_64, install to ARM), but only the relevant properties. And for > Android, that is fatal - there is no file_contexts text file on which to > fallback anymore. They only ship file_contexts.bin. > > --001a11488a42e6c70c053ca48775 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have started implementing an arch string patch. Unfortun= ately, i did
not manage to finish it before I had to leave the office t= oday.
In essence I did this:
The regex_arch_string has = three components: the pointer width determined
by sizeof(void*), = PCRE2_SIZE width determined by sizeof(), and
endianess determined= by
__BYTE_ORDER__=3D=3D__ORDER_BIG/LITTEL_ENDIAN__
For example, the resulting string for x86_64 and aarch64el shou= ld look like
this: "8-8-el".

I= bumped the compiled context version number and added the string
= right after the version in the output.
Comments?


On Fri,= Sep 16, 2016 at 3:52 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
On 09/16/2016 0= 9:31 AM, Jason Zaman wrote:
> On Fri, Sep 16, 2016 at 06:15:01AM -0700, William Roberts wrote:
>> On Fri, Sep 16, 2016 at 6:09 AM, Janis Danisevskis <jdanis@google.com> wrote:
>>> I don't mind. Then before sefcontext_compile -r gets widel= y adapted we
>>> should change the semantic quickly. I'll prepare a patch.<= br> >>
>> Did I miss something and this was merged? Iv'e been out recove= ring
>> from a surgery so I haven't been
>> following this as well as I normally would have,
>>
>> If its merged, just leave it.
>
> Its the very latest thing in master yeah, but I do also agree with cha= nging it.
>
> I just wanted to add that from a distro perspective, compiling things = by
> default makes more sense. In gentoo, the package post_install runs
> sefcontext_compile. Using the fcontext files happens a lot more than a= ny
> updates to libselinux (and thus potential format changes) so I'm p= retty
> sure most people would prefer to have the speedup.
>
> Gentoo does it on the machine itself, I am not sure about redhat or > debian but I wouldnt be surprised if they do it per-arch at the very > least so cross-arch probably isnt an issue.

In Red Hat, SELinux policy is noarch, and they switched to precompil= ing
both policy and file_contexts.bin at build time to minimize the cost at
package install time.=C2=A0 Otherwise, in small VMs, they had issues with running out of memory during semodule -B.=C2=A0 So file_contexts.bin
presently has to be arch-independent, or we need the arch properties
detection logic and fallback.=C2=A0 That said, none of this matters unless<= br> you build with USE_PCRE2=3Dy, and no one outside of Android is doing that today.

> Also, I think we should add the arch to the version string stored. I > would rather have false negatives than positives especially since we a= re
> not 100% sure exactly what part of the arch is important. We can alway= s
> loosen it up later if that gets locked down.

We don't want the arch string itself, because that would invalid= ate use
of file_contexts.bin entirely on typical Android use cases (build on
x86_64, install to ARM), but only the relevant properties.=C2=A0 And for Android, that is fatal - there is no file_contexts text file on which to fallback anymore.=C2=A0 They only ship file_contexts.bin.


--001a11488a42e6c70c053ca48775--