Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SElinux issue #19

Closed
tsumi opened this Issue Sep 19, 2016 · 24 comments

Comments

10 participants
@tsumi
Copy link

tsumi commented Sep 19, 2016

Hi,
i noticed that x86 centOS 7 image have SElinux disabled even if enforcing is specified in the config file.

Step to reproduce:

  • Create a new VC1S VPS with Centos 7 image
  • Just after boot up:
[root@srv ~]# getenforce
Disabled
[root@srv ~]# setenforce 1
setenforce: SELinux is disabled
[root@srv ~]# cat /etc/selinux/config 

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of three two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected. 
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

Am I missing something or there is a boot in bootimage?
Thanks

@FlorianHeigl

This comment has been minimized.

Copy link

FlorianHeigl commented Oct 3, 2016

I think it should be set disabled at the very least.
I found a nagios check to monitor the status:
https://github.com/opinkerfi/nagios-plugins/tree/master/check_selinux

nonetheless I'd also like it to be enabled of course :)

@frafra

This comment has been minimized.

Copy link

frafra commented Dec 30, 2016

I think that the CentOS image should be as close as possible to the official CentOS standard installation.
Could it be related with scaleway/image-fedora#20?

@FlorianHeigl

This comment has been minimized.

Copy link

FlorianHeigl commented Jan 1, 2017

@frafra agreed, it would be helpful to have a kinda normal kernel (and bootup) - but the current setup is just too different (reboot with console attached). Just supporting NBD well enough will probably not ever work with stock CentOS kernel.
Anyway, what you can do: You can nowadays switch to the Fedora bootscript to enable SELinux.
That means you'll run a non-CentOS kernel, but it works pretty OK.

@pdonadeo

This comment has been minimized.

Copy link

pdonadeo commented Jul 5, 2017

Is there a way to enable enforcing SELinux on CentOS image? Having it disabled in 2017 is not good at all.

@The-Loeki

This comment has been minimized.

Copy link

The-Loeki commented Jul 11, 2017

@pdonadeo

Anyway, what you can do: You can nowadays switch to the Fedora bootscript to enable SELinux.

@pdonadeo

This comment has been minimized.

Copy link

pdonadeo commented Jul 11, 2017

@The-Loeki thanks, I already solved the way you suggested. But the default CentOS configuration remains a PITA, in my opinion.

@The-Loeki

This comment has been minimized.

Copy link

The-Loeki commented Jul 11, 2017

oh, that we all can agree on https://stopdisablingselinux.com/

@pdonadeo

This comment has been minimized.

Copy link

pdonadeo commented Jul 11, 2017

@The-Loeki WOW, thanks for the link 😸

@danhawker

This comment has been minimized.

Copy link

danhawker commented Sep 18, 2017

@The-Loeki
Can you detail how you enabled SELinux on the CentOS image, and which image/arch do you refer to?? Am currently using the CentOS image on aarch64 and no matter what I do, I can't get SELinux to be enabled, neither in permissive or enforcing.

Steps

  • Set the bootscript to use a SELinux enabled kernel (arm64 4.9.32 docker in my case)
  • Boot CentOS image
  • Re-label the filesystem (using either touch /.autorelabel or fixfiles)
  • Reboot
  • Login and use setenforce 1

However I always get

[root@scw-2a025d ~]# setenforce 1
setenforce: SELinux is disabled

If I look at the running kernel, it looks like SELINUX is enabled, but is disabled by default on the kernel parameter at bootup (CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0). Which is OK, however it seems that runtime activation isn't working as expected. So even after I use setenforce, it doesn't take.

[root@scw-2a025d ~]# zcat /proc/config.gz | grep SELINUX
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_DEFAULT_SECURITY_SELINUX is not set

I've raised a support ticket to Scaleway and they responded that this is currently unsupported, but to track issues on github.

Is there any update regarding SELinux on aarch64? Wonder if the newer kernels are more SELinux friendly.

@The-Loeki

This comment has been minimized.

Copy link

The-Loeki commented Sep 18, 2017

From the top of my head (and mind you, on an x86_64 image, haven't gotten around doing this on any ARM yet):

  • Switch bootscript to something w/Fedora in it
  • Enable SElinux in /etc/selinux/config (it's hard-disabled IIRC)
  • do the touch thang to relabel (even though coming back from a full disable will trigger it too)
  • profit

I do have to say I'm having serious problems w/Scaleway stating 'it's not supported'... It is in fact widely supported by Red Hat, I've never had issues on our CentOS VM's here and the hypervisor shouldn't give a hoot.

@danhawker

This comment has been minimized.

Copy link

danhawker commented Sep 18, 2017

@The-Loeki
Hmm, yeah thats basically what I've been doing, but on aarch64.

OK, I think the kernel is the issue then. Scaleway doesn't provide a 'fedora' labelled kernel for aarch64 (there is for armv7), which I guess was added for exactly this reason.

WRT unsupported - pretty sure they mean from their point of view, at the moment, but agree that it is widely supported and the hypervisor (KVM on aarch64) shouldn't care either way.

Anyone know where I can raise a ticket for a fedora kernel variant for aarch64?

@metal3d

This comment has been minimized.

Copy link

metal3d commented Nov 24, 2017

That's the same here, cannot install OpenShift 3.6 that needs to have selinux enabled.
The problem should be resolved by scaleway because Centos 7.3 (x86 here) has no problem with selinux in other platforms...

Any chance to force selinux to be enabled ?

@starlilyth

This comment has been minimized.

Copy link

starlilyth commented Jan 9, 2018

Scaleway images have been altered to prevent SELinux from being enabled:

# zcat /proc/config.gz | grep SELINUX
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_DEFAULT_SECURITY_SELINUX is not set

Specifically: CONFIG_SECURITY_SELINUX_DISABLE=y

@starlilyth

This comment has been minimized.

@starlilyth

This comment has been minimized.

Copy link

starlilyth commented Jan 9, 2018

This configuration error was likely made by a careless admin hitting enter without looking closely while configuring the kernel image. Scaleways adamant refusal to address it for months is probably a clear indicator of how they handle all support issues (and this has proven true in my interactions so far).
Further, their obvious inexperience with security fundamentals on the largest enterprise Linux platforms makes me question the integrity of their infrastructure.
It is becoming clear they are not a serious choice for production use.

@FlorianHeigl

This comment has been minimized.

Copy link

FlorianHeigl commented Jan 9, 2018

Sure, if there's a major design error in the platform, it's definitely time to blame an admin for it.
surely it wasn't the gods who designed or build the things, because everyone can see they are spotless, after all they call themselves engineers.

(also, since they boot another kernel first, and then launch into our OS... it can never be assumed to be secure)

@The-Loeki

This comment has been minimized.

Copy link

The-Loeki commented Jan 11, 2018

@FlorianHeigl I don't appreciate the pointless and rather uninformed innuendo. The issue, it's cause and it's workaround are all well documented here and it's blatantly obvious this is a (wrong) Scaleway decision if you take the time to study the problem.

Furthermore, the fact that they 'boot another kernel first' has nothing to do with anything at all. Nor has it any additional security implications, as that is the very definition of a hypervisor anyway.

Also note that SELinux is pretty far from spotless, but again that is an entirely different matter

@FlorianHeigl

This comment has been minimized.

Copy link

FlorianHeigl commented Jan 11, 2018

Sorry, but I find it just as pointless if people are pulling the "human error" or "careless admin" card for things that are obvious design flaws.
And I see little reason this should always be something to just suck up and live with.
There's enough research to prove that this attitude is a constant cause of errors.

I was speaking of the baremetal systems (which is the standard platform at scaleway), do a scw attach and watch the complete process.
There's no hypervisor there, and the boot procedure includes running a lot of things prior to what you see as your running OS later. There's no way to have a secure base on this platform. One has to know what to use it for.

We don't need to discuss SELinux per se. I'm trying to get this supported just as long as you do.

@The-Loeki

This comment has been minimized.

Copy link

The-Loeki commented Jan 11, 2018

Figures; we're only using the VM's for now, hence the difference :)

For me 'obvious design flaw' equates to 'human error' or 'careless admin/architect' in this case.
Point is there's absolutely no argument for the obvious design flaw other than "we can't be bothered by it" which sux as a security design.

And granted, I'm guessing the major reason to do it this way probably wasn't in the tech; it was probably over fears of support case load.
Better to ignore some nerds talking to each other about disabling it than a truck load of n00bs having all kinds of SELinux troubles maybe?

@yamatt

This comment has been minimized.

Copy link

yamatt commented Apr 4, 2018

Thought I'd check out this Fedora boot option with the new CentOS 7.3 image and I can't seem to find a network when it boots. Anyone able to confirm? I reconfirmed it works ok for the CentOS 7.2 image.

My steps to reproduce:

  1. Create server
  2. Use defaults
  3. Select CentOS 7.3
  4. Select create
  5. Make sure the machine is off
  6. In server settings press the 'Show' button next to advanced.
  7. In the Bootscript setting select the option that contains Fedora in the description. For me right now it says x86_64 4.10.8 fedora #1
  8. Switch the server back on

You can see that it is trying some wget thing that keeps failing (for me at least) in the Console pane and ssh fails.

@halmartin

This comment has been minimized.

Copy link
Contributor

halmartin commented Apr 25, 2018

@yamatt please open a new issue for your problem, this is not related to SELinux.

@halmartin

This comment has been minimized.

Copy link
Contributor

halmartin commented Apr 25, 2018

@The-Loeki @FlorianHeigl @tsumi

SELinux is enabled and enforcing in the new CentOS 7.4 x86_64 image, provided you are using local boot on VC1 as this uses the CentOS distribution kernel.

If you are creating a CentOS VM (not baremetal) I would recommend you create a new CentOS 7.4 VC1 instance and enable local boot to enjoy SELinux support.

There is no direct migration path for older images, as the partition table needs to change to support EFI booting.

Therefore, the migration path for earlier CentOS images would be to shut off your instance, attach the disk to the new CentOS 7.4 VC1 instance, and copy the data.

I would recommend you do this AFTER the first boot, as during the first boot an SELinux relabel takes place, and if you attach your previous VM disk this will take a very long time and may result in your instance being halted (as we cannot signal the server has booted until after the initial SELinux relabel).


As for network boot and baremetal servers, we are aware that lack of SELinux support bothers many people wishing to run CentOS. We are evaluating the options for supporting SELinux on these platforms.

For the time being, if you need SELinux for your use case, please use a VC1 instance with local boot.

@The-Loeki

This comment has been minimized.

Copy link

The-Loeki commented Apr 25, 2018

Thank you! It's very satisfying to see Scaleway's finally dedicated some engineering/dev time to this wart of an issue!

@halmartin

This comment has been minimized.

Copy link
Contributor

halmartin commented Apr 26, 2018

If you experience issues with SELinux in the new CentOS 7.4 image on VC1 instances, please open a new issue describing your problem in detail.

C1 and C2 instances are still using a network kernel which does not support SELinux. If you need SELinux support, please consider using a VC1 instance instead.

There are also plans to support CentOS 7.4 with SELinux in ARM64 instances, and I hope to have more news for you about this in the coming weeks.

Since the initial issue with SELinux was opened against VC1 instances, and this has now been resolved, I am closing this issue.

I will open a new issue (#30) to address lack of SELinux for instances using bootscripts (C1, C2, ARM64).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.