DISABLE_AVC=y

DISABLE_AVC=y

[William Roberts]

Does anyone actualy use this, this currently doesn't build:

compute_av.c: In function ‘security_compute_av_flags_raw’:
compute_av.c:65:28: error: suggest braces around empty body in an ‘if’
statement [-Werror=empty-body]
   map_decision(tclass, avd);
                            ^
cc1: all warnings being treated as errors
make[1]: *** [compute_av.o] Error 1

clude -D_GNU_SOURCE -DDISABLE_AVC   -c -o compute_av.o compute_av.c
compute_av.c: In function ‘security_compute_av_flags_raw’:
compute_av.c:65:28: error: expected expression before ‘;’ token
   map_decision(tclass, avd);
                            ^
make[1]: *** [compute_av.o] Error 1
make[1]: Leaving directory `/home/wc

Should we fix it or kill it off?

-- 
Respectfully,

William C Roberts

Re: DISABLE_AVC=y

[Stephen Smalley]

On 09/28/2016 10:39 AM, William Roberts wrote:
> Does anyone actualy use this, this currently doesn't build:
> 
> compute_av.c: In function ‘security_compute_av_flags_raw’:
> compute_av.c:65:28: error: suggest braces around empty body in an ‘if’
> statement [-Werror=empty-body]
>    map_decision(tclass, avd);
>                             ^
> cc1: all warnings being treated as errors
> make[1]: *** [compute_av.o] Error 1
> 
> clude -D_GNU_SOURCE -DDISABLE_AVC   -c -o compute_av.o compute_av.c
> compute_av.c: In function ‘security_compute_av_flags_raw’:
> compute_av.c:65:28: error: expected expression before ‘;’ token
>    map_decision(tclass, avd);
>                             ^
> make[1]: *** [compute_av.o] Error 1
> make[1]: Leaving directory `/home/wc
> 
> Should we fix it or kill it off?

I am not aware of any users of it; it is a legacy of some early work on
embedded SELinux but does not appear to be used in current solutions
(e.g. meta-selinux does not use it).  So I would just kill it.
Especially since the userspace AVC is used by many userspace programs
now in Linux and in Android.

Re: DISABLE_AVC=y

[William Roberts]

Same thing for DISABLE_BOOL, should that die or be fixed?

On Wed, Sep 28, 2016 at 10:58 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 09/28/2016 10:39 AM, William Roberts wrote:
>> Does anyone actualy use this, this currently doesn't build:
>>
>> compute_av.c: In function ‘security_compute_av_flags_raw’:
>> compute_av.c:65:28: error: suggest braces around empty body in an ‘if’
>> statement [-Werror=empty-body]
>>    map_decision(tclass, avd);
>>                             ^
>> cc1: all warnings being treated as errors
>> make[1]: *** [compute_av.o] Error 1
>>
>> clude -D_GNU_SOURCE -DDISABLE_AVC   -c -o compute_av.o compute_av.c
>> compute_av.c: In function ‘security_compute_av_flags_raw’:
>> compute_av.c:65:28: error: expected expression before ‘;’ token
>>    map_decision(tclass, avd);
>>                             ^
>> make[1]: *** [compute_av.o] Error 1
>> make[1]: Leaving directory `/home/wc
>>
>> Should we fix it or kill it off?
>
> I am not aware of any users of it; it is a legacy of some early work on
> embedded SELinux but does not appear to be used in current solutions
> (e.g. meta-selinux does not use it).  So I would just kill it.
> Especially since the userspace AVC is used by many userspace programs
> now in Linux and in Android.
>



-- 
Respectfully,

William C Roberts

Re: DISABLE_AVC=y

[Stephen Smalley]

On 09/28/2016 11:00 AM, William Roberts wrote:
> Same thing for DISABLE_BOOL, should that die or be fixed?

Would that be useful for the Android device/target build, since they
don't support booleans?

I don't believe there are any users of EMBEDDED=y.  DISABLE_SETRANS=y
and DISABLE_BOOL=y may make sense for Android (host and target builds).
DISABLE_RPM is enabled in Fedora/RHEL now because they have updated rpm
to use the more general setexecfilecon() interface introduced to support
other package managers.  So we may want to even make DISABLE_RPM=y the
default.  Technically that is an ABI break but since Red Hat is already
shipping it that way and rpm has been updated, I'm not sure it matters.

> 
> On Wed, Sep 28, 2016 at 10:58 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On 09/28/2016 10:39 AM, William Roberts wrote:
>>> Does anyone actualy use this, this currently doesn't build:
>>>
>>> compute_av.c: In function ‘security_compute_av_flags_raw’:
>>> compute_av.c:65:28: error: suggest braces around empty body in an ‘if’
>>> statement [-Werror=empty-body]
>>>    map_decision(tclass, avd);
>>>                             ^
>>> cc1: all warnings being treated as errors
>>> make[1]: *** [compute_av.o] Error 1
>>>
>>> clude -D_GNU_SOURCE -DDISABLE_AVC   -c -o compute_av.o compute_av.c
>>> compute_av.c: In function ‘security_compute_av_flags_raw’:
>>> compute_av.c:65:28: error: expected expression before ‘;’ token
>>>    map_decision(tclass, avd);
>>>                             ^
>>> make[1]: *** [compute_av.o] Error 1
>>> make[1]: Leaving directory `/home/wc
>>>
>>> Should we fix it or kill it off?
>>
>> I am not aware of any users of it; it is a legacy of some early work on
>> embedded SELinux but does not appear to be used in current solutions
>> (e.g. meta-selinux does not use it).  So I would just kill it.
>> Especially since the userspace AVC is used by many userspace programs
>> now in Linux and in Android.
>>

Re: DISABLE_AVC=y

[William Roberts]

On Wed, Sep 28, 2016 at 11:10 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 09/28/2016 11:00 AM, William Roberts wrote:
>> Same thing for DISABLE_BOOL, should that die or be fixed?
>
> Would that be useful for the Android device/target build, since they
> don't support booleans?

We don't compile the full source, thats how we avoid needing this,
booleans.c isn't included.

>
> I don't believe there are any users of EMBEDDED=y.  DISABLE_SETRANS=y
> and DISABLE_BOOL=y may make sense for Android (host and target builds).
> DISABLE_RPM is enabled in Fedora/RHEL now because they have updated rpm
> to use the more general setexecfilecon() interface introduced to support
> other package managers.  So we may want to even make DISABLE_RPM=y the
> default.  Technically that is an ABI break but since Red Hat is already
> shipping it that way and rpm has been updated, I'm not sure it matters.

Good to know, so I am looking at all of this in the context of we
don't accidentally want to install
with ANDROID_HOST=y. I'm thinking of something where we could write
the variables to
a .config file, and check for changes, if theirs a change, we could
force a clean, so you always
get what you want.

ie:
  $ make XXX=y
  $ make install

is always correct, for any given changes in build parameters, thoughts?

Re: DISABLE_AVC=y

[Stephen Smalley]

On 09/28/2016 11:13 AM, William Roberts wrote:
> On Wed, Sep 28, 2016 at 11:10 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On 09/28/2016 11:00 AM, William Roberts wrote:
>>> Same thing for DISABLE_BOOL, should that die or be fixed?
>>
>> Would that be useful for the Android device/target build, since they
>> don't support booleans?
> 
> We don't compile the full source, thats how we avoid needing this,
> booleans.c isn't included.
> 
>>
>> I don't believe there are any users of EMBEDDED=y.  DISABLE_SETRANS=y
>> and DISABLE_BOOL=y may make sense for Android (host and target builds).
>> DISABLE_RPM is enabled in Fedora/RHEL now because they have updated rpm
>> to use the more general setexecfilecon() interface introduced to support
>> other package managers.  So we may want to even make DISABLE_RPM=y the
>> default.  Technically that is an ABI break but since Red Hat is already
>> shipping it that way and rpm has been updated, I'm not sure it matters.
> 
> Good to know, so I am looking at all of this in the context of we
> don't accidentally want to install
> with ANDROID_HOST=y. I'm thinking of something where we could write
> the variables to
> a .config file, and check for changes, if theirs a change, we could
> force a clean, so you always
> get what you want.
> 
> ie:
>   $ make XXX=y
>   $ make install
> 
> is always correct, for any given changes in build parameters, thoughts?

I don't think we really need it.

There was work a long time ago on autotools support for selinux; you can
see that in the autotools branch.  But they never ran it to completion,
and I'm not really a fan of autotools anyway.

Re: DISABLE_AVC=y

[William Roberts]

On Wed, Sep 28, 2016 at 11:24 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 09/28/2016 11:13 AM, William Roberts wrote:
>> On Wed, Sep 28, 2016 at 11:10 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>> On 09/28/2016 11:00 AM, William Roberts wrote:
>>>> Same thing for DISABLE_BOOL, should that die or be fixed?
>>>
>>> Would that be useful for the Android device/target build, since they
>>> don't support booleans?
>>
>> We don't compile the full source, thats how we avoid needing this,
>> booleans.c isn't included.
>>
>>>
>>> I don't believe there are any users of EMBEDDED=y.  DISABLE_SETRANS=y
>>> and DISABLE_BOOL=y may make sense for Android (host and target builds).
>>> DISABLE_RPM is enabled in Fedora/RHEL now because they have updated rpm
>>> to use the more general setexecfilecon() interface introduced to support
>>> other package managers.  So we may want to even make DISABLE_RPM=y the
>>> default.  Technically that is an ABI break but since Red Hat is already
>>> shipping it that way and rpm has been updated, I'm not sure it matters.
>>
>> Good to know, so I am looking at all of this in the context of we
>> don't accidentally want to install
>> with ANDROID_HOST=y. I'm thinking of something where we could write
>> the variables to
>> a .config file, and check for changes, if theirs a change, we could
>> force a clean, so you always
>> get what you want.
>>
>> ie:
>>   $ make XXX=y
>>   $ make install
>>
>> is always correct, for any given changes in build parameters, thoughts?
>
> I don't think we really need it.
>
> There was work a long time ago on autotools support for selinux; you can
> see that in the autotools branch.  But they never ran it to completion,
> and I'm not really a fan of autotools anyway.

Me either, so whats your though then on ANDROID_HOST=y, is installing
it on accident a killer issue or
user be careful?

Re: DISABLE_AVC=y

[Stephen Smalley]

On 09/28/2016 11:32 AM, William Roberts wrote:
> On Wed, Sep 28, 2016 at 11:24 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On 09/28/2016 11:13 AM, William Roberts wrote:
>>> On Wed, Sep 28, 2016 at 11:10 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>> On 09/28/2016 11:00 AM, William Roberts wrote:
>>>>> Same thing for DISABLE_BOOL, should that die or be fixed?
>>>>
>>>> Would that be useful for the Android device/target build, since they
>>>> don't support booleans?
>>>
>>> We don't compile the full source, thats how we avoid needing this,
>>> booleans.c isn't included.
>>>
>>>>
>>>> I don't believe there are any users of EMBEDDED=y.  DISABLE_SETRANS=y
>>>> and DISABLE_BOOL=y may make sense for Android (host and target builds).
>>>> DISABLE_RPM is enabled in Fedora/RHEL now because they have updated rpm
>>>> to use the more general setexecfilecon() interface introduced to support
>>>> other package managers.  So we may want to even make DISABLE_RPM=y the
>>>> default.  Technically that is an ABI break but since Red Hat is already
>>>> shipping it that way and rpm has been updated, I'm not sure it matters.
>>>
>>> Good to know, so I am looking at all of this in the context of we
>>> don't accidentally want to install
>>> with ANDROID_HOST=y. I'm thinking of something where we could write
>>> the variables to
>>> a .config file, and check for changes, if theirs a change, we could
>>> force a clean, so you always
>>> get what you want.
>>>
>>> ie:
>>>   $ make XXX=y
>>>   $ make install
>>>
>>> is always correct, for any given changes in build parameters, thoughts?
>>
>> I don't think we really need it.
>>
>> There was work a long time ago on autotools support for selinux; you can
>> see that in the autotools branch.  But they never ran it to completion,
>> and I'm not really a fan of autotools anyway.
> 
> Me either, so whats your though then on ANDROID_HOST=y, is installing
> it on accident a killer issue or
> user be careful?

There is already a warning in selinux/README about the potential for a
break by installing over your system libraries, since that is possible
even aside from ANDROID_HOST=y.  So I think it is fine.  I wasn't
planning to even mention ANDROID_HOST=y in the README because it is
really only for maintainers, not users.