LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   SELinux Enabled, SSHD Daemon Fails (https://www.linuxquestions.org/questions/linux-security-4/selinux-enabled-sshd-daemon-fails-4175589956/)

pyrovortex 09-22-2016 12:11 PM

SELinux Enabled, SSHD Daemon Fails
 
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

unSpawn 09-23-2016 11:04 AM

I found you run Fedora 16 (necroposts are not appreciated https://www.linuxquestions.org/quest...1/ 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.

pyrovortex 09-28-2016 11:01 AM

Quote:

Originally Posted by unSpawn (Post 5609172)
I found you run Fedora 16 (necroposts are not appreciated https://www.linuxquestions.org/quest...1/ 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

c0wb0y 09-28-2016 02:11 PM

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

pyrovortex 09-29-2016 12:57 PM

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

c0wb0y 09-29-2016 01:12 PM

Quote:

Originally Posted by pyrovortex (Post 5611629)
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?

Jjanel 09-29-2016 11:19 PM

Maybe: seinfo -t
 
(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

c0wb0y 09-30-2016 01:06 AM

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*

pyrovortex 09-30-2016 11:36 AM

Quote:

Originally Posted by c0wb0y (Post 5611880)
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

pyrovortex 09-30-2016 11:46 AM

Quote:

Originally Posted by c0wb0y (Post 5611641)
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?

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

Thanks

c0wb0y 09-30-2016 07:53 PM

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?

unSpawn 10-02-2016 01:04 PM

Quote:

Originally Posted by pyrovortex (Post 5610990)
The fedora 16 version is from my workplace and so cannot exactly switch to version 23.

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.

pyrovortex 10-05-2016 07:37 AM

Quote:

Originally Posted by c0wb0y (Post 5612237)
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?

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

pyrovortex 10-05-2016 07:49 AM

Quote:

Originally Posted by unSpawn (Post 5612812)
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 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

jpollard 10-05-2016 09:02 AM

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_u:object_r:lib_t:s0

c0wb0y 10-06-2016 04:33 PM

Quote:

Originally Posted by pyrovortex (Post 5614166)
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

Sorry, but I'm not sure how you can get up-to-date if your base OS is long gone?

jpollard 10-06-2016 07:19 PM

Quote:

Originally Posted by c0wb0y (Post 5614845)
Sorry, but I'm not sure how you can get up-to-date if your base OS is long gone?

One way is to update the libraries/utilities known to have vulnerabilities manually.

Which is what I suspect has happened in this case. Doing it manually is relatively easy (I used to do it all the time).

The one thing tricky is when SELinux is active. You also have to set the security label on the result.

jpollard 10-06-2016 07:33 PM

Quote:

Originally Posted by c0wb0y (Post 5614845)
Sorry, but I'm not sure how you can get up-to-date if your base OS is long gone?

One way is to update the libraries/utilities known to have vulnerabilities manually.

Which is what I suspect has happened in this case. Doing it manually is relatively easy (I used to do it all the time).

The one thing tricky is when SELinux is active. You also have to set the security label on the result.

The problem here is the "cannot enable executable stack". That should be a bug in the library (the executable stack is a flag in the ELF header for the library).

You can try installing the "execstack" package to see what is going on. You can try "execstack -c <library>" (this should clear the flag calling for an executable stack) and then try it out. I don't believe libcrypto is supposed to be using an executable stack, so I'm not sure how it would have gotten set. If clearing the flag causes sshd to fail then you have a buggy library.

You can find the manpage on execstack at https://linux.die.net/man/8/execstack and see what it does before installing it.

I think the package should be available in an archived repository, though you might have to look for one.

BTW, I apologize for missing the obvious. You clearly stated the problem, yet I missed it.

pyrovortex 10-07-2016 10:30 AM

Quote:

Originally Posted by jpollard (Post 5614188)
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_u:object_r:lib_t:s0

Hi,

libcrypto.so.1.0.0 on my box was from OpenSSL and the context on the file is same as yours "system_u:object_r:lib_t:s0".
But is it possible that Selinux recognizes a manually installed file and gives it a context ? I am under the impression that based on the directory, the underlying files get their contexts.


Thanks

pyrovortex 10-07-2016 10:39 AM

Quote:

Originally Posted by jpollard (Post 5614893)
One way is to update the libraries/utilities known to have vulnerabilities manually.

Which is what I suspect has happened in this case. Doing it manually is relatively easy (I used to do it all the time).

The one thing tricky is when SELinux is active. You also have to set the security label on the result.

The problem here is the "cannot enable executable stack". That should be a bug in the library (the executable stack is a flag in the ELF header for the library).

You can try installing the "execstack" package to see what is going on. You can try "execstack -c <library>" (this should clear the flag calling for an executable stack) and then try it out. I don't believe libcrypto is supposed to be using an executable stack, so I'm not sure how it would have gotten set. If clearing the flag causes sshd to fail then you have a buggy library.

You can find the manpage on execstack at https://linux.die.net/man/8/execstack and see what it does before installing it.

I think the package should be available in an archived repository, though you might have to look for one.

BTW, I apologize for missing the obvious. You clearly stated the problem, yet I missed it.


Nailed it with the explanation. I am not sure how expressive I could be and so was trying hard to think about analogies.
I will try out the "execstack" based proposed solution and update you soon.

Thanks

jpollard 10-07-2016 08:30 PM

Quote:

Originally Posted by pyrovortex (Post 5615084)
Nailed it with the explanation. I am not sure how expressive I could be and so was trying hard to think about analogies.
I will try out the "execstack" based proposed solution and update you soon.

Thanks

You did fine. It was my error.

pyrovortex 12-29-2016 09:38 AM

Hi All,

Thanks for chipping in.

Closing the thread.

Thanks!


All times are GMT -5. The time now is 04:40 AM.