Hello,
With fedora 13, when I use Math:GSL, I get an error message: Can't load '/usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so' for module Math::GSL::Errno: /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so: cannot restore segment prot after reloc: Permission denied at /usr/lib/perl5/DynaLoader.pm line 200.
if I do not switch SELinux to permissive !!
IE I cannot use enforcing
Patrick Dupre wrote:
Hello,
With fedora 13, when I use Math:GSL, I get an error message: Can't load '/usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so' for module Math::GSL::Errno: /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so: cannot restore segment prot after reloc: Permission denied at /usr/lib/perl5/DynaLoader.pm line 200.
if I do not switch SELinux to permissive !!
Seems something you installed yourself that's running afoul of selinux, fedora doesn't install anything into /usr/local/... by default.
-- Rex
On Sun, 29 Aug 2010, Rex Dieter wrote:
Patrick Dupre wrote:
Hello,
With fedora 13, when I use Math:GSL, I get an error message: Can't load '/usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so' for module Math::GSL::Errno: /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so: cannot restore segment prot after reloc: Permission denied at /usr/lib/perl5/DynaLoader.pm line 200.
if I do not switch SELinux to permissive !!
Seems something you installed yourself that's running afoul of selinux, fedora doesn't install anything into /usr/local/... by default.
Of course, I NEED Math:GSL !!!!
Patrick Dupre wrote:
On Sun, 29 Aug 2010, Rex Dieter wrote:
Patrick Dupre wrote:
Hello,
With fedora 13, when I use Math:GSL, I get an error message: Can't load '/usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so' for module Math::GSL::Errno: /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so: cannot restore segment prot after reloc: Permission denied at /usr/lib/perl5/DynaLoader.pm line 200.
if I do not switch SELinux to permissive !!
Seems something you installed yourself that's running afoul of selinux, fedora doesn't install anything into /usr/local/... by default.
Of course, I NEED Math:GSL !!!!
OK, so... what's your point? Your original post seemed to be blaming selinux here, for something that's not testable (ie, supporting/testing something not included in fedora).
-- Rex
On 29/08/10 18:42, Rex Dieter wrote:
Patrick Dupre wrote:
On Sun, 29 Aug 2010, Rex Dieter wrote:
Patrick Dupre wrote:
Hello,
With fedora 13, when I use Math:GSL, I get an error message: Can't load '/usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so' for module Math::GSL::Errno: /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so: cannot restore segment prot after reloc: Permission denied at /usr/lib/perl5/DynaLoader.pm line 200.
if I do not switch SELinux to permissive !!
Seems something you installed yourself that's running afoul of selinux, fedora doesn't install anything into /usr/local/... by default.
Of course, I NEED Math:GSL !!!!
OK, so... what's your point? Your original post seemed to be blaming selinux here, for something that's not testable (ie, supporting/testing something not included in fedora).
I would advise Patrick to disable Selinux. I've made that decision long ago because it gives me more problems when enabled that I can possibly solve. IMHO the user interface is so bad that selinux is unuseable for an ordinary enduser.
On Sun, Aug 29, 2010 at 6:14 PM, Erik P. Olsen epodata@gmail.com wrote:
On 29/08/10 18:42, Rex Dieter wrote:
Patrick Dupre wrote:
On Sun, 29 Aug 2010, Rex Dieter wrote:
Patrick Dupre wrote:
Hello,
With fedora 13, when I use Math:GSL, I get an error message: Can't load '/usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so' for module Math::GSL::Errno: /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so: cannot restore segment prot after reloc: Permission denied at /usr/lib/perl5/DynaLoader.pm line 200.
if I do not switch SELinux to permissive !!
Seems something you installed yourself that's running afoul of selinux, fedora doesn't install anything into /usr/local/... by default.
Of course, I NEED Math:GSL !!!!
OK, so... what's your point? Your original post seemed to be blaming selinux here, for something that's not testable (ie, supporting/testing something not included in fedora).
I would advise Patrick to disable Selinux. I've made that decision long ago because it gives me more problems when enabled that I can possibly solve. IMHO the user interface is so bad that selinux is unuseable for an ordinary enduser.
With many selinux issues with a bit of effort and help from a few experts the issues can often be resolved - I have been running all my systems with selinux enforcing since F9 - and the additional protection is worth it. There are a few things from outside Fedora (like Crossover) that will only work in f13 with one selinux setting downgrading security but other than that I have no problem with any of the systems. The other thing that is worthwhile it actually reading the selinux guide and understanding how it ticks. That way you can often work around problems yourself with a bit of probing of the files and processes involved in an AVC denial.
There are some real experts around on this list and they are often ready to make suggestions from their significant knowledge base that is worthwhile listening to and by responding and working with them then more often than not the issues can be resolved.
On Sunday, 29 August, 2010 @17:14 zulu, Erik P. Olsen scribed:
I would advise Patrick to disable Selinux. I've made that decision long ago because it gives me more problems when enabled that I can possibly solve. IMHO the user interface is so bad that selinux is unuseable for an ordinary enduser.
Ummm... that's NOT good advice, in my honest opinion.
That's rather like telling someone to disable the windows firewall because it might stop them from using the chat rooms in AOL, and it's just "too complicated" for ordinary users to make the exceptions/open ports to run IRC instead.
From what I've seen, most SELinux hassles result from
doing too much from root access (i.e. when it could/should have been done from user-level access instead).
I would advise the OP to subscribe to the selinux list and be ready to post copies of the AVC denials when requested.
All probably true, but I dread the day they decide to make SELinux mandatory, and take away the ability to disable it (in the name of security).
On 08/29/2010 01:44 PM, mike cloaked wrote:
With many selinux issues with a bit of effort and help from a few experts the issues can often be resolved - I have been running all my systems with selinux enforcing since F9 - and the additional protection is worth it. There are a few things from outside Fedora (like Crossover) that will only work in f13 with one selinux setting downgrading security but other than that I have no problem with any of the systems. The other thing that is worthwhile it actually reading the selinux guide and understanding how it ticks. That way you can often work around problems yourself with a bit of probing of the files and processes involved in an AVC denial.
There are some real experts around on this list and they are often ready to make suggestions from their significant knowledge base that is worthwhile listening to and by responding and working with them then more often than not the issues can be resolved.
On Sun, 29 Aug 2010, Rex Dieter wrote:
Patrick Dupre wrote:
On Sun, 29 Aug 2010, Rex Dieter wrote:
Patrick Dupre wrote:
Hello,
With fedora 13, when I use Math:GSL, I get an error message: Can't load '/usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so' for module Math::GSL::Errno: /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so: cannot restore segment prot after reloc: Permission denied at /usr/lib/perl5/DynaLoader.pm line 200.
if I do not switch SELinux to permissive !!
Seems something you installed yourself that's running afoul of selinux, fedora doesn't install anything into /usr/local/... by default.
Of course, I NEED Math:GSL !!!!
OK, so... what's your point? Your original post seemed to be blaming selinux here, for something that's not testable (ie, supporting/testing something not included in fedora).
You can install the package Math:GSL, and the make test will fail if SELinux is set enforcing. THis is not a new problem and I do not think that I should desactive Selinux every that I use Math:GSL. Same problem with scilab
Regards.
On Sun, 29 Aug 2010, Erik P. Olsen wrote:
On 29/08/10 18:42, Rex Dieter wrote:
Patrick Dupre wrote:
On Sun, 29 Aug 2010, Rex Dieter wrote:
Patrick Dupre wrote:
Hello,
With fedora 13, when I use Math:GSL, I get an error message: Can't load '/usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so' for module Math::GSL::Errno: /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so: cannot restore segment prot after reloc: Permission denied at /usr/lib/perl5/DynaLoader.pm line 200.
if I do not switch SELinux to permissive !!
Seems something you installed yourself that's running afoul of selinux, fedora doesn't install anything into /usr/local/... by default.
Of course, I NEED Math:GSL !!!!
OK, so... what's your point? Your original post seemed to be blaming selinux here, for something that's not testable (ie, supporting/testing something not included in fedora).
I would advise Patrick to disable Selinux. I've made that decision long ago because it gives me more problems when enabled that I can possibly solve. IMHO the user interface is so bad that selinux is unuseable for an ordinary enduser.
So what is the purpose of SELinux ?
On Sun, 29 Aug 2010, mike cloaked wrote:
On Sun, Aug 29, 2010 at 6:14 PM, Erik P. Olsen epodata@gmail.com wrote:
On 29/08/10 18:42, Rex Dieter wrote:
Patrick Dupre wrote:
On Sun, 29 Aug 2010, Rex Dieter wrote:
Patrick Dupre wrote:
Hello,
With fedora 13, when I use Math:GSL, I get an error message: Can't load '/usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so' for module Math::GSL::Errno: /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so: cannot restore segment prot after reloc: Permission denied at /usr/lib/perl5/DynaLoader.pm line 200.
if I do not switch SELinux to permissive !!
Seems something you installed yourself that's running afoul of selinux, fedora doesn't install anything into /usr/local/... by default.
Of course, I NEED Math:GSL !!!!
OK, so... what's your point? Your original post seemed to be blaming selinux here, for something that's not testable (ie, supporting/testing something not included in fedora).
I would advise Patrick to disable Selinux. I've made that decision long ago because it gives me more problems when enabled that I can possibly solve. IMHO the user interface is so bad that selinux is unuseable for an ordinary enduser.
With many selinux issues with a bit of effort and help from a few experts the issues can often be resolved - I have been running all my systems with selinux enforcing since F9 - and the additional protection is worth it. There are a few things from outside Fedora (like Crossover) that will only work in f13 with one selinux setting downgrading security but other than that I have no problem with any of the systems. The other thing that is worthwhile it actually reading the selinux guide and understanding how it ticks. That way you can often work around problems yourself with a bit of probing of the files and processes involved in an AVC denial.
There are some real experts around on this list and they are often ready to make suggestions from their significant knowledge base that is worthwhile listening to and by responding and working with them then more often than not the issues can be resolved.
In my opinion, people involved in the fedora projetc should work with the package makers, Math:GSL and Scilab for example to see how they could make the installation and the use of the package correct/compatible with SELinix !
On 08/29/2010 08:27 AM, Patrick Dupre wrote:
With fedora 13, when I use Math:GSL, I get an error message: Can't load '/usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so' for module Math::GSL::Errno: /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so: cannot restore segment prot after reloc: Permission denied at
Try:
chcon -t texrel_shlib_t \ /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so
On Sun, 29 Aug 2010, Gordon Messmer wrote:
On 08/29/2010 08:27 AM, Patrick Dupre wrote:
With fedora 13, when I use Math:GSL, I get an error message: Can't load '/usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so' for module Math::GSL::Errno: /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so: cannot restore segment prot after reloc: Permission denied at
Try:
chcon -t texrel_shlib_t \ /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so
OK, it works for Errno.so, but I have to do it all the files of the package ! Thank
On 29 August 2010 17:18, Patrick Dupre pd520@york.ac.uk wrote:
On Sun, 29 Aug 2010, Gordon Messmer wrote:
On 08/29/2010 08:27 AM, Patrick Dupre wrote:
With fedora 13, when I use Math:GSL, I get an error message: Can't load '/usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so' for module Math::GSL::Errno: /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so: cannot restore segment prot after reloc: Permission denied at
Try:
chcon -t texrel_shlib_t \ /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so
OK, it works for Errno.so, but I have to do it all the files of the package !
How about use find and xargs to do the work for you?
Something like this should work, (untested)
# find /usr/local/lib/perl5/auto/Math/GSL -type f -name '*.so' -print0 | xargs -0 chcon -t texrel_shlib_t
BTW, why not file a RFE for Math::GSL on the redhat bugzilla under Fedora? I already see lots of perl packages in the repository, adding another one might be quite simple for one the current maintainers? :)
Thank
I would advise Patrick to disable Selinux. I've made that decision long ago because it gives me more problems when enabled that I can possibly solve. IMHO the user interface is so bad that selinux is unuseable for an ordinary enduser.
So what is the purpose of SELinux ?
Theodore Tso put it very well: http://lwn.net/Articles/252892/
| In some environments, say if you are creating a system that will | handle classified data for the U.S. government, there are formal | requirements that your employer, the NSA, sign off on the | solution. This allows the NSA to force the application | programmers and end users to make the tradeoff tilt very much | against convenience in favor of security. And given the threat | models and capabilities of the adversaries involved, that's | probably appropriate. | | But that's not necessarily appropriate for all users. SELINUX is | so horrible to use, that after wasting a large amount of time | enabling it and then watching all of my applications die a | horrible death since they didn't have the appropriate | hand-crafted security policy, caused me to swear off of it. For | me, given my threat model and how much my time is worth, life is | too short for SELinux.
And JWZ:
On Mon, 30 Aug 2010 13:29:51 +0900, Takehiko Abe wrote:
I would advise Patrick to disable Selinux. I've made that decision long ago because it gives me more problems when enabled that I can possibly solve. IMHO the user interface is so bad that selinux is unuseable for an ordinary enduser.
Huge rant against SELinux deleted . . . .
I've had exactly the opposite experience running SELinux, even with hand- compiled applications from a variety of sources - including my own.
I've had some issues with understanding how SELinux works - the latest being not able to pipe output to root's home directory. However, in retrospect, the restriction is good and one that is easy to solve (pipe to /tmp, then mv or cp).
The last two nightmare SELinux issues I had were with Songbird and the Mono server that enables Mono on Apache. Both had multiple problems, and to me it's indicative of sloppy coding. I decided not to run those applications. This is probably a wise decision since Songbird for Linux is no more. I've yet to see a satisfactory configuration of Mono and Apache on Linux that doesn't entail disabling SELinux. Since I'm not a .NET or C# fan, I'll happily do without.
I think in a home environment the key has been to run in permissive mode. Then you get all of the warnings along with how to fix the problem. An added bonus is that you can submit bug reports about SELinux with the hope of making it better and more seamless. Once you don't get SELinux warnings for a few days, you might think about running in strict mode.
The only continuing nag that I have now is NVidia's proprietary driver. Fortunately I have a script I run after building the driver to take care of any lingering SELinux issues. I prefer installing the driver by hand (as well as tweaking xorg.conf and overclocking my graphics card) rather than depending on rpmfusion.org. They provide a fine service (and I use some of their other packages), but I've had no trouble building the stock NVida drivers.
. . . . just my two cents.
/mde/
On Mon, 2010-08-30 at 13:29 +0900, Takehiko Abe wrote:
not necessarily appropriate for all users. SELINUX is so horrible to use, that after wasting a large amount of time enabling it and then watching all of my applications die a horrible death since they didn't have the appropriate hand-crafted security policy, caused me to swear off of it.
You have to wonder if those programs had such big problems because they were badly coded, trying to do things that they shouldn't do.
You see warnings with some programs about it trying to make something executable that SELinux says shouldn't be necessary. Suggesting that the programmer is one those who believes that their software should be able to do absolutely anything without any restriction.
On Mon, Aug 30, 2010 at 1:18 AM, Patrick Dupre pd520@york.ac.uk wrote:
Try:
chcon -t texrel_shlib_t \ /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so
OK, it works for Errno.so, but I have to do it all the files of the package !
You can set context for all the files in a directory (such as /usr/local/lib/perl5/auto/Math/GSL ) by doing: semanage fcontext -a -t textrel_shlib_t '/usr/local/lib/perl5/auto/Math/GSL(/.*)?' then restorecon -vR /usr/local/lib/perl5/auto/Math/GSL
This will then allow you to set that context in all the files if they change in the future by repeating the restorecon command. Also the files will have their contexts correctly reset after an autorelabel as well.
I would strongly suggest that you read the selinux guide.
On 08/30/2010 04:30 PM, mike cloaked wrote:
On Mon, Aug 30, 2010 at 1:18 AM, Patrick Dupre pd520@york.ac.uk wrote:
Try:
chcon -t texrel_shlib_t \ /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so
OK, it works for Errno.so, but I have to do it all the files of the package !
You can set context for all the files in a directory (such as /usr/local/lib/perl5/auto/Math/GSL ) by doing: semanage fcontext -a -t textrel_shlib_t '/usr/local/lib/perl5/auto/Math/GSL(/.*)?' then restorecon -vR /usr/local/lib/perl5/auto/Math/GSL
This will then allow you to set that context in all the files if they change in the future by repeating the restorecon command. Also the files will have their contexts correctly reset after an autorelabel as well.
I would strongly suggest that you read the selinux guide.
Another thing to do would be to google "customizing selinux policy" (or similar words/phrase) and then create a local policy.
Someplace like http://wiki.centos.org/HowTos/SELinux is a good start.
Thank.
On Mon, Aug 30, 2010 at 1:18 AM, Patrick Dupre pd520@york.ac.uk wrote:
Try:
chcon -t texrel_shlib_t \ /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so
OK, it works for Errno.so, but I have to do it all the files of the package !
You can set context for all the files in a directory (such as /usr/local/lib/perl5/auto/Math/GSL ) by doing: semanage fcontext -a -t textrel_shlib_t '/usr/local/lib/perl5/auto/Math/GSL(/.*)?' then restorecon -vR /usr/local/lib/perl5/auto/Math/GSL
This will then allow you to set that context in all the files if they change in the future by repeating the restorecon command. Also the files will have their contexts correctly reset after an autorelabel as well.
I would strongly suggest that you read the selinux guide.
I've had exactly the opposite experience running SELinux, even with hand- compiled applications from a variety of sources - including my own.
You say "the opposite" but you seem to have a lot of problems and spent fair amount of time because of SELinux. And what you get in return? Nothing except for a vague notion of "security".
You have to wonder if those programs had such big problems because they were badly coded, trying to do things that they shouldn't do.
So you measure the quality of the programs with SELinux. Ouch.
You see warnings with some programs about it trying to make something executable that SELinux says shouldn't be necessary. Suggesting that the programmer is one those who believes that their software should be able to do absolutely anything without any restriction.
It does not suggest such a thing. Linux is not Microsoft Windows. No SELinux does not mean no restriction or no security.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/29/2010 11:27 AM, Patrick Dupre wrote:
Hello,
With fedora 13, when I use Math:GSL, I get an error message: Can't load '/usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so' for module Math::GSL::Errno: /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so: cannot restore segment prot after reloc: Permission denied at /usr/lib/perl5/DynaLoader.pm line 200.
if I do not switch SELinux to permissive !!
IE I cannot use enforcing
Ignoring the usual SELinux sucks/no it does not rant.
Patrick,
SELinux is noticing that Math:CSL has built libraries that require text relocation, and were not marked as such.
http://www.akkadia.org/drepper/selinux-mem.html
Explains the access check.
SELinux is all about labeling. Every process and file has a label and there are rules about how the processes and labels interact. When you have an SELinux problem, usually either the labeling is wrong or the rules are wrong.
http://danwalsh.livejournal.com/30837.html
In this case it looks like Math:CSL either built their libraries incorrectly or require code that triggers this access (Assemply)? So you have two choices either change the labels on the shared libraries to allow the access, using semanage fcontext ...
Or you can turn off the check altogether.
# setsebool -P allow_execmod 1
On Mon, 30 Aug 2010 08:36:52 -0400 Daniel J Walsh wrote:
In this case it looks like Math:CSL either built their libraries incorrectly or require code that triggers this access (Assemply)?
Yea, it is very very simple to have a library with hand coded assembly as part of it that is missing the obscure assembly directives that set the flags marking the text as really being execute only and the data as really being non-executable.
Usually comparing the assembly with the assembly output from gcc for a small function will enable you to discover the wondrous gibberish the hand coded assembly needs to add :-).
Dan - thank you. selinux is outstanding - and through your efforts (and others) especially on the fedora policy files, grown over the last several years into something really useful.
Anti-selinux folk. It takes work to deploy it on some systems for sure and I am just learning - i have a lot of work on one system to get it compliant. For many setups targeted policy works with no changes at all.
Please avoid the rude remarks - i.e. be excellent :)
If some of you are not using it fine. But to claim it has little or no security suggests nothing but enormous ignorance of security issues.
If one does not have the xxx (time, resources, ability, whatever) to make the effort to tune those systems which need some work fine - dont do it - that decision has nothing to do with security - only _your_ choices.
To Dan, Stephen (and the NSA) and all the others - thank you for helping advance linux security.
gene/
Tim:
You have to wonder if those programs had such big problems because they were badly coded, trying to do things that they shouldn't do.
Takehiko Abe:
So you measure the quality of the programs with SELinux. Ouch.
I certainly put bad marks against programs which do unwise things (try to read things they shouldn't, try to write where they shouldn't, try to execute things that the shouldn't, etc.). SELinux warnings are just one set of red flags.
You see warnings with some programs about it trying to make something executable that SELinux says shouldn't be necessary. Suggesting that the programmer is one those who believes that their software should be able to do absolutely anything without any restriction.
It does not suggest such a thing.
When I see warnings that some program has tried to read some file completely unrelated to its operation, yes I do believe that the programmer is one of those that thinks that their program should do anything that they want, regardless of other concerns.
Linux is not Microsoft Windows.
Though some programmers seem to think that it should be. Some users, too.
No SELinux does not mean no restriction or no security.
I never said it. But when you see something trying to read something that it shouldn't, that was stopped by SELinux, it's a window into the mindset of the program author.
So you measure the quality of the programs with SELinux. Ouch.
I certainly put bad marks against programs which do unwise things
Unwise according to SELinux -- another program.
Linux is not Microsoft Windows.
Though some programmers seem to think that it should be. Some users, too.
heh. To me it looks like many fedora users are so much traumatized by Windows insecurity that they brought the same habits into computing on Linux which are not necessary -- like fearing HTML mail or feeling vulnerable without firewall or other security enhancing softwares...
No SELinux does not mean no restriction or no security.
I never said it. But when you see something trying to read something that it shouldn't, that was stopped by SELinux, it's a window into the mindset of the program author.
Care to give an example? Which program tries to read which file?
On 08/30/2010 10:25 PM, Takehiko Abe wrote:
heh. To me it looks like many fedora users are so much traumatized by Windows insecurity that they brought the same habits into computing on Linux which are not necessary -- like fearing HTML mail or feeling vulnerable without firewall or other security enhancing softwares...
It is up to the individual to decided on the level of security they desire. Some may consider certain precautions to be based on paranoia.
I think you know that it is certainly possible to deploy a web server and applications on the web server which, if done improperly, could expose the system to unnecessary risks. And, you should also know that certain selinux policies are designed to mitigate that risk. One could argue that the perfect web server designer/administrator doesn't need that sort of protection...but when you find perfect programmers please let me know.
As for "fear" of HTML email... Most of the aversion to HTML mail on this list is due to the added size of the message. Me, I don't care about the size. What has turned me off on HTML email is the way some people/companies abuse it. There was this one company, from northern Asia, that sent messages in HTML with 1 pixel images embedded to be retrieved from their web server. Each message they sent had a different image embedded such that they could match the message with the image retrieval and know that the message was opened/displayed by someone. This was their way of getting around people refusing to "acknowledge receipt".
On Mon, 30 Aug 2010 21:10:12 +0900, Takehiko Abe wrote:
I've had exactly the opposite experience running SELinux, even with hand- compiled applications from a variety of sources - including my own.
You say "the opposite" but you seem to have a lot of problems and spent fair amount of time because of SELinux. And what you get in return? Nothing except for a vague notion of "security".
I have not spent a large amount of time. Songbird and Mono are the only two troublesome issues I've had since SELinux has been a part of Redhat/ Fedora.
I spent 1 hour (and one bug report) on Songbird. I abandoned it because it ran poorly and had multiple SELinux issues. I did spend a few days off and on with mod_mono and friends. I finally decided that even if I got mod_mono running cleanly, any C#.NET programming I needed to do (mostly Java / .NET integration via SOAP) would be better done on Windows.
The NVidia issue is well known, documented, and actually mostly taken care of in their install script.
Other minor issues, such as the cron file descriptor leak, are normal bugs and taken care of pretty rapidly by the maintainers of various packages.
As far as a vague notion of security, I have to confess I have not studied SELinux, so I don't know the material in detail. It's on my list of things to do, but right now I'm in the middle of working on portlets (JSR 286), and some Tomcat configurations which I hope to write up. There is just so much time in the day . . .
That being said, one of the particular things that SELinux does that I like is preventing privileged applications from writing where it is unexpected. For example, unless you specifically label a directory for httpd, you'll get an SELinux denial (or warning if you run in permissive mode) when httpd tries to read or write from directories not deemed safe. If you're developing PHP and using the ~username/public_html option to get around having to copy things over as root, this can be a bit of a pain until you label your file system correctly.
However, this is a really valuable warning / denial. Many PHP frameworks tend to write temporary files. It would be nice to have the system deny those files if they're not in the expected places. Attackers subvert PHP frameworks all the time. By preventing files getting written to unexpected places, this makes the attack more difficult and the system more secure.
I've not had my use of the system hampered or curtailed by SELinux. I'm a pretty aggressive user. Right now I have an IDE (NetBeans), an editor (emacs), firefox, thunderbird, gyachi, pan, a shell, streamtuner, and audacious 2 running as this user. Sometimes I'll also have OpenOffice or Pencil running. I have Apache and MySQL running in the background, and I will be starting Tomcat 6.0.18 and Derby for testing soon (my portal container has issues with Tomcat 6.0.29). I occasionally run IP aliases to simulate multiple machines. Sometimes I'll fire up Google Earth when events happen in another part of the world where friends of mine live.
While doing this, I have had absolutely no issue with SELinux. Any small warning (haven't seen one in over a week) I can usually handle by issuing the appropriate SELinux command. I always file a bug report so that people can fix their programs. It's not much that I give back to Fedora (I spend a lot more time on ASF software), but it's a start.
As another person has said, if a program gives multiple SELinux warnings and seems to defy any simple attempts at file labeling as a fix, then maybe it's a poorly written program. If the program maintainers are not responsive to SELinux problems, then maybe the programmers have too much on their plates to properly maintain their contributions. In any case, there are almost always other packages that perform the same tasks without the SELinux issues.
Of course, you always have the option of turning off SELinux. It's been my experience that turning off SELinux is not necessary. Personally, I like knowing when a potentially unsafe operation is happening on my system. I actually learn a bit about security. I then change my habits and become a more security-conscious user, programmer, architect, system administrator.
Learning new stuff is not a bad thing. In fact, it's pretty fun.
. . . just my two cents
/mde/
On Monday, August 30, 2010 14:27:28 Genes MailLists wrote:
Dan - thank you. selinux is outstanding - and through your efforts (and others) especially on the fedora policy files, grown over the last several years into something really useful.
[snip]
To Dan, Stephen (and the NSA) and all the others - thank you for helping advance linux security.
+1
Best, :-) Marko
On Mon, Aug 30, 2010 at 2:27 PM, Genes MailLists lists@sapience.com wrote:
Dan - thank you. selinux is outstanding - and through your efforts (and others) especially on the fedora policy files, grown over the last several years into something really useful.
Anti-selinux folk. It takes work to deploy it on some systems for sure and I am just learning - i have a lot of work on one system to get it compliant. For many setups targeted policy works with no changes at all.
Please avoid the rude remarks - i.e. be excellent :)
If some of you are not using it fine. But to claim it has little or no security suggests nothing but enormous ignorance of security issues.
If one does not have the xxx (time, resources, ability, whatever) to make the effort to tune those systems which need some work fine - dont do it - that decision has nothing to do with security - only _your_ choices.
To Dan, Stephen (and the NSA) and all the others - thank you for helping advance linux security.
I whole-heartedly concur - and indeed I have had a lot of help at times from Dan W in particular who has so many times devoted his time to helping people, also to Stephen S and the unseen names from NSA who have made huge advances in security through creating and developing selinux to the point where for the most part it is quite transparent to most users for much of the time.
| hand-crafted security policy, caused me to swear off of it. For | me, given my threat model and how much my time is worth, life is | too short for SELinux.
And JWZ:
http://jwz.livejournal.com/719608.html
And if you have a machine actually plugged into the internet, handling any untrusted content or with potentialy buggy apps (which is just about anything that opens an image for example) then its kind of useful.
An awful lot of attacks simply don't work because of SELinux. But it's your system, one of the things about Free Software is you control the tradeoffs on your machine not some vendor by diktat.
Myself - I'm prepared to fiddle now and then with SELinux settings on my box so that its much harder to steal all my email, run off with my credit card data or just be a nuisance.
Sad to see people made the same argument about firewalls long ago - turn it off it breaks doom, video streaming, etc. Nowdays anyone suggesting turning off your firewall or always running as root (saves debugging file permission problems) would be howled down. It's not alas occurred yet with SELinux.
As to software which demands you disable security, I always apply common sense and treat it the same way as if a passing tradesman says "can you just leave your door unlocked for the weekend"
Alan
And if you have a machine actually plugged into the internet, handling any untrusted content or with potentialy buggy apps (which is just about anything that opens an image for example) then its kind of useful.
heh. I guess it's even more useful if I am using the adobe 64-bit flash plugin with a known exploit incident.
An awful lot of attacks simply don't work because of SELinux. But it's your system, one of the things about Free Software is you control the tradeoffs on your machine not some vendor by diktat.
Myself - I'm prepared to fiddle now and then with SELinux settings on my box so that its much harder to steal all my email, run off with my credit card data or just be a nuisance.
Please give me an attack scenario where all my email get stolen.
However, this is a really valuable warning / denial. Many PHP frameworks tend to write temporary files. It would be nice to have the system deny those files if they're not in the expected places.
You are developing a PHP application which will be deployed on a server. And you are using SELinux as a debugging tool.
On Tue, 31 Aug 2010 06:40:02 +0000 keke@gol.com wrote:
However, this is a really valuable warning / denial. Many PHP frameworks tend to write temporary files. It would be nice to have the system deny those files if they're not in the expected places.
You are developing a PHP application which will be deployed on a server. And you are using SELinux as a debugging tool.
SELinux is useful in that role yes - and it's very useful in production because all sorts of joyously wonderful people try and debug your PHP shopping cart when its in production.
Alan
On Mon, 2010-08-30 at 22:06 +0100, Alan Cox wrote:
As to software which demands you disable security, I always apply common sense and treat it the same way as if a passing tradesman says "can you just leave your door unlocked for the weekend"
Likewise for people vehemently advocating to disable SELinux, I view them with a great deal of suspicion. Is it simply they really do not like it, or do they have ulterior motives?
On 08/31/2010 02:26 PM, Tim wrote:
On Mon, 2010-08-30 at 22:06 +0100, Alan Cox wrote:
As to software which demands you disable security, I always apply common sense and treat it the same way as if a passing tradesman says "can you just leave your door unlocked for the weekend"
Likewise for people vehemently advocating to disable SELinux, I view them with a great deal of suspicion. Is it simply they really do not like it, or do they have ulterior motives?
Neither. Initially, when trying to use it, they typically notice something stops working. Then, when trying to make it work, they get lost in arcane and cryptic tools.
To utilize Alan's ABS analogy: In most cases, the only UI ABS offers to end-users an on/off switch and "just works". SELinux however forces to fiddle and dig through 100s of knobs and switches.
In short: there is nothing fundamentally wrong with SELinux, except that its UIs and GUIs are not end-user-ready and that the Fedora SELinux policy packages suffer from bugs.
Ralf
On Tue August 31 2010, Ralf Corsepius wrote:
Neither. Initially, when trying to use it, they typically notice something stops working. Then, when trying to make it work, they get lost in arcane and cryptic tools.
I can relate to that... As always, with something NEW or unfamiliar.. I tried it also and turned it off in an earlier life:)
so, this morning I installed selinux: # yum install policycoreutils-gui
then ran: # system-config-selinux rebooted & did the relabel.
this is my travel laptop running FC13.
right now I have nomachine client running, and it just works, as does thunderbird... I might set it up on my Debian Desktop also, since I do have a web server running there...
Likewise for people vehemently advocating to disable SELinux, I view them with a great deal of suspicion. Is it simply they really do not like it, or do they have ulterior motives?
Neither. Initially, when trying to use it, they typically notice something stops working. Then, when trying to make it work, they get lost in arcane and cryptic tools.
You forgot the crucial point. Namely that SELinux is not necessary for most.
btw I don't know who "vehemently advocating to disable SELinux". Rather it is "I don't need it" or its variations -- all very smooth and mild like the Theodore Tso's comment I quoted in the first place. I quote one more from the same thread. This one is from Linus:
"I find SELinux to be so irrelevant to my usage that I don't use it at all"
place. I quote one more from the same thread. This one is from Linus:
"I find SELinux to be so irrelevant to my usage that I don't use it at all"
Linus is not exactly famous for his ability to understand security concepts. I find the fact your argument is produced by google and cut/paste rather than technical material ... enlightening
But hey if Linus jumped down a volcano would you follow ?
There *are* cases where you want SELinux off - isolated high performance computing clusters for example where you want the absolute minimal overhead but they also usually turn off other junk Fedora inflicts on people by default which is far more pointless - like LVM (unless you are doing crypted fs stuff)
Alan
;;; sorry other one goes straight to you
Linus is not exactly famous for his ability to understand security concepts. I find the fact your argument is produced by google and cut/paste rather than technical material ... enlightening
Well, please educate me. All I hear from advocates is "more security" without a concrete example. You mentioned the danger of emails get stolen without SELinux. Please give me the scenario. So we can gauge the risk.
But hey if Linus jumped down a volcano would you follow ?
Sure I will. Did he?
On Wed, Sep 01, 2010 at 00:14:09 +0900, Takehiko Abe keke@gol.com wrote:
;;; sorry other one goes straight to you
Linus is not exactly famous for his ability to understand security concepts. I find the fact your argument is produced by google and cut/paste rather than technical material ... enlightening
Well, please educate me. All I hear from advocates is "more security" without a concrete example. You mentioned the danger of emails get stolen without SELinux. Please give me the scenario. So we can gauge the risk.
If you read email you need selinux. If you read email with a client that fires up plugins to read special content (e.g. html, pdfs, flash) then you really need selinux.
If you use a web browser to view more than a short list of trusted sites, you need selinux.
If you run network services accessible from outside the machine then you need selinux.
If you run binaries from semitrusted groups (this includes most commercial software) then you need selinux.
On 08/31/2010 05:32 PM, Bruno Wolff III wrote:
On Wed, Sep 01, 2010 at 00:14:09 +0900, Takehiko Abekeke@gol.com wrote:
;;; sorry other one goes straight to you
Linus is not exactly famous for his ability to understand security concepts. I find the fact your argument is produced by google and cut/paste rather than technical material ... enlightening
Well, please educate me. All I hear from advocates is "more security" without a concrete example. You mentioned the danger of emails get stolen without SELinux. Please give me the scenario. So we can gauge the risk.
If you read email you need selinux. If you read email with a client that fires up plugins to read special content (e.g. html, pdfs, flash) then you really need selinux.
If you use a web browser to view more than a short list of trusted sites, you need selinux.
If you run network services accessible from outside the machine then you need selinux.
If you run binaries from semitrusted groups (this includes most commercial software) then you need selinux.
You don't _need_ SELinux in any such cases.
SELinux is aiming at catching malfunctioning/misbehaving programs and _may_ prevent damage in use-cases such as those you list.
However, SELinux also causes mal-functions and prevents applications from operating properly. Semi-educated tweaking SELinux may even cause further damage up to rendering systems completely unusable.
To me this means: If the defaults work, use it. If it doesn't, switch it off, otherwise you might easily shoot yourself into the foot.
Ralf
Well, please educate me. All I hear from advocates is "more security" without a concrete example. You mentioned the danger of emails get stolen without SELinux. Please give me the scenario. So we can gauge the risk.
Simple example. Daemons running under selinux can only access the things they are expected to be accessing. So if I was to crack your httpd and try and execute a shell SELinux would block it. Standard file permissions have no notion of who is doing the action and in what context so would not save you.
The biggest win for a lot of folks is web stuff. If I find a bug in a PHP script (which for most PHP is pretty much a given) that allows me to access arbitary files it will be a lot less useful under SELinux because only files labelled as http content can be accessed this way.
If I manage to use a bug to add a new script to your machine via the web server I'll not be able to get it to run as a cgi because the web server isn't allowed to create cgi binaries. Again won't happen with just file permissions.
Alan
If you use a web browser to view more than a short list of trusted sites, you need selinux.
If you run network services accessible from outside the machine then you need selinux.
If you run binaries from semitrusted groups (this includes most commercial software) then you need selinux.
You don't _need_ SELinux in any such cases.
I wouldn't dare run some of the web plugins without them being very very constrained by a security tool. I'm not sure I trust some of the image libraries either although the google audit work seems to be slowly improving it.
Unfortunately application library security has taken a nasty turn for the worse because any library exploit in a library also used on the iphone is now being sat on by jailbreakers rather than reported.
Alan
;;; sorry again -- my thunderbird habit does not work for your message
Well, please educate me. All I hear from advocates is "more security" without a concrete example. You mentioned the danger of emails get stolen without SELinux. Please give me the scenario. So we can gauge the risk.
Simple example. Daemons running under selinux can only access the things they are expected to be accessing. So if I was to crack your httpd [...]
I am sorry, but I assumed a desktop system all along. I believe that is clear when I say that SELinux is not necessary for most. The comments I quoted are /not/ about servers too.
And from the context it was clear that you talked about a browser exploit when you said "its much harder to steal all my email, run off with my credit card data or just be a nuisance."
I assume you know the chances that an average linux user actually get exploited in that way is very low.
On Wed, Sep 01, 2010 at 08:29:25 +0900, Takehiko Abe keke@gol.com wrote:
I assume you know the chances that an average linux user actually get exploited in that way is very low.
Don't expect that to last. Windows users get hosed by web browser and plugin bugs a lot. Right now it isn't worth the trouble to set up similar exploits for Linux systems. Expect that to change as the malware toolkits get better.
And from the context it was clear that you talked about a browser exploit when you said "its much harder to steal all my email, run off with my credit card data or just be a nuisance."
SELinux constrains desktop applications too - particularly high risk ones like web browsers.
I assume you know the chances that an average linux user actually get exploited in that way is very low.
I would love to see the academic paper reference for this and the analysis as to why - maybe it's because most of them use SELinux ;)
Alan
On Tue, 2010-08-31 at 18:41 -0500, Bruno Wolff III wrote:
Windows users get hosed by web browser and plugin bugs a lot. Right now it isn't worth the trouble to set up similar exploits for Linux systems. Expect that to change as the malware toolkits get better.
And, as more clueless users migrate to a system, where they expect to be able to treat it as a magic box, and click on everything without thinking about it...
I assume you know the chances that an average linux user actually get exploited in that way is very low.
I would love to see the academic paper reference for this and the analysis as to why - maybe it's because most of them use SELinux ;)
Just count the known incidents of such exploits. ZERO. No WMD.
I assume you know the chances that an average linux user actually get exploited in that way is very low.
Don't expect that to last. Windows users get hosed by web browser and plugin bugs a lot. Right now it isn't worth the trouble to set up similar exploits for Linux systems.
So, right now I do not need SELinux even if I "use a web browser to view more than a short list of trusted sites".
Expect that to change as the malware toolkits get better.
I don't.
So, right now I do not need SELinux even if I "use a web browser to view more than a short list of trusted sites".
Of course flash, firefox, all the image libraries it uses and the font libraries are perfect and never had a bug triggerable remotely - right ?
Nope.
Look for example the Dowd exploit of flash - SELinux blocked it, non SELinux systems got 0wned. Ditto Mambo against Firefox. Dowd is also interesting because it was designed and built as a cross platform exploit.
Alan
On Wed, 01 Sep 2010 21:25:11 +0900 Takehiko Abe keke@gol.com wrote:
I assume you know the chances that an average linux user actually get exploited in that way is very low.
I would love to see the academic paper reference for this and the analysis as to why - maybe it's because most of them use SELinux ;)
Just count the known incidents of such exploits. ZERO. No WMD.
Wrong again - hard to tell whether you are clueless, a troll or write exploits as a hobby and want to stop people protecting against them ?
Alan
On 09/01/2010 10:54 PM, Alan Cox wrote:
On Wed, 01 Sep 2010 21:25:11 +0900 Takehiko Abe keke@gol.com wrote:
I assume you know the chances that an average linux user actually get exploited in that way is very low.
I would love to see the academic paper reference for this and the analysis as to why - maybe it's because most of them use SELinux ;)
Just count the known incidents of such exploits. ZERO. No WMD.
Wrong again - hard to tell whether you are clueless, a troll or write exploits as a hobby and want to stop people protecting against them ?
All of the above?
;;; the clueless sent the mail directly to you again. Sorry. ;;;
Just count the known incidents of such exploits. ZERO. No WMD.
Wrong again
You mentioned "Dowd exploit of flash". Google returns:
"IBM researcher Mark Dowd has outlined a Flash vulnerability that could allow for a rare cross-platform web-based exploit."
This is definitely not the incident of the exploits you suggested. No email got stolen. It says Mark Dowd is an IBM researcher. He is not a criminal.
;;; edit ;;;;
I think you are trying not to see my point.
On Wednesday, September 01, 2010 16:29:53 Takehiko Abe wrote:
You mentioned "Dowd exploit of flash". Google returns:
"IBM researcher Mark Dowd has outlined a Flash vulnerability that could allow for a rare cross-platform web-based exploit."This is definitely not the incident of the exploits you suggested. No email got stolen. It says Mark Dowd is an IBM researcher. He is not a criminal.
Mark Dowd is an IBM researcher who discovered the hole in flash and constructed the exploit. You can read about all gory details in his paper:
http://documents.iss.net/whitepapers/IBM_X-Force_WP_final.pdf
And since he is not a criminal, he published his findings so that Adobe can fix the appropriate hole.
HTH, :-) Marko
I've been a security wonk for many years, and the problem I have with SeLinux is that when it makes a decision I disagree with, it's like pulling teeth to change it's mind.
So I sometimes just turn it off
Sigh
-- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org
On Aug 31, 2010, at 11:13 AM, Alan Cox alan@lxorguk.ukuu.org.uk wrote:
place. I quote one more from the same thread. This one is from Linus:
"I find SELinux to be so irrelevant to my usage that I don't use it at all"Linus is not exactly famous for his ability to understand security concepts. I find the fact your argument is produced by google and cut/paste rather than technical material ... enlightening
But hey if Linus jumped down a volcano would you follow ?
There *are* cases where you want SELinux off - isolated high performance computing clusters for example where you want the absolute minimal overhead but they also usually turn off other junk Fedora inflicts on people by default which is far more pointless - like LVM (unless you are doing crypted fs stuff)
Alan
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Ralf Corsepius wrote:
On 08/31/2010 05:32 PM, Bruno Wolff III wrote:
On Wed, Sep 01, 2010 at 00:14:09 +0900, Takehiko Abekeke@gol.com wrote:
;;; sorry other one goes straight to you
Linus is not exactly famous for his ability to understand security concepts. I find the fact your argument is produced by google and cut/paste rather than technical material ... enlightening
Well, please educate me. All I hear from advocates is "more security" without a concrete example. You mentioned the danger of emails get stolen without SELinux. Please give me the scenario. So we can gauge the risk.
If you read email you need selinux. If you read email with a client that fires up plugins to read special content (e.g. html, pdfs, flash) then you really need selinux.
If you use a web browser to view more than a short list of trusted sites, you need selinux.
If you run network services accessible from outside the machine then you need selinux.
If you run binaries from semitrusted groups (this includes most commercial software) then you need selinux.
You don't _need_ SELinux in any such cases.
SELinux is aiming at catching malfunctioning/misbehaving programs and _may_ prevent damage in use-cases such as those you list.
However, SELinux also causes mal-functions and prevents applications from operating properly. Semi-educated tweaking SELinux may even cause further damage up to rendering systems completely unusable.
To me this means: If the defaults work, use it. If it doesn't, switch it off, otherwise you might easily shoot yourself into the foot.
Ralf:
How about we pick a happy middle ground: Permissive mode. That way I get notified if the 'bad guys' are up to something and I don't get locked out when I 'make a mistake'.
We can agree to disagree on the merits and benefits of each and every program on the system, but when it comes to security, to remain sane we have to have some sort of it. Otherwise we would go back to being islands of computing power. That is what 'they' want. Then they can beat on us until we submit.
James McKenzie
Takehiko Abe wrote:
I assume you know the chances that an average linux user actually get exploited in that way is very low.
Don't expect that to last. Windows users get hosed by web browser and plugin bugs a lot. Right now it isn't worth the trouble to set up similar exploits for Linux systems.
So, right now I do not need SELinux even if I "use a web browser to view more than a short list of trusted sites".
Have I got a site for you. I stated it before, web browser malware is NOT operating system specific.
Expect that to change as the malware toolkits get better.
I don't.
I do. Rootkits have given way to browser malware. And it does exist for Firefox, Chrome and Opera. YOUR information is very, very valuable. And yes, it can be stolen without a lot of effort. One wrong step and 'bang' they've got you.
SELinux and other security tools (never rely on just one) alert you that 'something is wrong'. You have to take action to fix.
Also, keep in mind that in business, 85% of all attacks come from inside the company. Most are not intentional. Most are stupid users doing stupid things. Again, tools help.
SELinux is a tool, designed to 'armor up' your system. Its history is well known.
BTW, since I'm an island, I don't need SELinux. But I'm going to install it and set it to permissive in case I make a mistake.
James McKenzie
Patrick Dupre wrote:
On Sun, 29 Aug 2010, Rex Dieter wrote:
Patrick Dupre wrote:
Hello,
With fedora 13, when I use Math:GSL, I get an error message: Can't load '/usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so' for module Math::GSL::Errno: /usr/local/lib/perl5/auto/Math/GSL/Errno/Errno.so: cannot restore segment prot after reloc: Permission denied at /usr/lib/perl5/DynaLoader.pm line 200.
if I do not switch SELinux to permissive !!
Seems something you installed yourself that's running afoul of selinux, fedora doesn't install anything into /usr/local/... by default.
Of course, I NEED Math:GSL !!!!
So relabel it, there's a good chance that a screen or so down the error report you see with sealert there will be a line saying something like "to allow this run {cmd}" and all you have to do is drag the {cmd} it gives you and drop it in a console.
This is not always true, but often enough to be worth looking.
You need to relabel /usr/local/lib/* because you may have just plopped things into that directory instead of *installing* them properly.
-
Alan Cox -
Bill Davidsen -
Bruno Wolff III -
Chris Kloiber -
Daniel J Walsh -
Darr -
Ed Greshko -
Erik P. Olsen -
Genes MailLists -
Gordon Messmer -
James McKenzie -
Marcus Leech -
Mark Eggers -
Marko Vojinovic -
mike cloaked -
Patrick Dupre -
PaulCartwright -
Ralf Corsepius -
Rex Dieter -
Suvayu Ali -
Takehiko Abe -
Tim -
Tom Horsley