SELinux is short for Security-Enhanced Linux, and is a security module built into the Linux kernel which provides Mandatory Access Control (MAC). It was originally developed by the National Security Agency to harden Linux for use in secure environments, and acts as a highly granular, "default deny" security shield. Even if a process or root-level is compromised, it strictly limits what resources such as files/directories, network ports and such can be accessed, and what actions may be taken, down to even individual syscalls (the functions programs use to enter the kernel) into the kernel on individual files. It goes well beyond the old-style read/write/execute by owner/group/world permissions to pinpoint accuracy in protecting your system. I like to think of it as something similar to a firewall, but between processes (and resources) instead of networks.

Good resources include:

Regarding SELinux, I feel that any system engineer/developer/administrator should become familiar with it (or its alternatives, if using a different distro or OS) and use it. Indeed, I would go so far as to say that where possible, it is negligent to run a system without having SELinux or its equivalent running in what SELinux calls "enforcing" mode. And I say this of home development machines as well, since without having it enabled during development, how is the developer to test and develop the modules necessary to control the access of any software. And for any machine even indirectly exposed to the Internet, either on an incoming or outgoing traffic basis, this necessity goes up by several orders of magnitude.

This may seem a bit arrogant of me, but I come from a background where I was held directly responsible for doing my part to insure the security of systems for which I was responsible for the OS at both CompuServe and Bell Labs Messaging, among other places, where it could show up in my annual performance reviews. Just ask Google or your favorite search engine "what is the term for when you do not use all the tools to protect against a security failure and you suffer a breach" to see why I don't agree with it being arrogant, but instead feel it is so important.

Slug
selinux

A review of Tuleap so far (Tuleap, part 2 of ?)

In my previous article, I talked about why I am interested in Tuleap. But in this one, I am going to talk about my impressions of the software, in trying to set it up and get it running. And while not quite an article warranting a Core Dump category tag, I did realize that I needed a new one, as I have done a number of similar posts.

Dang it Red Hat!!!

If you have looked around this site, or know me and have heard me discuss it, I have an honest to goodness Red Hat Enterprise Linux subscription. I am not talking about the rebuilt version called Rocky Linux, which is the successor to CentOS after Red Hat changed that distro from being just a rebuilt/relabeled version of the corresponding RHEL version to a stream version sitting somewhere behind Fedora and before RHEL. 

New Video: Repeatable, automated installs using ansible and cobbler – Part 2

A brief update on the ongoing process of getting a new, up-to-date cobbler server running with the associated DNS and DHCP services. We discuss some of the issues encountered so far, including briefly discussing SELinux issues, and touch upon next steps which will hopefully have us successfully complete the installation.

SELinux and Tuleap (part 1)

I have been looking at tuleap for a personal Agile tool, to help me track tasks as I work on personal coding projects. For example, I might be working on a new version of a disk partitioning script to use with my kickstart installs, and come up with ideas I don't want to forget. So, to keep track of it, I have been creating tasks in Eclipse Mylyn using the stand-alone task list. But that list can be less than optimal, and it does not integrate with things like Jenkins, etc.