Re: [COOT] coot on fedora 14 with selinux enabled

[Kay Diederichs]

Am 11.04.2011 16:26, schrieb Leonid Flaks:

On 04/07/2011 09:07 AM, Kay Diederichs wrote:

On 04/07/2011 02:32 PM, Leonid Flaks wrote:

On 04/07/2011 02:23 AM, Kay Diederichs wrote:

Am 20:59, schrieb Leon Flaks:

I am running coot on 64-bit Fedora 14 installed from binaries
compiled for centos 5 with both gtk and python. I made a number of
links to so libraries somewhat similar to the ones described on this
list last month. However, there is another issue I ran into, which
prevented coot from starting. selinux is enabled and it is
complaining about executable stack set on the library libgmp.so.3 .
This library comes with coot tarbal. There is another copy of the
same library on the system which has this flag set properly, but of
course, coot uses the one that comes with it.
To fix this issue I had to run 'execstack -c
$coot_root_dir/lib/libgmp.so.3.3.0', which solved my problem. Coot is
installed on the nfs server, so this command had to be executed on
the server as root. Coot is happy after that and runs without
problems.
However, every time I download the new version (I tried 3455
yesterday), I have to fix this stack flag.
Would it be possible to get it done on the server, so that binaries
that come with the tarbal have it fixed already?

Thanks,

Leon

why not simply delete coot's version of libgmp.so.3.3.0 after
downloading it? coot then should find and use the system-supplied
library.

HTH,

Kay

Thanks for the reply!
I'll test it next week. But how is your suggestion any better then the
one I was doing? rm command is shorter then execstack ;-) but you need
to remove the link to libgmp.so.3 also. Would it be better to have it
fixed in the binary?

Leon

Leon,

Kay, I have a few comments to your reply.

I suppose it's better since you can "fix" it yourself with ordinary
user privileges - IOW you don't need to bother your system
administrator with it. (I don't understand why a link to libgmp.so.3
has to be removed.)

In my environment both commands require root privileges, and I did not
think about the other possible situation, where it would be easier - you
definetly have a point here. Regarding libgmp.so.3. In coot version that
I downloaded the binary is libgmp.so.3.3.0 and it has two links pointing
to it - libgmp.so.3 and libgmp.so
I got a complain about execstack for libgmp.so.3 - obviously coot was
trying to load this library. If I remove the target and live the broken
link behind, that would not likely make coot use the system-supplied
version. I would suggest to remove the other link (libgmp.so) also.

"fix in the binary" ? - the binary is built for CentOS-5, whereas you
run FC14. I'm not sure if running 'execstack -c
$coot_root_dir/lib/libgmp.so.3.3.0' will not have undesirable side
effects on CentOS-5 machines.

About execstack complain. I am not an expert in selinux issues. There is
a good and very short note about it at
http://danwalsh.livejournal.com/6117.html?thread=23525 written by the
main developer of selinux. The chapter on execstack has a few good
points. I highly recommend looking at it.
I can't help quoting a couple sentences here;

"Some libraries/applications are accidentally marked as requiring
execstack. These usually happen because of a mistake in the build
procedure."
and a few lines below that -

"You should immediately report this as a bugzilla to the packager and/or
the upstream maintainer to fix the code."

That is why I reported this issue on this list in the first place. I
also thought it might help others solve the problem as it was not
trivial to find both the problem and solution.
I don't think that this fix would have any effect on CentOS, but it is
worth checking. I don't have any CentOS around, might try Scientific
Linux 5 instead. That would be a pure exercise - I don't have any plans
on using it.

The proper way might be to compile&link on a FC14 machine. But that
boils down to the question for which platforms there have to be
separate builds ... have you counted the existing ones?

There is a version of coot available as a part of Fedora 14
distribution. Unfortunately it was built some time ago and is rather old
on the scale of how fast this program is moving both in fixing bugs and
introducing new features.

best,

Kay

In short - this library has a potential security issue in the form it is
distributed.

Thanks again,
Leon

Hi Leon,




c) run coot - it should pick up the system-supplied libgomp*



best,

Kay

I'm a big fan of KISS - my translation would be "keep it simple and standard". The KISS principle states that simplicity should be a key goal in design, and that unnecessary complexity should be avoided (from Wikipedia). In this case I feel you're doing things in a unnecessarily complex way. Surely I may be missing something or understand the situation wrongly - but I'd try: a) unpack the coot tarfile (obviously to a location you can write to; this does not require root privs) b) rm <some_path>/libgomp* (IOW get rid of libgomp.so.3* which surely is only provided by the coot tarfile because version 3 of libgomp is _not_ provided by CentOS-5/RHEL5.) I don't see where "execstack" (have not heard of that before although I do use SELinux on my machines!) then enters the picture. Whether the distributed (by coot) libgomp.so presents a security risk to CentOS-5 users is something that I wouldn't lose sleep over.

smime.p7s
Description: S/MIME Cryptographic Signature