I downloaded Google Earth 4.3 and the install seemed to run without hitch. When I try to run googleearth the xterm displays the following error message; ./googleearth-bin: error while loading shared libraries: ./libminizip.so: cannot restore segment prot after reloc: Permission denied
And then an icon pops up with SE Linux reporting that it has blocked a program.
Is SE linux preventing google earth from running? How do I tell SE Linux to get the heck out of the way?
TIA
Mike
Mike Faire wrote:
I downloaded Google Earth 4.3 and the install seemed to run without hitch. When I try to run googleearth the xterm displays the following error message; ./googleearth-bin: error while loading shared libraries: ./libminizip.so: cannot restore segment prot after reloc: Permission denied
And then an icon pops up with SE Linux reporting that it has blocked a program.
Is SE linux preventing google earth from running? How do I tell SE Linux to get the heck out of the way?
That's a bit like asking how to turn off the burglar alarm so break-ins won't be so noisy. The correct question is how to set attributes correctly so google earth will run, and the answer may be in the SElinux report, as it often is. Real the report and see if it gives you a command to run which solves the problem.
On Fri, 2008-11-28 at 13:45 -0500, Bill Davidsen wrote:
Mike Faire wrote:
I downloaded Google Earth 4.3 and the install seemed to run without
snip...
Is SE linux preventing google earth from running? How do I tell SE Linux to get the heck out of the way?
That's a bit like asking how to turn off the burglar alarm so break-ins won't be so noisy. The correct question is how to set attributes correctly so google earth will run, and the answer may be in the SElinux report, as it often is. Real the report and see if it gives you a command to run which solves the problem.
-- Bill Davidsen davidsen@tmr.com
While your point is well taken Bill, looking at http://www.nsa.gov/selinux/papers/policy2/t1.html makes it clear that adjusting rules and policies is going to require more time and study than I can afford in the foreseeable future. I have a plate full.
Since I see nothing directly relating to Google Earth there, setting /etc/selinux/config to "disable" will have to do until someone with a working knowledge of SE Linux chimes in or I get time to do the research in the future.
Thanks, just the same,
Mike
Mike Faire wrote:
On Fri, 2008-11-28 at 13:45 -0500, Bill Davidsen wrote:
Mike Faire wrote:
I downloaded Google Earth 4.3 and the install seemed to run without
snip...
Is SE linux preventing google earth from running? How do I tell SE Linux to get the heck out of the way?
That's a bit like asking how to turn off the burglar alarm so break-ins won't be so noisy. The correct question is how to set attributes correctly so google earth will run, and the answer may be in the SElinux report, as it often is. Real the report and see if it gives you a command to run which solves the problem.
-- Bill Davidsen davidsen@tmr.com
While your point is well taken Bill, looking at http://www.nsa.gov/selinux/papers/policy2/t1.html makes it clear that adjusting rules and policies is going to require more time and study than I can afford in the foreseeable future. I have a plate full.
The error status from selinux often contains the command to reset the attributes needed to make the application work. No research needed, drag and drop the command into a root shell, hit ENTER.
Since I see nothing directly relating to Google Earth there, setting /etc/selinux/config to "disable" will have to do until someone with a working knowledge of SE Linux chimes in or I get time to do the research in the future.
Thanks, just the same,
Mike
On Friday 28 November 2008, Bill Davidsen wrote:
Mike Faire wrote:
On Fri, 2008-11-28 at 13:45 -0500, Bill Davidsen wrote:
Mike Faire wrote:
I downloaded Google Earth 4.3 and the install seemed to run without
snip...
Is SE linux preventing google earth from running? How do I tell SE Linux to get the heck out of the way?
That's a bit like asking how to turn off the burglar alarm so break-ins won't be so noisy. The correct question is how to set attributes correctly so google earth will run, and the answer may be in the SElinux report, as it often is. Real the report and see if it gives you a command to run which solves the problem.
-- Bill Davidsen davidsen@tmr.com
While your point is well taken Bill, looking at http://www.nsa.gov/selinux/papers/policy2/t1.html makes it clear that adjusting rules and policies is going to require more time and study than I can afford in the foreseeable future. I have a plate full.
The error status from selinux often contains the command to reset the attributes needed to make the application work. No research needed, drag and drop the command into a root shell, hit ENTER.
'twould be nice if that worked. :(
Unforch, I can't recall when the setroubleshooters advice ever worked here. The latest denial recommends a 'restorecon -v "./lp3"' but doesn't work on the only "./lp3" I could find on the system, in /etc/cups/interfaces/lp3. Using Brothers own drivers installed by their own rpms. I even did an autorelabel on the last reboot, no change in the error message I posted to the selinux list noonish yesterday, and no reply has been seen.
Since I see nothing directly relating to Google Earth there, setting /etc/selinux/config to "disable" will have to do until someone with a working knowledge of SE Linux chimes in or I get time to do the research in the future.
Thanks, just the same,
Mike
-- Bill Davidsen davidsen@tmr.com "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot
Bill Davidsen davidsen@tmr.com writes:
That's a bit like asking how to turn off the burglar alarm so break-ins won't be so noisy. The correct question is how to set attributes correctly so google earth will run, and the answer may be in the SElinux report, as it often is. Real the report and see if it gives you a command to run which solves the problem.
;-)
Good analogy, extra style points for making one feel guilty for turning off something that sounds like it should be a good thing to have on in general.
Each distribution, since I think FC4, I've tried to run selinux and after a short time decided it simply wasn't worth the trouble. On anything more complicated than a client-only, stand-alone system, I'd get low-probability failures creeping out of the woodwork forever. Selinux as currently delivered is a better DOS than any outside attacker has ever inflicted on WSRCC in the one and a half dozen years it has been on the net. (Now, I obviously still believe in chrooted, internet-faceing programs run as powerless per-daemon users, and I'm a firm stickler in no non-RSA/DSA remote logins. I just don't like my own system DOS-ing me randomly.)
This time on F10 selinux lasted exactly 15 minutes. The first time I tried to log in as an NFS automounted user, I realized that things have gotten worse in terms of working for me out of the box. Sure I could fight the issue and use the selinux tools to adjust the permissions, but why bother, it is clear this hasn't been well tested and using selinux will be an uphill battle with a pre-alpha quality permissions database that I'll essentially be maintaining on my own.
I strongly suspect that Red Hat doesn't run with selinux enabled on their corporate machines. From how rickety everything still is, it just doesn't feel like they eat their own dog-food. How can NFS-ed home directories possibly not work if they did? Folks from RH are of course encouraged to tell me how wrong I am.
-wolfgang
Wolfgang S. Rupprecht wrote:
Bill Davidsen davidsen@tmr.com writes:
That's a bit like asking how to turn off the burglar alarm so break-ins won't be so noisy. The correct question is how to set attributes correctly so google earth will run, and the answer may be in the SElinux report, as it often is. Real the report and see if it gives you a command to run which solves the problem.
;-)
Good analogy, extra style points for making one feel guilty for turning off something that sounds like it should be a good thing to have on in general.
Much easier to have on in distribution configuration on servers, not doing bizarre stuff. My mail, dns, dhcp servers run fine that way. Clients doing unusual stuff, not so much.
Each distribution, since I think FC4, I've tried to run selinux and after a short time decided it simply wasn't worth the trouble. On anything more complicated than a client-only, stand-alone system, I'd get low-probability failures creeping out of the woodwork forever. Selinux as currently delivered is a better DOS than any outside attacker has ever inflicted on WSRCC in the one and a half dozen years it has been on the net. (Now, I obviously still believe in chrooted, internet-faceing programs run as powerless per-daemon users, and I'm a firm stickler in no non-RSA/DSA remote logins. I just don't like my own system DOS-ing me randomly.)
This time on F10 selinux lasted exactly 15 minutes. The first time I tried to log in as an NFS automounted user, I realized that things have gotten worse in terms of working for me out of the box. Sure I could fight the issue and use the selinux tools to adjust the permissions, but why bother, it is clear this hasn't been well tested and using selinux will be an uphill battle with a pre-alpha quality permissions database that I'll essentially be maintaining on my own.
Haven't done amd home directories since SonOS (yes, the old 68030 based SunOS based on BSD), so I can't say, but having had similar issues bind mounting a home directory I know what you mean, the stock selinux doesn't like that.
I strongly suspect that Red Hat doesn't run with selinux enabled on their corporate machines. From how rickety everything still is, it just doesn't feel like they eat their own dog-food. How can NFS-ed home directories possibly not work if they did? Folks from RH are of course encouraged to tell me how wrong I am.
I haven't had any problems with system which permanently mount filesystem on local disk. That's a good bit of my usage, and all my server usage, the only thing worse than single points of failure is multiple single points of failure, and proper redundancy is expensive.
I don't have an answer for your automount issue, my bind mount (in rc.local) is followed by some selinux blessing, which I took directly from the warning in active but not enforcing mode. After I sprinkle the mount with holy water it works.
That's a bit like asking how to turn off the burglar alarm so break-ins won't be so noisy. The correct question is how to set attributes correctly so google earth will run, and the answer may be in the SElinux report, as it often is. Real the report and see if it gives you a command to run which solves the problem.
OK, I can turn off selinux, and not get any of these errors, or I can leave selinux on, get errors, look at the troubleshoot report, and follow the instructions to enable the program that had problems to go ahead and do whatever nasty things selinux detected. All without doing the kind of massive code review required to prove that the nasty things are actually harmless in this particular program's case.
So why isn't it much simpler and less trouble to just turn off selinux in the first place? I get the same level of security in the end, and much less hassle in the meantime :-).
(Some days I feel like I should start the Linux Curmudgeon blog, but there is probably one out there already - I haven't looked).
Tom Horsley wrote:
So why isn't it much simpler and less trouble to just turn off selinux in the first place? I get the same level of security in the end, and much less hassle in the meantime :-).
(Some days I feel like I should start the Linux Curmudgeon blog, but there is probably one out there already - I haven't looked).
I think that there's little doubt that selinux is a good idea. But it's only been recently that it worked well enough for me to actually leave it on, and even now I get AVC denial messages for stuff Fedora itself installs (got a few the other day when starting firefox on a *freshly upgraded* FC10 system.
This does strike me as a little sloppy. If Fedora installs it, shouldn't Fedora set selinux to allow it? Maybe I'm missing something...
I dunno. Selinux has always struck me like a car alarm that gives you thirty seconds to enter in a 100 digit code. Faced with that, it's no wonder people shut it down.
--Russell
On Sat, 2008-11-29 at 17:47 -0800, Russell Miller wrote:
This does strike me as a little sloppy. If Fedora installs it, shouldn't Fedora set selinux to allow it? Maybe I'm missing something...
Not necessarily. For example, when you enable Samba, you have to further enable an selinux setting if you're going to be sharing home directories via Samba. Otherwise, the requests are rejected by default. The idea here is that while a particular program may allow a variety of things to be done, you can use selinux to block things in a fine grained way, external to that program.
Why is this better than just not configuring the program to do things you don't want in the first place? The answer to that is the program itself might get subverted through something like a buffer overwrite.
Generally speaking, in the security world you default to the most restrictive behavior and administrators loosen up the restrictions as needed. This, of course, tends to annoy everyday users who don't realize all the insecurities of what they want to do, and just want it to work. I mean, all those flashing red lights and sirens can be annoying when all I want to do is start a little campfire over there next to the gas cans.
Make sense?
Wayne.
Wayne Feick wrote:
Generally speaking, in the security world you default to the most restrictive behavior and administrators loosen up the restrictions as needed. This, of course, tends to annoy everyday users who don't realize all the insecurities of what they want to do, and just want it to work. I mean, all those flashing red lights and sirens can be annoying when all I want to do is start a little campfire over there next to the gas cans.
Make sense?
Well, yes. But we're not talking about setting a campfire next to gas cans. I think we're overdoing the analogies.
I understand your rationale, but at some point, a security tool that gets in the way will cease being a security tool - and generally in a very dangerous way. If we want to extend your already tortured analogy a little, it's kind of like having a wall between the gas can and the campfire, but the only way to get to the wood to start the fire is to enter a code into a little door in the wall. And you can only take out one at a time. Eventually you'll just chop down the wall, and to hell with the consequences. And possibly use it for wood, but that's a different analogy that doesn't yet have a real world case. I'm sure we'll find one. :-)
It would be at least a nice thing to have a tool that asks you if you're doing some common things that selinux doesn't by default allow, make sure that's what you want to do, and set up selinux to allow them. At least then most people won't need to worry about it, but it might make common tasks easier for someone who really doesn't know what they're doing.
But I still maintain that things like firefox, which is a default install with no real changes to it, should never trigger an AVC alarm. A default Fedora install, with no local modifications to it, should never trigger AVC denials. But it happens frequently.
--Russell
Wayne.
Tom Horsley wrote:
OK, I can turn off selinux, and not get any of these errors, or I can leave selinux on, get errors, look at the troubleshoot report, and follow the instructions to enable the program that had problems to go ahead and do whatever nasty things selinux detected. All without doing the kind of massive code review required to prove that the nasty things are actually harmless in this particular program's case.
So why isn't it much simpler and less trouble to just turn off selinux in the first place? I get the same level of security in the end, and much less hassle in the meantime :-).
Of course that isn't quite true. What you would have done is made the decision to trust a single program. You haven't disable the various selinux protection schemes for other components. In other words, you've handed out a set of keys. You've not unlocked and opened all the doors and all the windows and turned off the alarm system.
Ed Greshko wrote:
Tom Horsley wrote:
OK, I can turn off selinux, and not get any of these errors, or I can leave selinux on, get errors, look at the troubleshoot report, and follow the instructions to enable the program that had problems to go ahead and do whatever nasty things selinux detected. All without doing the kind of massive code review required to prove that the nasty things are actually harmless in this particular program's case.
So why isn't it much simpler and less trouble to just turn off selinux in the first place? I get the same level of security in the end, and much less hassle in the meantime :-).
Of course that isn't quite true. What you would have done is made the decision to trust a single program. You haven't disable the various selinux protection schemes for other components. In other words, you've handed out a set of keys. You've not unlocked and opened all the doors and all the windows and turned off the alarm system.
I was going to make that point, but your analogy is elegant, and I think I'll just save it for future quoting.
On Sat, Nov 29, 2008 at 20:41:51 -0500, Tom Horsley tom.horsley@att.net wrote:
So why isn't it much simpler and less trouble to just turn off selinux in the first place? I get the same level of security in the end, and much less hassle in the meantime :-).
Because you can still leave it protecting other processes on the system by either using pemissive domains or using audit2allow to generate rules you can use to add a new policy module.
What would be really nice is if people reported these issues to bugzilla instead of or in addition to griping about them here. Then either the app or the policy could be fixed for everyone else.
Bruno Wolff III wrote:
On Sat, Nov 29, 2008 at 20:41:51 -0500, Tom Horsley tom.horsley@att.net wrote:
So why isn't it much simpler and less trouble to just turn off selinux in the first place? I get the same level of security in the end, and much less hassle in the meantime :-).
Because you can still leave it protecting other processes on the system by either using pemissive domains or using audit2allow to generate rules you can use to add a new policy module.
What would be really nice is if people reported these issues to bugzilla instead of or in addition to griping about them here. Then either the app or the policy could be fixed for everyone else.
Sorry, I assume that the QA process includes someone actually installing the application and seeing that it works. I would rather see things sit in updates-testing until someone is willing to sign off that they actually have been at least smoke tested?
It doesn't need to be some maintainer who does that, anyone who is going to use the package can take a moment to do the sign off, assuming that there's a process to identify people as capable of installing a package with selinux enabled (lots of folks), and willing to do so (still hopefully a non-empty set).
If Fedora is going to ship with SElinux enabled, it also should be working. I keep one fully patched VM for testing things, just create a qcow clone and and run the test. Great for opening those web sites which may be useful or may have evil, among other things.
On Mon, Dec 01, 2008 at 13:35:12 -0500, Bill Davidsen davidsen@tmr.com wrote:
Sorry, I assume that the QA process includes someone actually installing the application and seeing that it works. I would rather see things sit in updates-testing until someone is willing to sign off that they actually have been at least smoke tested?
That doesn't mean that filing bugs to get problems fixed (or at least tracked) is a bad idea. That applies to any bug, not just selinux ones.
It doesn't need to be some maintainer who does that, anyone who is going to use the package can take a moment to do the sign off, assuming that there's a process to identify people as capable of installing a package with selinux enabled (lots of folks), and willing to do so (still hopefully a non-empty set).
There should be something in the packaging guidelines or the package review process about testing with selinux enabled. (If there isn't already.)
If Fedora is going to ship with SElinux enabled, it also should be working.
Just like anything else.
-
Bill Davidsen -
Bruno Wolff III -
Ed Greshko -
Gene Heskett -
Mike Faire -
Russell Miller -
Tom Horsley -
Wayne Feick -
Wolfgang S. Rupprecht