10:44 a.m.
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
12:49 p.m.
New subject: Selinux
On Mon, Dec 01, 2008 at 13:35:12 -0500,
Bill Davidsen <davidsen(a)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.
12:35 p.m.
New subject: Selinux
Bruno Wolff III wrote:
On Sat, Nov 29, 2008 at 20:41:51 -0500,
Tom Horsley <tom.horsley(a)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.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
12:28 p.m.
New subject: Selinux
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.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
7:05 p.m.
New subject: Selinux
Wolfgang S. Rupprecht wrote:
Bill Davidsen <davidsen(a)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.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
11:55 p.m.
New subject: Selinux
On Sat, Nov 29, 2008 at 20:41:51 -0500,
Tom Horsley <tom.horsley(a)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.
4:22 p.m.
New subject: Selinux
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.
10:58 a.m.
New subject: Selinux
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.
8:21 p.m.
New subject: Selinux
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.
7:47 p.m.
New subject: Selinux
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
7:41 p.m.
New subject: Selinux
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).
9:08 p.m.
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(a)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(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
I am looking for a honest man.
-- Diogenes the Cynic
6:45 p.m.
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(a)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
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
4:10 p.m.
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(a)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
12:45 p.m.
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.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
4:31 p.m.
New subject: Selinux (was: Re: Googleearth won't run on F10)
Bill Davidsen <davidsen(a)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 http://www.full-steam.org/ (ipv6-only)
You may need to config 6to4 to see the above pages.
5646
days inactive
5649
days old
15 comments
9 participants
participants (9)
-
Bill Davidsen -
Bruno Wolff III -
Ed Greshko -
Gene Heskett -
Mike Faire -
Russell Miller -
Tom Horsley -
Wayne Feick -
Wolfgang S. Rupprecht