Please disable the SELinux execstack/relro checks before FC5 final

[Arjan van de Ven]

Hi,

I'm hereby asking to disable/remove the SELinux execstack/relro checks
before FC5 ships. The current state of affairs will only lead to people
using big-hammer approaches in disabling selinux or big chunks thereof
(based on "solutions" they find with google), which is worse than not
having this protection in the first place.

The technology is not finished yet. What I can imagine being useful is:
1) having the security config tool do a scan for libs/binaries that are
not labeled correctly yet and present a dialog to add permissions,
including an explanation of what the consequences are
2) a dbus message on failure so that the desktop can pop up a "<this
application> tried to use <this insecure library> which is most likely a
security risk. In case you downloaded this plugin deliberately, make
sure you want this" or something

As it is right now, it's just one more thing people will just disable
and hate selinux more for.

[David Nielsen]

fre, 17 02 2006 kl. 11:42 +0100, skrev Arjan van de Ven:
>  Hi,
>  
>  I'm hereby asking to disable/remove the SELinux execstack/relro checks
>  before FC5 ships. The current state of affairs will only lead to people
>  using big-hammer approaches in disabling selinux or big chunks thereof
>  (based on "solutions" they find with google), which is worse than not
>  having this protection in the first place.
>  
>  The technology is not finished yet. What I can imagine being useful is:
>  1) having the security config tool do a scan for libs/binaries that are
>  not labeled correctly yet and present a dialog to add permissions,
>  including an explanation of what the consequences are
>  2) a dbus message on failure so that the desktop can pop up a "<this
>  application> tried to use <this insecure library> which is most likely a
>  security risk. In case you downloaded this plugin deliberately, make
>  sure you want this" or something
>  
>  As it is right now, it's just one more thing people will just disable
>  and hate selinux more for.   

I tend to agree, it's a great feature but we need better handling of it
- I assume the plan is to enable it early in the FC6 cycle again then?

- David
-- 
Obligatory shameless blog plug - the GNOME commentary located at:
www.lovesunix.net/blog

[Stephen Smalley]

On Fri, 2006-02-17 at 11:42 +0100, Arjan van de Ven wrote:
>  Hi,
>  
>  I'm hereby asking to disable/remove the SELinux execstack/relro checks
>  before FC5 ships. The current state of affairs will only lead to people
>  using big-hammer approaches in disabling selinux or big chunks thereof
>  (based on "solutions" they find with google), which is worse than not
>  having this protection in the first place.
>  
>  The technology is not finished yet. What I can imagine being useful is:
>  1) having the security config tool do a scan for libs/binaries that are
>  not labeled correctly yet and present a dialog to add permissions,
>  including an explanation of what the consequences are
>  2) a dbus message on failure so that the desktop can pop up a "<this
>  application> tried to use <this insecure library> which is most likely a
>  security risk. In case you downloaded this plugin deliberately, make
>  sure you want this" or something
>  
>  As it is right now, it's just one more thing people will just disable
>  and hate selinux more for.   
Can you clarify exactly what you want here?  I assume you mean just
allow-by-default, i.e. just enable booleans in the policy by default to
allow these permissions while still giving people the option to disable
them if they wish.  And what exact permissions are in view here:
- execstack obviously
- execheap?
- execmod?  If so, to all file types under one boolean setting, and only
to texrel_shlib_t under the opposite setting?
- execmem?  

-- 
Stephen Smalley
National Security Agency

[Stephen Smalley]

On Fri, 2006-02-17 at 09:26 -0500, Stephen Smalley wrote:
>  On Fri, 2006-02-17 at 11:42 +0100, Arjan van de Ven wrote:
>  > Hi,
>  > 
>  > I'm hereby asking to disable/remove the SELinux execstack/relro checks
>  > before FC5 ships. The current state of affairs will only lead to people
>  > using big-hammer approaches in disabling selinux or big chunks thereof
>  > (based on "solutions" they find with google), which is worse than not
>  > having this protection in the first place.
>  > 
>  > The technology is not finished yet. What I can imagine being useful is:
>  > 1) having the security config tool do a scan for libs/binaries that are
>  > not labeled correctly yet and present a dialog to add permissions,
>  > including an explanation of what the consequences are
>  > 2) a dbus message on failure so that the desktop can pop up a "<this
>  > application> tried to use <this insecure library> which is most likely a
>  > security risk. In case you downloaded this plugin deliberately, make
>  > sure you want this" or something
>  > 
>  > As it is right now, it's just one more thing people will just disable
>  > and hate selinux more for.  
>  
>  Can you clarify exactly what you want here?  I assume you mean just
>  allow-by-default, i.e. just enable booleans in the policy by default to
>  allow these permissions while still giving people the option to disable
>  them if they wish.  And what exact permissions are in view here:
>  - execstack obviously
>  - execheap?
>  - execmod?  If so, to all file types under one boolean setting, and only
>  to texrel_shlib_t under the opposite setting?
>  - execmem?   
Another question is what domains are in view here, e.g. all domains
(such that allow_execstack permits execstack to every process rather
than just unconfined processes) or just unconfined_t (so that confined
daemons remain protected even if allow_execstack is enabled)?

-- 
Stephen Smalley
National Security Agency

[Arjan van de Ven]

>  Another question is what domains are in view here, e.g. all domains
>  (such that allow_execstack permits execstack to every process rather
>  than just unconfined processes) or just unconfined_t (so that confined
>  daemons remain protected even if allow_execstack is enabled)? 
right now I fear the only sane answer is "set all to permissive
behavior"; the minimum for fc5 would be everything that can do plugins
of any kind, or uses libraries that tend to get replaced (3D ones ;).
But that ends up being a whole whopping lot...

I really wish the user notification/config thing existed, but that will
take time to get right for sure...

[Steve G]

> I really wish the user notification/config thing existed, but that
> will
> take time to get right for sure... 
I've been planning to make this a plugin to the audit event dispatcher. All the
hooks are there so that it could be written today. I can help out with the event
identification piece and getting it into dbus, but need someone else to do the
GUI side of it.

-Steve

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[Ulrich Drepper]

Arjan van de Ven wrote:
>  right now I fear the only sane answer is "set all to permissive
>  behavior"; the minimum for fc5 would be everything that can do plugins
>  of any kind, or uses libraries that tend to get replaced (3D ones ;).
>  But that ends up being a whole whopping lot... 
I'm not so sure.

The most crappy software are all those mozilla/firefox/thunderbird
plugins.  So, yes, we might need more time for that although I'd rather
prefer to have a separate domain for those programs.

The NVidia driver also needs an executable stack but nothing else.

What I have not seen are programs which have their own domain and still
need any of the booleans set.  Somebody should show real evidence that
any of those domains need the permission checks disable.

If we cannot move the moz/ffox/tbird into their own domain then, yes,
disable the checks for unconfined processes.  But we should keep the
tests for all programs which have their own domain.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

[Eric Brunson]

Ulrich Drepper wrote:
>  Arjan van de Ven wrote:
>    
> > right now I fear the only sane answer is "set all to permissive
> > behavior"; the minimum for fc5 would be everything that can do plugins
> > of any kind, or uses libraries that tend to get replaced (3D ones ;).
> > But that ends up being a whole whopping lot...
> >     
>
>  I'm not so sure.
>
>  The most crappy software are all those mozilla/firefox/thunderbird
>  plugins.  So, yes, we might need more time for that although I'd rather
>  prefer to have a separate domain for those programs.
>
>  The NVidia driver also needs an executable stack but nothing else.
>
>  What I have not seen are programs which have their own domain and still
>  need any of the booleans set.  Somebody should show real evidence that
>  any of those domains need the permission checks disable.
>
>  If we cannot move the moz/ffox/tbird into their own domain then, yes,
>  disable the checks for unconfined processes.  But we should keep the
>  tests for all programs which have their own domain.
>
>     
This NVidia driver issue seems to be cropping up a lot on the forums.  
Is there a fix for it other than setting permissive globally?

[Ulrich Drepper]

Eric Brunson wrote:
>  This NVidia driver issue seems to be cropping up a lot on the forums.
>
>  Is there a fix for it other than setting permissive globally? 
Has anybody ever tried to simply reset the flag?  Use

execstack -c /usr/lib*/libGL.so

If you want, make a copy of the file first.  But it should also be
possible to use

execstack -s /usr/lib*/libGL.so

to undo the effect.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

[Jim Cornette]

Ulrich Drepper wrote:
>  Eric Brunson wrote:
> > This NVidia driver issue seems to be cropping up a lot on the forums. 
> > Is there a fix for it other than setting permissive globally?
>  
>  Has anybody ever tried to simply reset the flag?  Use
>  
>  execstack -c /usr/lib*/libGL.so
>  
>  If you want, make a copy of the file first.  But it should also be
>  possible to use
>  
>  execstack -s /usr/lib*/libGL.so
>  
>  to undo the effect.
>  
>   
The problem happens with fedora-extras programs also. Ppracer would not 
start before execstack -s was performed on the library. I ra

  ppracer
ppracer: error while loading shared libraries: libGL.so.1: cannot enable 
executable stack as shared object requires: Permission denied
[jim@cornette-lt ~]$ locate libGL.so.1
/usr/lib/libGL.so.1
/usr/lib/libGL.so.1.2

  execstack -c /usr/lib/libGL.so.1 allowed ppracer to start. The 
performance was pretty poor though with a radeon and oss driver.

Section "Device"
         Identifier  "Videocard0"
         Driver      "radeon"
         VendorName  "Videocard vendor"
         BoardName   "ATI Technologies Inc Radeon Mobility U1"

I take it that there are many more instances around.

Thanks for the hint.

Jim

[Arjan van de Ven]

>  
>  The problem happens with fedora-extras programs also. Ppracer would not 
>  start before execstack -s was performed on the library. 
The fedora library or the ATI binary one ?

[Chris Adams]

Once upon a time, Arjan van de Ven <arjan(a)fenrus.demon.nl&gt; said:
>  > The problem happens with fedora-extras programs also. Ppracer
> would not 
>  > start before execstack -s was performed on the library.
>  
>  The fedora library or the ATI binary one ? 
I get that with a straight Fedora install.  Do a basic install and then
"yum install ppracer", and ppracer will fail to start.

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Ulrich Drepper]

Chris Adams wrote:
>  I get that with a straight Fedora install.  Do a basic install and
> then
>  "yum install ppracer", and ppracer will fail to start. 
This doesn't say anything.  How does it fail?  What DSOs are loaded?
How do the DSOs look like (output of eu-readelf -l DSO).

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

[Chris Adams]

Once upon a time, Ulrich Drepper <drepper(a)redhat.com&gt; said:
>  Chris Adams wrote:
>  > I get that with a straight Fedora install.  Do a basic install and then
>  > "yum install ppracer", and ppracer will fail to start.
>  
>  This doesn't say anything.  How does it fail?  What DSOs are loaded?
>  How do the DSOs look like (output of eu-readelf -l DSO). 
Well, it had resulted in an exec stack error on libGL (last tried a week
or so ago IIRC).  However, with a up to date devel (Core and Extras)
system, ppracer starts now.

You can see the message that did result a couple messages up this
thread:

https://www.redhat.com/archives/fedora-devel-list/2006-February/msg00919....

Checking, my system seems to show libGL.so.1.2 marked for execstack on
install now:

$ execstack -q /usr/lib/libGL.so.1.2
X /usr/lib/libGL.so.1.2

I'm pretty sure I didn't set it that way (on this install).
-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Jim Cornette]

Arjan van de Ven wrote:
> > The problem happens with fedora-extras programs also. Ppracer
> would not 
> > start before execstack -s was performed on the library.
>  
>  The fedora library or the ATI binary one ?
>  
>   
The Fedora Library and not the ATI binary. (3D does not work well at all.)
  The ppracer game worked recently when I let a child play the game 
before the massive rebuild. I don't know exactly when it quit working

Before performing execstack -c /usr/lib/libGL.so.1  ppcracer would error 
out and not launch.

I have mesa-libGL-6.4.2-2.1 installed and it verifies with rpm.


Jim

[Ivan Gyurdiev]

> >> This NVidia driver issue seems to be cropping up a lot on the
>
> >> forums. Is there a fix for it other than setting permissive globally?
> >
> > Has anybody ever tried to simply reset the flag?  Use
> >
> > execstack -c /usr/lib*/libGL.so 
This thread is totally confusing me....
I haven't been following exactly what's going on with this problem, but:
- /usr/lib*/libGL.so.1 is the Mesa GL library
- /usr/lib*/nvidia/libGL.so.1 is the Nvidia GL library, when properly 
installed via livna

On my computer both are marked GNU_STACK RWE, which seems relevant to 
this problem (correct me if that's not true), so I'm not sure why Nvidia 
is being blamed, and Mesa is not. This is x86_64.

- I get denials attempting to execute /dev/zero, exectstack, and execmem 
for glxgears with the Nvidia driver.
- I tried testing with the nv driver, but it crashed after I restarted X 
a few times, so I think selinux is not the primary problem when it comes 
to this driver. I'm running back to the "stable" nvidia driver [ even 
though it crashes on suspend ] :)

Will do more testing, but the point is that it's not clear which libGL 
library is causing the problem from this thread.
>  [jim@cornette-lt ~]$ locate libGL.so.1
>  /usr/lib/libGL.so.1
>  /usr/lib/libGL.so.1.2 
Doesn't this indicate the Mesa libGL library, and not the
Nvidia or ATI one?

>  I take it that there are many more instances around.
>  
Yes, I would expect to see problems with binaries that link to libGL...

[Ulrich Drepper]

Ivan Gyurdiev wrote:
> >> execstack -c /usr/lib*/libGL.so
>  This thread is totally confusing me....
>  I haven't been following exactly what's going on with this problem, but:
>  - /usr/lib*/libGL.so.1 is the Mesa GL library
>  - /usr/lib*/nvidia/libGL.so.1 is the Nvidia GL library, when properly
>  installed via livna
>  
>  On my computer both are marked GNU_STACK RWE, which seems relevant to
>  this problem (correct me if that's not true), so I'm not sure why Nvidia
>  is being blamed, and Mesa is not. This is x86_64. 
Don't assume the filesystem layout is the same on all machines.  For me,
the /usr/lib*/libGL.so files are the NVidia files.  This is why I
mentioned the command line above.

Whether the Mesa libraries have the same issue is another issue which
somebody might want to investigate.

I think what follows from the results I"ve seen so far is that it is
only a build problem on the NVidia driver's side that the E bit is set
and that it is safe to clear the bit using the execstack command.


>  - I get denials attempting to execute /dev/zero, exectstack, and
> execmem
>  for glxgears with the Nvidia driver. 
Do you have the DSO marked with textrel_shlib_t?  That'll always be
necessary.  Look at the driver:

  Type           Offset   VirtAddr           PhysAddr           FileSiz
 MemSiz   Flg Align
  LOAD           0x000000 0x0000003fe9900000 0x0000003fe9900000 0x081258
0x081258 R E 0x100000
  LOAD           0x081260 0x0000003fe9a81260 0x0000003fe9a81260 0x02fda0
0x0318c0 RWE 0x100000
  DYNAMIC        0x0b02b8 0x0000003fe9ab02b8 0x0000003fe9ab02b8 0x000200
0x000200 RW  0x8
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000
0x000000 RWE 0x8

 Section to Segment mapping:
  Segment Sections...
   00      [RO: .hash .dynsym .dynstr .gnu.version .gnu.version_r
.rela.dyn .rela.plt .plt .text .rodata]
   01      .data .writetext .eh_frame .dynamic .got .bss
   02      .dynamic
   03


They deliberately create a text section which is writable
(.data.writetext).  That segment must be writable.



>  Will do more testing, but the point is that it's not clear which
> libGL
>  library is causing the problem from this thread.
> > [jim@cornette-lt ~]$ locate libGL.so.1
> > /usr/lib/libGL.so.1
> > /usr/lib/libGL.so.1.2
>  Doesn't this indicate the Mesa libGL library, and not the Nvidia or ATI
>  one? 
That completely depends on how things are installed on your machine.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

[Ivan Gyurdiev]

> > - I get denials attempting to execute /dev/zero, exectstack, and
> execmem
> > for glxgears with the Nvidia driver.
> >     
>
>  Do you have the DSO marked with textrel_shlib_t?  That'll always be
>  necessary.  Look at the driver:
>
>     
Yes, both my Mesa libGL and the nvidia one are marked textrel_shlib_t.
Marking things textrel_shlib_t has no effect on execstack/execmem - it 
only suppresses execmod denials.

Actually I seem to get a different error than the other posters in 
enforcing mode:
glxgears: error while loading shared libraries: libGL.so.1: failed to 
map segment from shared object: Permission denied

This is strict policy btw, it's rather broken...

> >> [jim@cornette-lt ~]$ locate libGL.so.1
> >> /usr/lib/libGL.so.1
> >> /usr/lib/libGL.so.1.2
> >>       
> > Doesn't this indicate the Mesa libGL library, and not the Nvidia or ATI
> > one?
> >     
>
>  That completely depends on how things are installed on your machine.
>     
The version numbering indicate likely Mesa libGL.
The poster mentioned oss drivers, and radeon card.
I find it highly unlikely you are talking about the same thing.

[Ulrich Drepper]

Jim Cornette wrote:
>   execstack -c /usr/lib/libGL.so.1 allowed ppracer to start. The
>  performance was pretty poor though with a radeon and oss driver. 
Let's not confuse things.  You say that wafter fixing up the NVidia
driver with execstack -c it works?  The same as it would after disabling
enforcement?  That's the only thing important here.  Whether there are
other problems re speed etc should be brought up separately.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

[Ivan Gyurdiev]

>  If we cannot move the moz/ffox/tbird into their own domain then,
> yes,
>  disable the checks for unconfined processes.  But we should keep the
>  tests for all programs which have their own domain.
>     
Moz/ffox/tbird cannot be moved into their own domain until we have the 
capability to launch content handling applications from within firefox, 
and have them enter the proper domain. This is particularly difficult, 
because some of those applications (i.e. openoffice) don't have a domain 
at the moment (and creating one would be difficult). That means firefox 
must be allowed to transition into user_t/unconfined_t, which defeats 
any attempt at security. Launching one application within another is the 
primary reason why the desktop can't be confined.

In the old strict policy firefox and mozilla were confined, and I worked 
on the evolution and thunderbird policies over the summer. I think the 
basic functionality was working, but those programs could not be allowed 
to launch other apps. We need a trusted program to be responsible for 
that, so that firefox can't transition into the generic domain.

There's other problems as well, including limiting those programs' 
ability to write to the user home directory, and the top level /tmp 
directory (what good does confining an application do, if it can still 
overwrite all your important files, or steal your credit card info?). 
There's marking of content as potentially hostile, and management of 
that content.

There's an effort to limit bonobo connections from firefox to restricted 
domains only (no user_t/unconfined_t connections).... also challenging, 
because there's so many things firefox talks to, and one of them is 
sufficient to necessitate allowing communications channel to 
user_t/unconfined_t.

=============

Currently the firefox/moz/tbird/evolution policies have not been ported 
yet to the new refpolicy.  They also require  the policies for bonobo, 
orbit, gnome and other dekstop-related things (also not yet ported). 
Even when they are ported, I doubt they would meet the needs of 
targeted-policy users.

[Ivan Gyurdiev]

>  There's an effort to limit bonobo connections from firefox to 
>  restricted domains only (no user_t/unconfined_t connections).... also 
>  challenging, because there's so many things firefox talks to, and one 
>  of them is sufficient to necessitate allowing communications channel 
>  to user_t/unconfined_t. 
Isn't bonobo capable of doing exactly what we need
anyway - launching 
applications based on required characteristics sent over a socket to its 
server? Maybe I'm ignorant of how those things work, but having a 
centralized way to launch other apps (from a different process than our 
own) would be very helpful to selinux.

[Daniel J Walsh]

Ivan Gyurdiev wrote:
> > If we cannot move the moz/ffox/tbird into their own domain then, yes,
> > disable the checks for unconfined processes.  But we should keep the
> > tests for all programs which have their own domain.
> >   
>  Moz/ffox/tbird cannot be moved into their own domain until we have the 
>  capability to launch content handling applications from within 
>  firefox, and have them enter the proper domain. This is particularly 
>  difficult, because some of those applications (i.e. openoffice) don't 
>  have a domain at the moment (and creating one would be difficult). 
>  That means firefox must be allowed to transition into 
>  user_t/unconfined_t, which defeats any attempt at security. Launching 
>  one application within another is the primary reason why the desktop 
>  can't be confined. 
That is not entirely true.  java, wine and mono all run in
their own 
domain in targeted which is unconfined.  I could do similar for
thunderbird, firefox and freinds.  We are not trying to confine these 
apps, but trying to confine the exec* apps to as few as possible.

>  In the old strict policy firefox and mozilla were confined, and I 
>  worked on the evolution and thunderbird policies over the summer. I 
>  think the basic functionality was working, but those programs could 
>  not be allowed to launch other apps. We need a trusted program to be 
>  responsible for that, so that firefox can't transition into the 
>  generic domain.
>
>  There's other problems as well, including limiting those programs' 
>  ability to write to the user home directory, and the top level /tmp 
>  directory (what good does confining an application do, if it can still 
>  overwrite all your important files, or steal your credit card info?). 
>  There's marking of content as potentially hostile, and management of 
>  that content.
>
>  There's an effort to limit bonobo connections from firefox to 
>  restricted domains only (no user_t/unconfined_t connections).... also 
>  challenging, because there's so many things firefox talks to, and one 
>  of them is sufficient to necessitate allowing communications channel 
>  to user_t/unconfined_t.
>
>  =============
>
>  Currently the firefox/moz/tbird/evolution policies have not been 
>  ported yet to the new refpolicy.  They also require  the policies for 
>  bonobo, orbit, gnome and other dekstop-related things (also not yet 
>  ported). Even when they are ported, I doubt they would meet the needs 
>  of targeted-policy users.

[Daniel J Walsh]

Anyways I think I will go with allow_execmem allow_execstack for FC5 on 
by default, all confined domains will not have this ability.  For FC6 we 
will turn them off again but add a new unconfined type for 
firefox/thunderbird/evolution and freinds which will
only allow them to use execstack.  When ever you find an library that 
requires these privs please bugzilla them.

Dan

[Arjan van de Ven]

On Fri, 2006-02-17 at 09:26 -0500, Stephen Smalley wrote:
>  On Fri, 2006-02-17 at 11:42 +0100, Arjan van de Ven wrote:
>  > Hi,
>  > 
>  > I'm hereby asking to disable/remove the SELinux execstack/relro checks
>  > before FC5 ships. The current state of affairs will only lead to people
>  > using big-hammer approaches in disabling selinux or big chunks thereof
>  > (based on "solutions" they find with google), which is worse than not
>  > having this protection in the first place.
>  > 
>  > The technology is not finished yet. What I can imagine being useful is:
>  > 1) having the security config tool do a scan for libs/binaries that are
>  > not labeled correctly yet and present a dialog to add permissions,
>  > including an explanation of what the consequences are
>  > 2) a dbus message on failure so that the desktop can pop up a "<this
>  > application> tried to use <this insecure library> which is most likely a
>  > security risk. In case you downloaded this plugin deliberately, make
>  > sure you want this" or something
>  > 
>  > As it is right now, it's just one more thing people will just disable
>  > and hate selinux more for.  
>  
>  Can you clarify exactly what you want here?  I assume you mean just
>  allow-by-default, i.e. just enable booleans in the policy by default to
>  allow these permissions while still giving people the option to disable
>  them if they wish. 
sure that's fair enough

>    And what exact permissions are in view here:
>  - execstack obviously
>  - execheap? 
that needs to be treated the same as execstack; permissive by default

>  - execmod?  If so, to all file types under one boolean setting, and
> only
>  to texrel_shlib_t under the opposite setting?
>  - execmem?   
all by default set to "allow" (and yes I would LOVE for it to be
otherwise, but right now it just isn't ready)