Discussion:
Please disable the SELinux execstack/relro checks before FC5 final
Arjan van de Ven
2006-02-17 10:42:41 UTC
Permalink
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
2006-02-17 11:28:43 UTC
Permalink
Post by 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.
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
2006-02-17 14:26:35 UTC
Permalink
Post by 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.
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
2006-02-17 14:43:18 UTC
Permalink
Post by Stephen Smalley
Post by 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.
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
- 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
2006-02-17 20:14:29 UTC
Permalink
Post by Stephen Smalley
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...
Ulrich Drepper
2006-02-18 02:48:59 UTC
Permalink
Post by Arjan van de Ven
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 ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060217/1e2ed599/attachment.bin
Eric Brunson
2006-02-19 17:48:00 UTC
Permalink
Post by Ulrich Drepper
Post by Arjan van de Ven
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
2006-02-19 18:01:58 UTC
Permalink
Post by Eric Brunson
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 ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060219/dc89c9f5/attachment.bin
Jim Cornette
2006-02-19 19:17:17 UTC
Permalink
Post by Ulrich Drepper
Post by Eric Brunson
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 at 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
Ivan Gyurdiev
2006-02-19 20:14:47 UTC
Permalink
Post by Jim Cornette
Post by Ulrich Drepper
Post by Eric Brunson
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.
Post by Jim Cornette
[jim at 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?
Post by Jim Cornette
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
2006-02-20 01:28:40 UTC
Permalink
Post by Ivan Gyurdiev
Post by Jim Cornette
Post by Ulrich Drepper
execstack -c /usr/lib*/libGL.so
This thread is totally confusing me....
- /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.
Post by 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:

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.
Post by Ivan Gyurdiev
Will do more testing, but the point is that it's not clear which libGL
library is causing the problem from this thread.
Post by Jim Cornette
[jim at 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 ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060219/87f430da/attachment.bin
Ivan Gyurdiev
2006-02-20 03:11:15 UTC
Permalink
Post by Ulrich Drepper
Post by 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
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...
Post by Ulrich Drepper
Post by Ivan Gyurdiev
Post by Jim Cornette
[jim at 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.
Ivan Gyurdiev
2006-02-20 03:11:15 UTC
Permalink
Post by Ulrich Drepper
Post by 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
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...
Post by Ulrich Drepper
Post by Ivan Gyurdiev
Post by Jim Cornette
[jim at 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
2006-02-20 01:28:40 UTC
Permalink
Post by Ivan Gyurdiev
Post by Jim Cornette
Post by Ulrich Drepper
execstack -c /usr/lib*/libGL.so
This thread is totally confusing me....
- /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.
Post by 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:

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.
Post by Ivan Gyurdiev
Will do more testing, but the point is that it's not clear which libGL
library is causing the problem from this thread.
Post by Jim Cornette
[jim at 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 ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060219/87f430da/attachment-0002.bin
Arjan van de Ven
2006-02-19 20:00:39 UTC
Permalink
Post by Jim Cornette
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
2006-02-19 22:57:47 UTC
Permalink
Post by Arjan van de Ven
Post by Jim Cornette
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 at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Ulrich Drepper
2006-02-20 01:29:51 UTC
Permalink
Post by Chris Adams
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 ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060219/8860f7d7/attachment.bin
Chris Adams
2006-02-20 01:41:58 UTC
Permalink
Post by Ulrich Drepper
Post by Chris Adams
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.html

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 at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Chris Adams
2006-02-20 01:41:58 UTC
Permalink
Post by Ulrich Drepper
Post by Chris Adams
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.html

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 at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Ulrich Drepper
2006-02-20 01:29:51 UTC
Permalink
Post by Chris Adams
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 ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060219/8860f7d7/attachment-0002.bin
Jim Cornette
2006-02-20 03:39:12 UTC
Permalink
Post by Arjan van de Ven
Post by Jim Cornette
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
Chris Adams
2006-02-19 22:57:47 UTC
Permalink
Post by Arjan van de Ven
Post by Jim Cornette
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 at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Jim Cornette
2006-02-20 03:39:12 UTC
Permalink
Post by Arjan van de Ven
Post by Jim Cornette
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
Ulrich Drepper
2006-02-20 01:23:00 UTC
Permalink
Post by Jim Cornette
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 ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060219/cfdd817c/attachment.bin
Ivan Gyurdiev
2006-02-19 20:14:47 UTC
Permalink
Post by Jim Cornette
Post by Ulrich Drepper
Post by Eric Brunson
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.
Post by Jim Cornette
[jim at 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?
Post by Jim Cornette
I take it that there are many more instances around.
Yes, I would expect to see problems with binaries that link to libGL...
Arjan van de Ven
2006-02-19 20:00:39 UTC
Permalink
Post by Jim Cornette
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 ?
Ulrich Drepper
2006-02-20 01:23:00 UTC
Permalink
Post by Jim Cornette
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 ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060219/cfdd817c/attachment-0002.bin
Jim Cornette
2006-02-19 19:17:17 UTC
Permalink
Post by Ulrich Drepper
Post by Eric Brunson
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 at 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
Ulrich Drepper
2006-02-19 18:01:58 UTC
Permalink
Post by Eric Brunson
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 ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060219/dc89c9f5/attachment-0002.bin
Ivan Gyurdiev
2006-02-19 18:20:40 UTC
Permalink
Post by Ulrich Drepper
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
2006-02-19 18:37:01 UTC
Permalink
Post by 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
2006-02-20 20:52:02 UTC
Permalink
Post by Ivan Gyurdiev
Post by Ulrich Drepper
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.
Post by Ivan Gyurdiev
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
2006-02-20 20:55:38 UTC
Permalink
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
Daniel J Walsh
2006-02-20 20:55:38 UTC
Permalink
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

Ivan Gyurdiev
2006-02-19 18:37:01 UTC
Permalink
Post by 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
2006-02-20 20:52:02 UTC
Permalink
Post by Ivan Gyurdiev
Post by Ulrich Drepper
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.
Post by Ivan Gyurdiev
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.
Eric Brunson
2006-02-19 17:48:00 UTC
Permalink
Post by Ulrich Drepper
Post by Arjan van de Ven
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?
Ivan Gyurdiev
2006-02-19 18:20:40 UTC
Permalink
Post by Ulrich Drepper
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.
Ulrich Drepper
2006-02-18 02:48:59 UTC
Permalink
Post by Arjan van de Ven
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 ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060217/1e2ed599/attachment-0002.bin
Arjan van de Ven
2006-02-17 20:14:29 UTC
Permalink
Post by Stephen Smalley
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...
Arjan van de Ven
2006-02-17 20:12:23 UTC
Permalink
Post by Stephen Smalley
Post by 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.
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
Post by Stephen Smalley
- execstack obviously
- execheap?
that needs to be treated the same as execstack; permissive by default
Post by Stephen Smalley
- 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)
Stephen Smalley
2006-02-17 14:43:18 UTC
Permalink
Post by Stephen Smalley
Post by 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.
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
- 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
2006-02-17 20:12:23 UTC
Permalink
Post by Stephen Smalley
Post by 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.
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
Post by Stephen Smalley
- execstack obviously
- execheap?
that needs to be treated the same as execstack; permissive by default
Post by Stephen Smalley
- 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)
Steve G
2006-02-17 21:03:12 UTC
Permalink
Post by Arjan van de Ven
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
Arjan van de Ven
2006-02-17 10:42:41 UTC
Permalink
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
2006-02-17 11:28:43 UTC
Permalink
Post by 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.
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
2006-02-17 14:26:35 UTC
Permalink
Post by 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.
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
Steve G
2006-02-17 21:03:12 UTC
Permalink
Post by Arjan van de Ven
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
Loading...