SELinux disabled

[drparsec]

Hi,
I very appreciate your work and definately want to say "Thanks".

I usually use SELinux to gain a bit more security on my Linux installations. Unfortunately, SELinux is disabled (or to be precise not compiled into the kernel). Thus I am used to download a nwe kernel and the correspoding sources, get the config, enable SELinux, and do the kernel and module compile. Since this is quite time consuming, I would rather ask you if you could enable SELinux in your kernel.

Thanks

[popcornmix]

Can you explain exactly what you do to the kernel to enable SELinux?

[drparsec]

Sure,
I do the following:
Copy and unpack the config from /proc as .config into kernel sources. Run <bmake menuconfig and go to Security Options. Activate the items Socket and Networking Security Hooks, NSA SELinux Support, NSA SELinux Development Support, and NSA SELinux AVC Statistics. I leave the value of NSA SELinux checkreqprot default value at 1.

Just one warning if you try it with fedora 21 as I do: You should not activate SELinux straight away but set the variable SELINUX temporarily to permissive in the /etc/selinux/config file since you probably have to do an relabeling first by

touch /.autorelabel

and reboot.

Cheers and thanks

[popcornmix]

That's a pretty intrusive option which very few people will care about. There is a big question mark over performance: https://lkml.org/lkml/2004/8/7/155

I think we'd need a lot of evidence that the options are harmless and and required by many users to consider this. It may make sense for specific distributions to enabled it - you could try asking the fedora maintainers.

[Ferroin]

There really isn't all that much of a question over performance, it will be slower with this (or any other LSM) turned on, and SELinux is one of the heavier LSM's too.

Fedora has it built in by default, I forget if they enable it though.

I'd personally say that this is more of a niche option, and anyone who is messing around with it should probably build their own kernel (not just for SELinux, but due to the fact that there are other options that should be enabled for completeness, most of which are kind of cumbersome on a system designed for education and development).

[popcornmix]

I'll close this as it's unlikely to be enabled.
If other users want this feature they can post here. If there is a lot of demand we can reconsider.

[jorti]

Please, enable this option in the kernel so the people who wants it, can use it. You can disable it completely with selinux=0 in the kernel cmdline.

I think it's a must for Rpi servers.

[stefano-pogliani]

Hello,

I am setting up an https://owncloud.org/ server on a raspberrypi and I would like to make it available over the public internet.
Without SELinux enabled this is clearly not an option and as @jorti points out it is a must for an Rpi server.
Could you please reconsider giving us the ability to enable SELinux?

Kind regards,
Stefano

[karafior]

With the release of the Pi 2 and the availability of ARMv7 (hfp 32bit) as a primary architecture for the Fedora Project, I would like to propose a reconsideration of enabling SELinux support in the Kernel.

SELinux is an important part of a Fedora system, allowing it to use Docker containers safely, which is a whole new world for the Pi.

This in combination with a AltArch Special Interest Ggroup for CentOS 7 on ARMv7hl and Red Hat's plans to create an ARM variant of it's Enterprise Linux is a strong evidence that there is indeed demand for SELinux in Raspberry's kernel.

The CentOS on ARM SIG wiki explicitly mentions that the last thing not working on the Raspberry Pi 2 is the lack of SELinux in the kernel.

[popcornmix]

There is no reason why other distributions shouldn't use different kernel options. Arch Linux for example produce their own kernel build.
Raspbian is not going to enable SELinux.
If Fedora or CentOS or any other distribution chooses to enable it, then nothing is stopping them.

[igor-stoppa]

In my case I am going to use the PI 3 as home gateway/router. I think it would be time to reconsider enabling SE Linux. I doubt the performance difference is noticeable. Furthermore, it might be time to provide more than one option for the kernel, where an IoT-specific configuration would be available, with less performance and more security focus.

[ghost]

Its Important, SELinux needs to provided in Raspberry Pi 3b+, its very important Application layer protection in the event any intrusion bypassed the personal firewall of server. Even i use raspberry pi3 b+ as server, please enable SELinux features in the Raspberry pi 3b+ running the Raspbian OS

[pelwell]

If SELinux is important to you then you'll need to find another kernel build that enables it (or build your own - it's not difficult: https://www.raspberrypi.org/documentation/linux/kernel/building.md) - the overheads are too great for such a niche feature to be enabled in official RPi builds.

[awillis]

Since the RPi5 is out, I think this should be revisited. I notice that the original objection in 2015 relied on an LKML post from 2004 without considering the followup. SELinux does not need to be enabled in official RPi builds, support for it can be included and it can ship in a disabled state, in which case it has no performance impact. Debian includes tooling to enable it when using grub, as well as all necessary userspace packaging. The only ask for RPiOS is to ensure support is built into the kernel as it is for Debian (and Ubuntu) and to ensure that the enablement is honored by the bootloader.

[JamesH65]

So what are the performance and kernel size hits when enabling it nowadays?

[awillis]

Although not a recent test, a quick Google search led me to https://www.phoronix.com/review/fedora-31-selinux

I'd like to reiterate that the ask is not to enable SELinux, even in permissive mode, but rather to ensure support is included in the kernel and bootloader to allow interested users to enable it. As of the latest RPi OS this does not seem to be the case. If support is included in the kernel it can be left disabled, in which case it is like any other unused driver or capability. Only when enabled either in permissive or enforcing modes is there a measurable performance impact.

I should add that SELinux has been shipped enabled and in enforcing mode by default in RHEL and Fedora for many years now. That means paying customers on much larger and more expensive hardware are actively using SELinux in scenarios where every bit of performance is money.

On smaller devices such as the RPi where education or hobbyist interests are the primary driver of the platform, I would hope that concerns over microbenchmarks would be outweighed by the mission of the product and the requests of the community.

[pelwell]

That means paying customers on much larger and more expensive hardware are actively using SELinux in scenarios where every bit of performance is money.

That's an over-simplification - if performance was the only objective, all of the security features would be disabled because they only slow things down. As with most things in life, it's a trade-off, and the best compromise is going to be application specific. We have to decide where the sweet spot lies for our kernel builds based on the needs of the majority of our users. On systems with limited RAM, kernel size is more of a factor than on an 8GB Pi 5.

This is not to say that it isn't worth revisiting the status of SELinux in our kernels, but remember that right-for-you does not mean right-for-everyone.

[awillis]

I did not say that performance is the only objective for RedHat and Fedora customers. It most obviously is not. I think that my statement holds up well in context.

In this thread I focus on performance because the objection that shut down this thread for years was focused on out of date performance data. I'm happy to see another concern raised with regard to kernel size, it tells me that we are making progress. Would you be willing to compare compiled kernel sizes with and without SELinux support included?

I am also glad to see that we are aligned in our consideration for the needs of a broad audience. Like you, I also have extensive practice in weighing the needs of a global audience across a variety of use cases. It also sometimes requires advocacy for folks that have not received timely attention, as is the case in this thread.

Are there other concerns your team would have aside from performance and kernel sizes on smaller devices? It would be good to list them here to raise awareness.

[pelwell]

I'm happy to see another concern raised with regard to kernel size, it tells me that we are making progress.

Not really - it's always a consideration, as can be seen on many similar requests.

Would you be willing to compare compiled kernel sizes with and without SELinux support included?

That's how these things work - present some evidence, and we'll make a decision.

[timg236]

Moved issue to Linux.

Right now, I think this is something that's unlikely to be re-opened unless it's virtually zero cost. The default kernel binaries are targetted for desktop-class OS's with board hardware support. So long as the downstream patches don't prevent an SELinux configuration from being built that seems reasonable.
N.B AppArmor can be installed without rebuilding the kernel and seems to be a better fit for the majority of installs where security enhancements are desired.

[awillis]

I've shifted to using dietpi for my project, as it's a better fit for other reasons. I think it is relatively safe to say that people who request the use of SELinux are interested in using it, and are probably well aware of AppArmor. SELinux has long been enabled and enforcing by default in other desktop focused distributions like Fedora, and can be enabled in Ubuntu and Debian. The intentional omission of SELinux support keeps RPiOS behind other desktop and debian based distributions.

Kernel size impact could be easily obtained by compiling the kernel with the necessary support, it is only a matter of being willing to take the time do to so. If I get some spare time, I will compile the RPi kernel for the RPi devs and have a look. It's no longer a blocker for me though.

[awillis]