What's New in Fedora Core 3 SE Linux
Security Enhanced Linux (SE Linux) now is the default configuration for an installation of Fedora Core 3 (FC3). When you install FC3, you have the option of turning off SE Linux. Alternatively, you can turn it off manually after it has been installed. In FC2, SE Linux was not installed by default but was an option offered during the installation process, where you had to supply selinux as a parameter to the boot loader.
The default SE Linux policy in FC3 is the targeted policy. Two types of policies are offered--targeted and strict. Targeted policy is new in FC3. Under the targeted policy, only some of the more commonly used daemons run with SE Linux restricting what they can do. These daemons include named, httpd, dhcpd, portmap, squid, nscd, syslogd, snmpd and ntpd. These daemons run in their own domains; httpd, for instance, runs in the httpd_t domain.
Daemons and system processes that do not have a policy installed run in the unconfined_t domain. Processes running in the unconfined_t domain have the standard Linux DACs (discretionary access controls) applied. SE Linux MACs (mandatory access controls) are applied, in that processes running in unconfined_t have a policy that says allow everything.
To see which domains are targeted, examine your /etc/selinux/targeted/src/domains/program/ directory. To see which programs are running unconfined, run ps axZ to see what is running in the unconfined_t domain.
Strict policy applies the SE Linux MAC controls to all processes. The unconfined_t domain is not used by default in the strict policy, as there is a domain for each daemon and restricted domains for user logins. No restrictions exist for user login domains under the targeted policy. The strict policy is not installed by default, as it is more difficult to administer. Strict policy is more secure than targeted because of the SE Linux MAC controls being applied to all processes, apart from a small number of important system processes--init scripts, insmod, hotplug, firstboot, RPM and anaconda. This is opposed to only being applied to a small selection of important daemons under the targeted policy. One can see that a tradeoff exists here between usability and security. If you were to run strict policy, you would be more likely to edit policy manually, because the controls are tighter. Chances are, an operation you want to do would not be allowed, and you therefore would be required to make local customizations.
You can switch from targeted to strict policy and vice versa, but you first should test this on a non-production system. If you were to change from targeted to strict policy on a production system, you probably would find that some things you want to do are not allowed, requiring manual modifications to system policy. If you are not confident with troubleshooting and solving SE Linux policy-related issues, it is advised that you run the targeted policy. Switching from strict to targeted policy should not result in any major glitches.
The process of changing from one policy type to another is quite simple, and command-line instructions can be found in the Fedora Core 3 test3 SELinux FAQ (see Resources). Another way to change to the other policy type is to run the system-config-securitylevel program. It currently is available only in graphics mode, not text mode. At the time of this writing, there is a bug in FC3 pre-release: the /.autorelabel file is not created by the system-config-securitylevel script, so you have to create it by hand. This bug will be fixed for the FC3 release. The existence of this file causes all filesystems to be relabeled on boot. The /etc/rc.sysinit script removes this file upon boot.
In FC2, the SE Linux directory was /etc/security/selinux; in FC3, it has been changed to /etc/selinux, with subdirectories of strict and targeted. Under the strict and targeted directories you can find the necessary files for the strict and targeted policies. The strict and targeted directories also contain a file called booleans. This file contains settings for default values for items that may be changed, such as httpd_enable_cgi, a value that allows CGI scripts to be run.
The /etc/selinux/config file also is a new addition in FC3. It contains the SELINUX variable, which can be set to enforcing, permissive or disabled. The config file also contains the SELINUXTYPE variable, which can be set to targeted or strict. The config.v file is the version control file for the config file. You can edit the config file by hand but it isn't recommended. Instead, you should use the system-config-securitylevel program. The config file is read at boot time, so making a runtime change to it doesn't alter the current running of your system. If you change the value of the SELINUXTYPE variable between strict and targeted, you must reload the new policy and relabel all filesystems. Creating the .autorelabel flag file is the only recommended way of doing this, followed by a reboot.
A more detailed discussion of the /etc/selinux/ directory is beyond the scope of this article, but it will be covered in a future article.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Interview with Patrick Volkerding
- Tips for Optimizing Linux Memory Usage
- What's GNU
- Secure Logging Over a Network
- Apache 2.0: The Internals of the New, Improved
- User-Mode Linux
- Getting Started with mod_security
- Using C for CGI Programming
- FSlint: annoyingly vague, but useful
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide