SELinux is one of the most powerful security features in your Fedora system. It’s like a valet key for your computer services, only allowing them to access approved data. SELinux has outgrown its early-days reputation for difficulty. Now it has tunable policy for most popular applications, and provides extra security and confidence. However, sometimes errors do occur, and this article will help you deal with them.

Assumptions

This article assumes two things:

1. You know the basics of SELinux. If you haven’t learned basics of SELinux, now is a great time to do that. One of the best primers is this video by Thomas Cameron. Take the time to watch and understand it.
2. You’re using SELinux in enforcing mode. The enforcing mode is the normal and expected way to run Fedora. If you’ve disabled SELinux, you’ll need to enable it. Edit the /etc/sysconfig/selinux file to set SELINUX=permissive. Using permissive mode first ensures that any radical problems can still be fixed automatically by the following commands. Then do the following:

   sudo fixfiles -F onboot
   reboot

   The boot process may take longer than usual, since SELinux relabels any files created while it was disabled. This can take a while on very large file systems, so be patient.

Don’t be surprised if you start seeing errors after relabeling, if you’ve been running in disabled mode for a while. Running in disabled mode is like wallpapering over a leak. When you remove the wallpaper, you’re likely to find water damage. In the same way, if you’ve been running without SELinux enabled, you’ve probably created more problems that now need to be solved.

Once the machine has rebooted, you can switch to enforcing mode:

sudo setenforce 1

Is it really SELinux?

A good way to tell whether SELinux is at fault for an error is to set permissive mode. This means SELinux logs the error, but still allows the activity. To do this, run this command:

sudo setenforce 0

Then try the process again, in another terminal if needed. If it now succeeds, SELinux policy is fault. To find errors within the last 10 minutes, use the ausearch command:

sudo ausearch -m AVC,USER_AVC,SELINUX_ERR -ts recent

If the process still fails while in permissive mode, the problem is likely not the SELinux policy. In that case, make sure to run sudo setenforce 1 to return to enforcing mode. Remember this setting is global, so you don’t want to leave off policy enforcement everywhere!

Identify the problem

You can generally identify SELinux errors through the AVC message. One of the parameters of the AVC message is the command that generated the message. For example, you might see comm=”/usr/sbin/httpd” in a message about an SELinux error generated by the Apache web server.

The problem will also tell you the source context (scontext) of the acting part of your system, and the target context (tcontext) of the thing it tried to act on. Often, but not always, the source is a binary and the target a file. To understand the error better, you can use the SELinux Troubleshooter. You can install this from the Software tool in Fedora Workstation, or use sudo with dnf in a terminal:

sudo dnf install setroubleshoot

To start the program, use the Overview in Fedora Workstation to locate the SELinux Troubleshooter, or run from a terminal:

sealert

You can find recent alerts in the browser that appears:

At this screen, for example, you can list all the alerts present on your system to troubleshoot them systematically.

Fixing the problem

When you select Troubleshoot you’ll see several options for your error.

In this case, the user created an index.html file in their home directory, and used the mv command to put it in /var/www/html/ to be served by the Apache web server. After pointing a web browser at http://localhost/index.html, this error occurred.

Notice how each choice gives you a specific set of commands you can run to fix the problem. In this case, there is a boolean switch you can enable to allow the activity in the future, even while SELinux is enforcing policy.

However, just because a boolean exists doesn’t mean you should enable it without understanding it. In this case, if you turn on the boolean, the Apache web server will be able to read any user content whose file permissions allow it. So in this case, we might instead want to ask, “Why does the file have that context?” In this case it’s because the user moved the file. That means the file carried its old context into its new location, rather than receiving a new default context that allows the web server to read content in /var/www/html.

In this case, the best idea is to simply restore the file’s correct context:

sudo restorecon -rv /var/www/html/index.html
Relabeled /var/www/html/index.html from unconfined_u:object_r:user_home_t:s0 to unconfined_u:object_r:httpd_sys_content_t:s0

A note about SELinux booleans

There are many booleans available. Each one allows you to set a broad class of access that may be expected for an application to function. To see the whole list and their current settings, run this command:

semanage boolean -l

If you install the selinux-policy-devel package first, you can also see a short description for each boolean when you run the command above:

SELinux boolean State Default Description

abrt_anon_write (off , off) Allow ABRT to modify public files used for public file transfer services.
abrt_handle_event (off , off) Determine whether ABRT can run in the abrt_handle_event_t domain to handle ABRT event scripts.
abrt_upload_watch_anon_write (on , on) Determine whether abrt-handle-upload can modify public files used for public file transfer services in /var/spool/abrt-upload/.
antivirus_can_scan_system (off , off) Allow antivirus programs to read non security files on a system
...

To set a boolean temporarily, run this command, where boolname is the name of the boolean and value is either on or 1, or off or 0.

setsebool boolname=value

To set it permanently, add the -P switch:

setsebool -P boolname=value

Conclusion

There are other functions you can perform with the SELinux Troubleshooter, such as creating a specific policy module for your own system. You might find this SELinux guide helpful for understanding those functions.

Photo by Cristina Gottardi on Unsplash

The Fedora 27 Beta is getting close to release, and the Fedora Atomic Working Group and Fedora Cloud SIG want to get the community together next week to find and squash bugs. We are organizing a test day for Friday, September 29th.

During the Test Day, participants can test both Atomic Host content and Fedora Cloud Base content. Vagrant Boxes will be available to test with as well. See the wiki page for links to artifacts for Atomic Host and Cloud Base Images. We have qcow2, AMIs, and ISO images ready for testing.

How do test days work?

A test day is an event where anyone can help make sure that changes in Fedora work well in the upcoming release. Fedora community members often participate, but the public is welcome also. You only need to be able to download materials (including some large files), and read and follow technical directions step by step, to contribute.

The wiki page for the Atomic/Cloud test day has a lot of good information on what and how to test. After you’ve done some testing, you can log your results in the test day web application. If you’re available on or around the day of the event, please do some testing and report your results.

Happy testing, and we hope to see you on test day.

Since Boltron is out and the team is working hard on Fedora 27 modular server, we could start talking more about what it all means. One of the aspects our team is interested in is utilizing modules in container images. If the world of Modularity is still new to you, don’t worry, we have you covered! I advise you to read the Boltron announcement and dive deep into Fedora Modularity website. As for containers, they keep being great at packaging applications with its dependencies and basic runtime environment in a single “box” which is easy to operate.

You might be wondering why anyone would include modules inside container images. There are some very practical reasons that make modules a good fit for containers.

1. You know what you are getting.

With traditional distribution, it’s hard to predict the version of software being installed. Let’s do an example. Do you know what version of nodejs you’ll get when you install it inside registry.fedoraproject.org/fedora:26 container image?

$ dnf install nodejs

It may be version 6, it may be version 8, who knows? You could check koji, bodhi or dist-git to find out, but none of those would give you the answer. Only running the command would tell.

So how will modules help here? Let’s proceed to the next point.

2. You can pick the version you want.

Modules have a concept of a stream. Streams are defined by packagers where they clearly state what the compatibility status of the stream is. Some may be strict which will require all updates within the stream to be API and ABI compatible, others may just provide latest upstream version with no guarantees. The strict streams are usually tied to upstream major releases. When installing a module, you can select a stream to be installed. In the example below, I chose stream 8 for nodejs, which is tied to upstream version 8.

$ dnf install @nodejs:8
======================================================
Package     Arch            Version
======================================================
Installing group packages:
nodejs      x86_64          1:8.0.0-1.module_42d8f2a0

Since the stream guarantees compatibility, updating nodejs package within that stream ensures that you will always be getting version 8.

This will also solve one of the problems we have when building container images in Fedora. There is a guideline that you should not set version label, because no one knows what version of the package is going to be installed. We concluded that it’s better to ignore the label rather than setting it wrong. With modules, we’ll select a precise stream and we’ll be sure to get a version we picked.

3. Compatibility under control.

Let’s get back to the first point.

What if your software stack works only with NodeJS 6 and the command dnf install nodejs would install version 8. That would be a problem, right?

With streams, you will be able to select one which guarantees that you will always get an API/ABI compatible packages within that stream. If you need stability, pick a stream with strict compatibility guarantees — no surprises when installing packages anymore. So predictable, such happiness!

4. A module may come optimized for the container use case.

Back in the day we defined an install profile named “container”. Install profile contains a set of packages which are meant to be installed. The “container” install profile should contain a list of RPM packages which are meant to be installed into containers.

So in dnf, all you need to do is just:

$ dnf install @nodejs:8/container

and you should be getting the right packages. No need to spend time figuring out what those should be. And obviously, you can always pick the ones you really need.

5. The installation is simple and your muscle memory works.

Modules don’t need a new package manager. You can easily install them using dnf. Optionally, if you want better experience, you can use the functionality supporting modularity which was added into dnf.

6. In the end, you are getting ordinary RPMs.

Modularity is not a new packaging technology. When you’re installing modules, in reality, you are getting RPMs. So, don’t fear that you need to learn a new packaging format.

7. Automation!

This is my favorite one. Once the Factory 2 team reaches their goals, we’ll have a complete build pipeline in-place. This means that to build an updated container-image, all you need to do, is to update an RPM spec file, commit the changes and push them into Fedora dist-git. You heard me.

The pipeline should then trigger the build of the RPM, which should trigger a build of the associated modules, which should trigger a build of container images which utilize the modules. On top of it, every step will be gated by CI.

We’re not quite there yet, but we’re right on track.

With this kind of automation, rebuilding container images for sake of fixing CVEs should be much easier. Benefit for users is to get updated container images within hours.

8. Rebuilds that work.

Imagine this: there is a new CVE with a fancy name. Fedora rebuilds all container images to pick up the fix from a base image based on the automation work described in previous point. And boom! A bunch packages were updated which turned into breaking functionality of the particular containers. That’s not we wanted, right?

This scenario should not happen with modules. As I explained when talking about streams, when you select a stream with strict compatibility guarantees, you should be getting functional, compatible packages forever.

9. The simplicity.

If you ever played with Software Collections, or even tried to create a container image based on an existing collection, you might got to a point when it was too complicated:

• RPMs installed into a separate tree in /opt
• the need to scl enable a collection
• and for sure, a bunch of hacks

Our goal is to make those pain points history. Why? Modules are installed directly in your root filesystem, you don’t need dedicated tooling to use the modules and… no hacks!

Oh, but your requirement is to have three database versions installed in parallel — no problem. Just get a container image for every version and you are good to go. Modularity doesn’t provide a solution for parallel installation, it provides multiple versions for a single package.

Are you so hyped for modules as I am?

The recent Flock conference of Fedora contributors included a Fedora Magazine workshop. Current editorial board members Ryan Lerch, Justin W. Flory, and Paul W. Frields covered how to join and get started as an author. Here are some highlights of the workshop and discussion that took place.

Writing process

The process of writing an article for Fedora magazine is simple and involves only a few steps.

1. The writer pitches an idea which summarizes the topic and its objectives.
2. Once the pitch is approved, the writer creates a draft.
3. The editors work with the author to get the article finished and scheduled for publishing.

The Fedora Magazine’s editorial board meeting happens every Tuesday, where approvals and scheduling happen. If you follow the process, you can usually expect your article to be published within a week or two, depending on the queue and time critical articles.

The full process of writing an article is covered here on the Magazine itself.

Tips for better articles

The Magazine provides articles about and outreach for Fedora. As a result, articles focus mainly on Fedora users, rather than just contributors. However, the Community Blog provides a focus on contributors, and might be the right place for some news. Ask yourself a few questions as you think about your pitch or article:

• Who’s your target audience? What kind of readers are you talking to?
• What do you want them to know or achieve by reading the article?

Also, articles don’t have to be big and complex. If you think your article is going beyond 500-600 words, you may want to break it up into two or more shorter, simpler articles. The Magazine also hosts series of articles, as long as authors are willing to write several entries before publishing the first.

The Magazine features a dedicated page full of tips and advice on writing better articles: Tips for article style, grammar, content, and SEO

Get your red hot pitches

During the workshop, some fantastic pitch ideas were discussed.

• Kernel bench-marking in Fedora
• Add-ons to improve your privacy on Thunderbird
• How to use Thunderbird mail filters
• Installing Mycroft.ai
• How to use Webex on Fedora
• Awesome GNOME extensions for developers
• Installing Hawkular on Fedora
• How to create a stratum 0 time source

The editorial board has already pre-approved each of the above pitch ideas. One of them might be a good start for your article for the Magazine. To claim a pitch, just follow the process described above and claim an idea.

Join the team

The Magazine’s reach and readership grows steadily every release. You too can be part of this team — it’s easy to get started and fun to work on. Your contributions directly impact the growth of the Magazine. Why not join today?

Photo by Aaron Burden on Unsplash