Hi All,

I have Selinux enabled and once the box comes up after the reboot, SSHD service enters a failed state.

On doing a systemctl restart sshd.service , I get the output as below :

"error while loading shared libraries : libcrytpo.so.1.0.0 : cannot enable executable stack as shared object requires : Permission denied"

the context of libcrypto.so.1.0.0 is system_u: object_r:lib_t:s0

Any guidance would be deeply appreciated!

Thanks

I found you run Fedora 16 (necroposts are not appreciated https://www.linuxquestions.org/quest...1/#post5609107 by the way) and you should not ever run EOL Fedora: version 23 is current IIRC. Please install that or choose a Linux distro with longer version support.

Unspawn,

Thanks for the reply.
The fedora 16 version is from my workplace and so cannot exactly switch to version 23.
I will keep that in mind about necroposts.

And using audit2allow ( it gave me a custom TE rules to be implemented based on the error message generated) I have found a way to make SSHD run. But I am looking further into eliminating the use of audit2allow.

Is there a location/file where a user can update Type Enforcement Rules permanently without using audit2allow?

Thanks

Unfortunately, you can't use SELinux and avoid audit2allow entirely. Same is true with semanage tools.

So there is no such file which has a list of all the type enforcement rules?

Like "/etc/selinux/targeted/contexts/files/file_contexts" which has all the file contexts.

Thanks

This does not look good. If you try a matchpathcon <sample-file> does it spits any output?
Maybe run SELinux on permissive mode then see if you can restart sshd with no issues?

(excuse my jumping-in here, since I'm just reading to learn & have no expertise here)
I picked up on the question in post #5, and web-searched it and found an LQ thread:
list all Type Enforcement contexts that exist on the system

The output of the semanage fcontext -l | grep named as per your link is the mapping of files named 'named' to their contexts. The same information can ge gleaned at /etc/selinux/<policy>/context/files/file_contexts*

So when I first ran into the original issue ( libcrypto.so.1.0.0 ) did not have access and so SSHD would fail. Running "semanage fcontext -l" would also fail citing the reason "ImportError: libcrypto.so.1.0.0: cannot enable executable stack as shared object requires: Permission denied".
Now after audit2allow fixed the issue with sshd, I have the same import error when running "semanage fcontext -l".
Looks like i have to create a new TE rule to let semanage access libcrypto.so.1.0.0

On doing a matchpathcon, it spits out the context of the file "system_ubject_r:lib_t:s0"
And i did not run into problems when running in permissive mode.

Thanks

I just realized that your OS is Fedora 14 which is long gone. I think getting SELInux to work on that OS is quite not worthwhile for various reasons such as a) vulnerabilities of old Openssl, Bash (remember Heartbleed?) amongst other things. We may or may not be able to get sshd to work with Selinux if you are persistent and this will involve creating custome TE. To start with, grep all the denials on audit.log related to sshd then pipe that to audit2allow to create a custome type enforcement.

By the way, do you have basic idea how SELinux works if you don't mind me asking?

Yes you can, for two reasons:
0) regardless of where you work it is a clear and present risk to work with outdated, unsupported software. This is made worse if your machine is networked, which it seems to be.
1) it's Fedora policy and for good reasons. If you can't / won't keep up then please choose a Linux distro with a more common release scheme or choose one of the Enterprise / LTS ones.


Before you dismiss this all please consider the risk in general and specifically all the OpenSSH, OpenSSL etcetera vulnerabilities since February 2013 which was the End Of Life date of F 16.

I use only the kernel from FC16 and from a security point of view, we put in the updates immediately when patches are available (OpenSSL/Bash as mentioned).
And yes, using Audit2Allow i could put in place a custom TE and make SSHD to run in 'enforcing' mode of Selinux.
I picked up Selinux a month ago and putting in the effort to come up to a decent understanding of how it works.

So after getting SSHD to work courtesy of audit2allow, my question is, as audit2allow creates a new TE, any idea where all the TEs are stored so that I can do a before and after for SSHD and find out the 'fix' TE ??

Thanks

I understand your concern unspawn but I can assure you that I am up to date ( software wise ) with all the security vulnerabilities that have been in the open till today.

Thanks

Where did you get libcrypto.so.1.0.0?

That doesn't appear to be a version used by Fedora 16. On my system it is libcrypto.so.1.0.0j

The package install for sshd for Fedora 16 would include the package for libcrypto that has the appropriate security label.

What you have installed is either not properly labeled, or is the wrong package.

If you manually installed the library, you have to properly label it or it will not be used. I would almost bet the label type is either unknown, or not "lib_t". On my system (an archived Fedora 16) the full label is system_ubject_r:lib_t:s0