LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 09-22-2016, 12:11 PM   #1
pyrovortex
LQ Newbie
 
Registered: Sep 2016
Posts: 10

Rep: Reputation: Disabled
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
 
Old 09-23-2016, 11:04 AM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,415
Blog Entries: 55

Rep: Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594
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.
 
Old 09-28-2016, 11:01 AM   #3
pyrovortex
LQ Newbie
 
Registered: Sep 2016
Posts: 10

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by unSpawn View Post
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
 
Old 09-28-2016, 02:11 PM   #4
c0wb0y
Member
 
Registered: Jan 2012
Location: Inside the oven
Distribution: Windows
Posts: 417

Rep: Reputation: 74
Unfortunately, you can't use SELinux and avoid audit2allow entirely. Same is true with semanage tools.
 
Old 09-29-2016, 12:57 PM   #5
pyrovortex
LQ Newbie
 
Registered: Sep 2016
Posts: 10

Original Poster
Rep: Reputation: Disabled
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
 
Old 09-29-2016, 01:12 PM   #6
c0wb0y
Member
 
Registered: Jan 2012
Location: Inside the oven
Distribution: Windows
Posts: 417

Rep: Reputation: 74
Quote:
Originally Posted by pyrovortex View Post
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?
 
Old 09-29-2016, 11:19 PM   #7
Jjanel
Member
 
Registered: Jun 2016
Distribution: any&all, in VBox; Ol'UnixCLI; NO GUI resources
Posts: 999
Blog Entries: 12

Rep: Reputation: 363Reputation: 363Reputation: 363Reputation: 363
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
 
Old 09-30-2016, 01:06 AM   #8
c0wb0y
Member
 
Registered: Jan 2012
Location: Inside the oven
Distribution: Windows
Posts: 417

Rep: Reputation: 74
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*
 
Old 09-30-2016, 11:36 AM   #9
pyrovortex
LQ Newbie
 
Registered: Sep 2016
Posts: 10

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by c0wb0y View Post
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
 
Old 09-30-2016, 11:46 AM   #10
pyrovortex
LQ Newbie
 
Registered: Sep 2016
Posts: 10

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by c0wb0y View Post
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_ubject_r:lib_t:s0"
And i did not run into problems when running in permissive mode.

Thanks
 
Old 09-30-2016, 07:53 PM   #11
c0wb0y
Member
 
Registered: Jan 2012
Location: Inside the oven
Distribution: Windows
Posts: 417

Rep: Reputation: 74
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?
 
Old 10-02-2016, 01:04 PM   #12
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,415
Blog Entries: 55

Rep: Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594
Quote:
Originally Posted by pyrovortex View Post
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.
 
Old 10-05-2016, 07:37 AM   #13
pyrovortex
LQ Newbie
 
Registered: Sep 2016
Posts: 10

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by c0wb0y View Post
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
 
Old 10-05-2016, 07:49 AM   #14
pyrovortex
LQ Newbie
 
Registered: Sep 2016
Posts: 10

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by unSpawn View Post
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
 
Old 10-05-2016, 09:02 AM   #15
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,900

Rep: Reputation: 1506Reputation: 1506Reputation: 1506Reputation: 1506Reputation: 1506Reputation: 1506Reputation: 1506Reputation: 1506Reputation: 1506Reputation: 1506Reputation: 1506
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

Last edited by jpollard; 10-05-2016 at 09:06 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] SSHD Alternative Port + selinux Sum1 CentOS 4 05-20-2016 06:32 AM
how do you know if selinux is enabled in SLES 11 redhatwannabe SUSE / openSUSE 2 03-20-2014 05:12 PM
FC8 sshd default configuration fails SeLinux john@ackley.net Linux - Software 1 12-29-2007 05:47 AM
how do i tell of selinux is enabled or not? sneakyimp Linux - Newbie 2 10-22-2007 07:13 PM
FollowSymLinks and SELinux enabled piforever Linux - Security 9 02-27-2006 10:09 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 07:43 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration