Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Red Hat Boosts SELinux With RHEL 5

kdawson posted more than 7 years ago | from the reducing-false-alarms dept.

Security 175

E. Stride writes "Many IT managers find Security Enhanced Linux, or SELinux, to be wildly complex. The mandatory access controls originally developed by the NSA have developed a reputation for being too complicated to deal with, and many IT shops simply turn the feature off. However, Red Hat's Dan Walsh says it's the only way to ensure 100% protection in the data center."

cancel ×


Sorry! There are no comments related to the filter you selected.

lol (0)

Anonymous Coward | more than 7 years ago | (#19405669)

lol 100% safe

Re:lol (2, Funny)

timmarhy (659436) | more than 7 years ago | (#19405883)

i can sell you a 100% safe pc if you want - it has no hd and no psu.

Re:lol (0)

Anonymous Coward | more than 7 years ago | (#19406305)

Seen it. It is a nice stable system. Only time I've seen it crash is when I've dropped it. []

Linux is dieing (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#19405677)

BSD is alive!

100%? (4, Informative)

mkro (644055) | more than 7 years ago | (#19405693)

There will never be a 100% protection. A good GUI with a wizard, like with SUSE's AppArmor [] , will help a lot of people from falling between the "naah, it broke something on my webserver, turning it off" and "I'll dedicate the two next months of my life to learn SELinux" chairs.

Re:100%? (5, Informative)

weapon (783054) | more than 7 years ago | (#19405769)

I run fedora and on *many* message boards I see the first trouble shooting idea is to turn off SELinux. What most people forget is that you can set SELinux to be permissive, so it is still turned on, and it lets you know when applications would be doing something that would be prevented. I think changing to permissive mode SELinux is more useful than turning it off as it lets you know what applications are misbehaving. I think part of this problem is that previously there has been no easy way to look as SELinux messages and manage the policies.

The main disadvantage of AppArmor is that it relies on file paths, not the inodes. All you need to do is be able to create a hard link in the right directory to get around it.

Re:100%? (2, Informative)

ryanov (193048) | more than 7 years ago | (#19406143)

I agree. This REALLY bothers me from a Sysadmin chair. It's clear that that feature was placed there in order to help you secure your system -- turning it off ought to be grounds for a reprimand from above. You wouldn't leave telnet open to the world in this day and age, so why would you turn off SELinux on a system that used it? At the very least, assigning files to the same context that contains the privileges that you need is something that does not take months to configure, but makes many of the problems go away.

I run a ColdFusion server with SELinux enabled (permissive yet, but I'm getting there)... that is a bit of a challenge, but it protects me from questions later, like "why was that privilege escalation possible?"

Re:100%? (5, Informative)

Anonymous Coward | more than 7 years ago | (#19406485)

Permissive mode is only useful for policy development. The kernel does not enforce the security policy in permissive mode so it is no more secure than turning it off.

Enforcing mode = Security policy decisions are enforced, policy violations are logged.
Permissive mode = Security policy decisions are not enforced, policy violations are logged.
Disabled = Security policy decisions are not computed.

Re:100%? (2, Informative)

ryanov (193048) | more than 7 years ago | (#19407065)

His point was that at least you KNOW about violations, even if they aren't enforced. That's at least something.

Where it gets tricky is when permissive allows something to happen that triggers another violation, whereas enforcing would have stopped things earlier in the chain. Things can look a little inconsistent in that way.

Re:100%? (5, Informative)

CajunArson (465943) | more than 7 years ago | (#19405809)

100% agree that there is no such thing as 100% protection. I think both SELinux and AppArmor are great things (I did my MS thesis (woefully out of date) [] on Domain & Type enforcement which is one of the major systems (along with RBAC & Bell-Lepadula/Biba) in Mandatory Access Control (MAC). The SELinux approach is (usually) a more 'pure' variety in that it encompasses the entire system, all of the namespaces in the system in one setup. When I say 'namespace' think of that scene in the Matrix when Neo can't open his mouth to make a phone call..... Tell me Mr. HAcker, how are you going to steal my passwords when you can't even name the /etc/shadow file? SELinux will allow policies where even the root user (under certain contexts) cannot screw with the system. This can make administration harder like in some SELinux setups you literally have to login as root from the physical console to have full access, su'ing to root or SSHing in as root will not get the same privileges. In the most extreme cases, an SELinux policy could literally require you to reboot the box off of a rescue CD to get full access to certain files. The controls are extremely fine grained and very powerful, but potentially cumbersome.
      AppArmor's main approach is somewhat less broad. It is more like putting certain applications into a MAC container to limit what an application can do, no matter who the user using the application is. A great example of this that most Slashdot readers should look into is putting the browser into a safety container. I've been using Linux since right before 2.4 came out, and I can't count the number of times I've heard 'Linux is more secure because even if your account gets hacked the system isn't hacked' While there is certainly truth to that from the perspective of the full system, it fails to mention that the only data I actually give a rat's ass about is the data in my account, I can always get the rest of the crap from CD/downloading! AppArmor can help fix this by saying: Hey Firefox, just because you are running as user CajunArson, you DON'T get to do everything CajunArson can do, we will only let you operate on some files, and you can't get full access to his data, you can't fork/exec any ol' program that CajunArson can, and in general you are limited to doing what you are supposed to do: Browse the Web. The underlying concepts are still based on the MAC used by SELinux, but the implementation, while not as air-tight theoretically, is also easier to adjust. If there is something I really need firefox to do that the profile will not allow, AppArmor makes the process of tweaking the security easier than SELinux in general (although RedHat could be working on better SELinux tools to fix that).
    Sorry for the long post, but remember: the next time someone says Linux is more secure than Windows, remember that things like SELinux and AppArmor really are what make it better, not just because it has a mean looking penguin!

AppArmor (3, Informative)

hweimer (709734) | more than 7 years ago | (#19407611)

AppArmor's main approach is somewhat less broad. It is more like putting certain applications into a MAC container to limit what an application can do, no matter who the user using the application is. A great example of this that most Slashdot readers should look into is putting the browser into a safety container.

Some time ago, I wrote a review of AppArmor [] , finding that it solves problems that don't exist. Looking at your browser example, the functionality provided by AppArmor can be implemented completely by setting up a different user and setting appropriate file ACLs.

For the real problems AppArmor provides little help. Can you confine network usage of a program, meaning your internal network cannot be accessed once your browser has been hacked? No. Can you limit the syscalls a program may use, reducing the risk of successful kernel exploits? No.

As long as it stays this way, I recommend to everyone to use SELinux, even though it is much more difficult to setup and configure.

Re:100%? (0)

Anonymous Coward | more than 7 years ago | (#19408273)

"Remember: the next time someone says Linux is more secure than Windows, remember that things like SELinux and AppArmor really are what make it better, not just because it has a mean looking penguin!" - by CajunArson (465943) on Tuesday June 05, @09:30PM (#19405809)

Agreed, 110%... & the "100% secure" the initial thread post here states that somebody from RedHat stated is possible? ISN'T, no way (what one person can lock, another WILL eventually, unlock - more OR less + new threat types emerge constantly).

Windows CAN be secured very well, but, you have to go thru some "GYRATIONS/EFFORT" to do it, but, it IS doable (but not to any 100% levels, because again - see what I stated last paragraph of mine above).

Here I am running Windows Server 2003 SP #2, fully current patched by MS update pages, here (I check it every 2nd Tuesday of the month of course, on "Patch Tuesday's"):

It is a personally 'security-hardened' model I have been working on for many years, using principals I learned & used since the NT 3.5x days onward to this version of the OS: As is now?

I score an 84.735 on the CIS Tool 1.x currently as of 06/01/2007!

(For CIS Tool - There are Linux, MacOS X, Solaris, & other OS models ports of this are available too by the way - not really "ports" strictly speaking, they require JAVA to run)

DOWNLOAD URL FOR CIS TOOL (for multiple platforms), from "The Center for Internet Security" here: []

(IMPORTANT: This tool IS invaluable in guiding you to a more secure OS, on any OS platform really!)


1.) Windows Server 2003's SCW was run over it FIRST (this only exists on Windows Server 2003, not on 2000/XP (you have to install this, it does NOT install by default) first to help security it (SCW = security configuration wizard, & it's pretty damn good believe-it-or-not, @ least, as as starting point))...

Directions for its installation are as follows:

Start the Add or Remove Programs Control Panel applet.

Click Add/Remove Windows Components.

On the Windows Components Wizard screen, select the "Security Configuration Wizard" check box, as the figure shows. Click Next.

The Windows Components Wizard builds a list of files to be copied and finishes installing SCW. Click Finish.


(Then, @ that point? I pull ANY Networking clients &/or Protocols in the Local Area Connection, other than Tcp/IP typically, on a stand-alone machine that is not dependent on Microsoft's File Sharing etc. on a LAN/WAN. I also disable that too!)

2.) Disable Microsoft "File & Print Sharing" as well as "Client for Microsoft Networks" in your LOCAL AREA CONNECTION (if you do not need them that is for say, running your home LAN)!

3.) Use IP security policies (modded AnalogX one, very good for starters, you can edit & add/remove from it as needed) - Download url link is here for that: []

(Search "AnalogX Public Server IPSec Configuration v1.00 (29k zip file)" on that page & follow the directions on the page!)

NOTE: This can be 'troublesome' though, for folks that run filesharing clients though. An alternative to this is using IP Ports Filtrations, in combination with a GOOD software firewall &/or NAT 'firewalling' (or true stateful inspection type) router. All of these work in combination w/ one another perfectly.

(HOWEVER - Should you choose to use it, and do filesharing programs? No problem really, because you can turn them on/off @ will using secpol.msc & the IP stack in Windows 2000/XP/Server 2003/VISTA is of "plug-N-play" design largely, & will allow it).

4.) USE General security policies in gpedit.msc/secpol.msc, these are VALUABLE tools (and will be needed & suggestions for it will be told to you by the CIS Tool noted above - great stuff!)]


Many services I do not need are either cut off OR secured in their logon entity to lower privilege entities (from default, near "ALL POWERFUL" SYSTEM, to lesser ones like NETWORK SERVICE or LOCAL SERVICE), see this URL where I did a lot of research for a prebuilt list for another forums, to see how/why this works: 990498ce97e81b9460ecf879bbdd1&t=16097 []

I went at ALL of the services in Windows Server 2003 (some will not be in XP for instance, & Windows 2000 has no NETWORK SERVICE or LOCAL SERVICE as far as I know, but not sure, you can always make a limited privelege user too for this on 2000 if needed)...

I did testing to see which services could be run/logged in as LOCAL SERVICE, or NETWORK SERVICE, rather than the default of LOCAL SYSTEM (which means Operating System entity level privileges - which CAN be "misused" by various spyware/malware/virus exploits).

LOCAL SERVICE startable list (vs. LocalSystem Logon Default):

Acronis Scheduler 2 Service
Alerter (needs Workstation Service Running)
COM+ System Application
Indexing Service
NVIDIA Display Driver Service
Office Source Engine
O&O Clever Cache
Remote Registry
Sandra Service
Sandra Data Service
Tcp/IP NetBIOS Helper
UserProfile Hive Cleanup Service
Volume Shadowing Service
Windows UserMode Drivers
Windows Image Acquisition
WinHTTP Proxy AutoDiscovery Service

NETWORK SERVICE startable list (vs. LocalSystem Logon Default):

ASP.NET State Service
Application Layer Gateway
Clipbook (needs Network DDE & Network DDE DSDM)
Microsoft Shadow Copy Provider
Executive Software Undelete
DNS Client
DHCP Client
Error Reporting
FileZilla Server
Machine Debug Manager
NetMeeting Remote Desktop Sharing Service
Network DDE
Network DDE DSDM
PDEngine (Raxco PerfectDisk)
Performance Logs & Alerts
Remote Desktop Help Session Manager Service
Remote Packet Capture Protocol v.0 (experimental MS service)
Resultant Set of Policies Provider
SAV Roam
Symantec LiveUpdate
Visual Studio 2005 Remote Debug

PLEASE NOTE: Each service uses a BLANK password when reassigning their logon entity (when you change it from the default of LOCAL SYSTEM Account), because they use SID's as far as I know, not standard passwords.

WHEN YOU TEST THIS, AFTER RESETTING THE LOGON USER ENTITY EACH SERVICE USES: Just run your system awhile, & if say, Norton Antivirus refuses to update, or run right? You KNOW you set it wrong... say, if one you test that I do NOT list won't run as LOCAL SERVICE? Try NETWORK SERVICE instead... if that fails? YOU ARE STUCK USING LOCAL SYSTEM!

If you cannot operate properly while changing the security logon entity context of a service (should NOT happen w/ 3rd party services, & this article shows you which ones can be altered safely)?

Boot to "Safe Mode", & reset that service's logon entity back to LOCAL SYSTEM again & accept it cannot do this security technique is all... it DOES happen!

If that fails? There are commands in the "Recovery Console" (installed from your Windows installation CD as a bootup option while in Windows using this commandline -> D:\i386\winnt32.exe /cmdcons, where D is your CD-Rom driveletter (substitute in your dvd/cd driveletter for D of course)) of:

ListSvc (shows services & drivers states of stopped or started)

Enable (starts up a service &/or driver)

Disable (stops a server &/or driver)

Which can turn them back on if/when needed

(ON Virtual Disk Service being removed, specifically: This was done solely because, although it will run as LOCAL SERVICE, diskmgmt.msc will not be able to work! Even though the Logical Disk Manager service does not list VirtualDisk as a dependency, this occurs, so VirtualDisk service was pulled from BOTH the LOCAL SERVICE and NETWORK SERVICE lists here... apk)


STEP #1: CONFIGURE A CUSTOM Microsoft Management Console for this!

Configuring yourself a "CUSTOM MMC.EXE (Microsoft Mgt. Console)" setup for security policy templates, here is how (these are NOT default Computer Mgt. tools, so you have to do this yourself, or run them by themselves, but this makes working w/ them convenient):

The next part's per BelArcGuy of BELARC ADVISOR's advice (pun intended): 551 []

"Security Configuration and Analysis" is an MMC snap-in. To access the MMC, type in mmc to the Windows Run.. command to pop up the console. Then use it's File|Add/Remove Snap-in... command and click the Add button on the resulting dialog. Choose both "Security Configuration and Analysis" and "Security Templates", close that dialog, and OK. You'll end up with a management console that has both of those snap-ins enabled. The whole MMC mechanism is a bit weird, but does work"

(It's easy, & it works, & is necessary for the actual steps to do this, below)

Next, is the actual "meat" of what we need to do, per Microsoft, to set ACLs!

STEP #2: HOW TO: Define Security Templates By Using the Security Templates Snap-In in Windows Server 2003 []

Create and Define a New Security Template

(To define a new security template, follow these steps)

1. In the console tree, expand Security Templates
2. Right-click %SystemRoot%\Security\Templates, and then click New Template
3. In the Template name box, type a name for the new template.

(If you want, you can type a description in the Description box, and then click OK)

The new security template appears in the list of security templates. Note that the security settings for this template are not yet defined. When you expand the new security template in the console tree, expand each component of the template, and then double-click each security setting that is contained in that component, a status of Not Defined appears in the Computer Setting column.

1. To define a System Services policy, follow these steps:
a. Expand System Services
b. In the right pane, double-click the service that you want to configure
c. Specify the options that you want, and then click OK.

(And, of course, the user feedback on its effectiveness (Makes your Win32 NT-based OS very much like how MacOS X treats its daemon processes via privelege levels), which uses the same general principals)

It works, & although many service packs for Windows OS' have changed their services (not all but many nowadays) to less than SYSTEM, my list covers those they may not have in recent service packs AND 3rd party services are listed too that you may be running possibly!


6.) Another thing I do for securing a Windows NT-based OS: IP Port Filtrations (like ip security policies (per AnalogX above), it is often called the "poor man's firewall" & works perfectly with both IPSecurity policies, hardware AND software firewalls, all in combination/simultaneously running)!


Start Menu -> Connect To Item (on the right hand side) -> Local Area Connection (whatever you called it, this is the default, iirc) open it via double click OR, right-click popup menu PROPERTIES item -> Properties button on left-hand side bottom, press/click it -> NEXT SCREEN (Local Area Connection PROPERTIES) -> "This connection uses the followng items" (go down the list, to Tcp/IP & select it & /click the PROPERTIES button there) -> Press/Click the Advanced Button @ the bottom Right-Hand Side (shows Advanced Tcp/IP Settings screen) -> OPTIONS tab, use it & Tcp IP Filtering is in the list, highlite/select it -> Beneath the Optional Settings, press/click the PROPERTIES button on the lower right-hand side -> Check the "Enable Tcp/IP Filtering (on all adapters)" selection -> In the far right, IP PROTOCOLS section, add ports 6 (tcp) & 17 (udp) -> In the far left "tcp ports" list - check off the radio button above the list titled "PERMIT ONLY", & then add ports you want to have open (all others will be filtered out, & for example, I leave port 80,8080, & 443 here open, only - you may need more if you run mail servers, & what-have-you (this varies by application)) -> I leave the UDP section "PERMIT ALL" because of ephemeral/short-lived ports usage that Windows does (I have never successfully filtered this properly but it doesn't matter as much imo, because udp does not do 'callback' as tcp does, & that is why tcp can be DDOS'd/DOS'd imo - it only sends out info., but never demands verification of delivery (faster, but less reliable)) -> DONE!

You may need a reboot & it will signal if it needs it or not (probably will, even in VISTA):

I say this, because although IP Security Policies work with the "Plug-N-Play" design of modern Windows NT-based OS' (ipsec.sys) & do NOT require a reboot to activate/deactivate them in Windows 2000/XP/Server 2003/VISTA? This is working @ a diff. level & diff. driver iirc (tcpip.sys) & level of the telecommunications stacks in this OS family & WILL require a reboot to take effect (for a more detailed read of this, see here): /cableguy/cg0605.mspx []

(Enjoy the read, it is VERY informative - That article shows you how TcpIP.sys, ipnat.sys, ipsec.sys, & ipfiltdrv.sys interact, PLUS how you can use them to your advantage in security!)

7.) PLUS, this version of the OS in Server 2003 has a hardened IE6/7 by default (which can be duplicated on other Win32 OS versions, because it mainly just does what I have been doing for a long time & noted by myself earlier, in stuff like turning off ActiveX & scripting + JAVA online on the public internet, of all types by default, & I do this in ALL of my browsers (IE, FF, & Opera) & only make exceptions for CERTAIN sites)

8.) Running the "std. stuff", like AntiVirus (NOD32 latest 2.7x) + SpyBot as my resident antispyware tool running in the background!

9.) Plus good email client practices like using .txt mail only, no RTF or HTML mail, not opening or allowing attachments unless I know the person (still gets email scanned though)

10.) I also use a LinkSys/CISCO BEFSX41 "NAT" true firewalling CISCO technology-based router (with cookie & scripting filtering built-in @ the hardware level), these are excellent investments for security.

11.) USE Tons of security & speed oriented registry hacks (reconfiging the OS basically - stuff like you might do in etc in UNIX/LINUX I suppose)

Many can be found here, in an article I authored (and it tells what they do, & how they work, w/ descriptions from Microsoft themselves): []

It outlines it all, as to what you can ".reg file hack" for better SPEED, and SEcURITY online, in a modern Windows 2000/XP/Server 2003 OS & has references from Microsoft in it for each setting plus their definitions & parameters possible!

12.) The use of a CUSTOM ADBANNER BLOCKING HOSTS FILE (my persona one houses, as of this date, 90,000 known adbanner servers, OR sites known to bear malicious code & exploits (per GOOGLE mostly, from

Custom HOSTS files work in combination with Opera adbanner blocks & the usage of .PAC filering files + cascading style sheets for this purpose.

(As well as speeding up access to sites I often access - doing this, acting as my own "DNS Server" more or less, is orders of magnitude faster than calling out to my ISP/BSP DNS servers, waiting out a roundtrip return URL-> IP Address resolution. It may take some maintenance for this @ times, especially if sites change HOSTING PROVIDERS, but this is a rarity & most sites TELL YOU when they do this as well, so you can make fast edits, as needed (and, on Windows NT-based OS since 2000/XP/Server 2003 & VISTA? A reboot is NOT required upon edits & commits of changes in the new largely near fully PnP IP stacks!)

13.) KEEP UP ON PATCHES FROM MICROSOFT, HERE (ordered by release date) and your antivirus/antispyware vendors: splayLang=en&nr=50&sortCriteria=date []

(download them manually & install them yourself, OR just let "Windows Automatic Updates" run)

& keep up on your AntiVirus updates (either automatically via their services, or manually) & the same with your AntiSpyware products &/or things like JAVA runtimes (which was updated yesterday (06/05/2007) to JRE6.1 by SUN Microsystems mind you)!

14.) It is also possible, for webbrowsers &/or email clients, to create a "VISTA LIKE" UAC/WIC type scenario, isolating them into their own spaces, here are 2 methods, how (not needed on VISTA though, afaik):

IE6/7 & FF + OPERA AS WELL (as noted by A/C slashdot poster in reply to my methods, both his & my own work well, & are listed here @ /. (slashdot)) on modern NT-based OS "how-to": 19310513 []

(ALL of that is done for ONLINE security... &, it works!)

Enjoy & IF you know of more to do? Please, have @ it, & let us all know what it is you do on your Win32 rigs of NT-based OS nature!


P.S.=> LINUX folks too, post what you do, that may be "analogs" of what I have listed above... thanks, this is for everyone's gain on ALL/ANY OS types out there! apk

Re:100%? (4, Informative)

Niten (201835) | more than 7 years ago | (#19405837)

Good GUIs are a wonderful thing, but I want to emphasize that SELinux isn't really all that difficult to begin with. High quality SELinux rules shipped with solid distributions such as RHEL 5 eliminate many of the problems that early adopters faced; indeed, that's more or less the subject of this article.

Many people (such as myself) consider SELinux much less of a "patch job" than AppArmor. For instance, with AppArmor security attributes are not stored with the filesystem inodes, but are specified according to path name. That might simplify AppArmor's implementation a bit, but consider what happens to the security policy when you have two different path names hard linked to the same inode...

Those of us who are partial to SELinux's implementation of mandatory access controls are thrilled to see the strides that Red Hat has made in their latest enterprise release.

Re:100%? (2, Insightful)

Anonymous Coward | more than 7 years ago | (#19406243)

"Good GUIs are a wonderful thing, but I want to emphasize that SELinux isn't really all that difficult to begin with."

Not difficult? I guess that's why *on a stock Fedora system* SELinux prevents my desktop computer from writing back the time to the hardware clock. Or why SELinux prevents UDEV from creating /dev/watchdog on my laptop.

If it isn't difficult how come the guys who cobble together the distro can't get it right?

I just turn it off and life is soooo much easier.

Re:100%? (2, Funny)

ryanov (193048) | more than 7 years ago | (#19406415)

Wouldn't that be a sign that it's time to get a better distro than to disable security features? :)

Re:100%? (1)

Architect_sasyr (938685) | more than 7 years ago | (#19406403)

Is there an indepth but easy to read guide on SELinux? I turn it off and rely on a few network based defenses for most of my stuff simply because I don't have two months to dedicate to it. But if there was something I could be flicking through while I post responses on slashdot, I'm sure that would be useful.

Re:100%? (2)

ryanov (193048) | more than 7 years ago | (#19407085)

Lots of them on the web. I posted my favorite someplace below that was put out by RedHat (easiest for me since it's the manual for the system I'm running anyway).

SELinux is a good thing (4, Insightful)

pembo13 (770295) | more than 7 years ago | (#19405705)

It can save a system from being compromised due to other services which are either weaker, or poorly configured. Taking some time to get SELinux working properly in ones production environment (if that system is important) is more than worth the time it takes to read up on it. Being a lazy sys admin rarely pays off in the long run.

Ulcers are a good thing (1)

Anonymous Coward | more than 7 years ago | (#19405801)

"Being a lazy sys admin rarely pays off in the long run."

Is it being a lazy sysadmin? Or just an overworked sysadmin?

Re:Ulcers are a good thing (1)

ryanov (193048) | more than 7 years ago | (#19406157)

One needs to put their foot down and do their job. That includes making the system as secure as reasonably possible. If that's the amount of time it takes, that's the amount of time it takes. I'd rather take the high ground than make excuses later on.

Re:SELinux is a good thing (4, Insightful)

garett_spencley (193892) | more than 7 years ago | (#19405891)

But it all really boils down to your needs.

For example, consider the typical LAMP server (linux + apache + mysql + php) that hosts a web application. What does it need to protect ? It needs to protect the database with all the user data, the publicly accessible html documents and php scripts and possibly the log files.

You may also argue that it needs to protect the overall system from compromises involving using the system as a zombie or irc server etc. but in that situation a well managed server could simply have the software reinstalled. If the admins are competent and have access to spare servers they could configure the replacement machine and do a swap without incurring any downtime at all.

In this situation SE Linux might just be total overkill. The extra paranoid could have the publicly accessible html docs + php scripts on a read-only partition. This is a production environment we're talking about so the need to upload new documents will only be when upgrading software versions. If the web application allows users to upload data then that will need to be handled separately. A cron job could change file permissions on newly updated documents so apache no longer has write access. The log files can be moved to a separate location once per day when they're rotated where apache (or any other services) don't have access to them. MySQL can run chrooted, only bind to and the database files can only have read/write access from the mysql user. Daily, or even hourly, backups of the database to read-only media can be implemented. This is on top of running an intrusion detection system, installing security updates asap, and doing all of your other post-install locking down before the network cable is even plugged in to the machine (setting up your ssh keys, firewalls, uninstalling unnecessary software - including compilers - and obviously unused daemons and anything else the paranoid admin does before the machine goes live etc.)

We're already talking about way more security than most LAMP based servers out there.

I agree that the setup could still benefit from SE Linux, particularly for the database since it's still the weakest link and one of the areas in the most need of protection. MySQL needs to read/write to the database on a regular basis and so you need to allow write access to the data files, trust your software, trust your mysql binaries (all binary files and static config files can be on read-only partitions) and nothing is preventing a root process from changing the file permissions or corrupting the data. However, for most people this setup would be more than adequate and SE Linux would be total overkill.

just how good is this? (2, Interesting)

rucs_hack (784150) | more than 7 years ago | (#19405711)

SElinux certainly sounds interesting. How relevant is it for the normal user?

Is it better for my personal linux box to have this or is Iptables enough?

Re:just how good is this? (4, Informative)

sammy baby (14909) | more than 7 years ago | (#19405761)

The short version: it's very good. But a huge pain in the ass.

The slightly longer version: IPtables is about network access, firewalls, et cetera. SELinux is about ensuring the integrity and access rights of software on your system. It's designed to prevent, say, one process on your machine from overwriting a file it should be able to. There's a pretty good explanation of exactly what it buys you here [] . (Warning: government site. They're watching youuuuuu!)

The problem with SELinux is that up until recently it has been a royal pain in the ass to configure. You'd go, "Sure, this sounds like a good idea", turn it on, and then curse it roundly when you tried updating MySQL from the version that ships with RHEL to the most recent supported release from MySQL. As a result, most folks just turned it off - they figured it wasn't worth the hassle.

RHEL 5 apparently includes tools (see the article) for figuring out what's wrong with your SELinux configuration. Definitely worth looking into. But if you're not concerned with validating application integrity on your home box... and let's face it, it's a home box... probably not worth it for you until it becomes dead simple.

accursed beer makes me typo (1)

sammy baby (14909) | more than 7 years ago | (#19405771)

Damn beer.

Obviously rather than "prevent one process on your machine from overwriting a file it should be able to," I meant "shouldn't". Feh.

Re:accursed beer makes me typo (1)

rucs_hack (784150) | more than 7 years ago | (#19406083)

Thanks for the info, sounds like its more then I need on my normal use machine.

Never damn beer, I believe it positively enhances the slashdot experience :-)

Re:just how good is this? (1)

ryanov (193048) | more than 7 years ago | (#19406173)

I'm not sure that it's at all worth it on a single-user system that is isolated from risky populations by firewalls, etc.

I don't use it on my personal laptop... actually, that makes me wonder -- I don't know, does Ubuntu even use it by default?

Re:just how good is this? (1)

fuego451 (958976) | more than 7 years ago | (#19406885)

does Ubuntu even use it by default?

I know that Debian Etch does and the user selects the level of protection during install. From then on I guess it does its own thing. There is no man page and I haven't gotten around to reading up on it so I have no clue as to what it is or is not doing. I would guess that Ubuntu uses SELinux in a similar fashion. See if /etc/selinux and /usr/share/selinux exist.

Re:just how good is this? (1)

ryanov (193048) | more than 7 years ago | (#19407109)

Looks like no... but:

$ aptitude search selinux
v   libselinux-dev                  -
i   libselinux1                     - SELinux shared libraries
p   libselinux1-dev                 - SELinux development headers
p   python-selinux                  - Python bindings to SELinux shared librarie
p   python-selinux-dbg              - Python bindings to SELinux shared librarie
v   python2.4-selinux               -
v   python2.5-selinux               -
p   selinux-basics                  - SELinux basic support
p   selinux-doc                     - documentation for Security-Enhanced Linux
v   selinux-policy                  -
p   selinux-policy-default          - Policy config files and management for NSA
p   selinux-policy-refpolicy-dev    - Headers from the SELinux reference policy
p   selinux-policy-refpolicy-doc    - Documentation for the SELinux reference po
p   selinux-policy-refpolicy-src    - Source of the SELinux reference policy for
p   selinux-policy-refpolicy-strict - Strict variant of the SELinux reference po
p   selinux-policy-refpolicy-target - Targeted variant of the SELinux reference
p   selinux-utils                   - SELinux utility programs a little is installed, and more could be.

Re:just how good is this? (4, Funny)

g1zmo (315166) | more than 7 years ago | (#19406301)

It's designed to prevent, say, one process on your machine from overwriting a file it should be able to.

Yeah, that pretty much sums up my experience too.

Re:just how good is this? (2)

bzipitidoo (647217) | more than 7 years ago | (#19406827)

I haven't tried SELinux recently. Basically, it adds a whole lot more permissions and group types and hierarchies to the 3x3 standard "rwx" for user, group, world. You get permissions like "append allowed but no other writes allowed", and "editors running under your account can write to your source code files, but no other apps running under your account can write to those files". Unfortunately, managing all those permissions isn't as easy as running some chmod type of utility. Another knock against such security enhancements is it slows everything down. Might take a 5% performance hit just to run SELinux.

I prefer the "air gap" and back ups. Do development on one PC, have another dedicated to database stuff, another for web services, etc. It's not like PCs and RAIDs are expensive. Could even do it with virtual PCs with something like VMWare. And you could probably manage several installations of an OS more easily and quickly than one installation of SELinux. Even with good tools, the sheer volume of permissions to manage makes SELinux unwieldy. With bad tools, you're probably opening up and watering down so much you might as well just turn it off.

At least SELinux isn't a joke that can be cracked in 2 seconds, with huge holes of the sort all too easily configured in a utility such as sudo. Think you're going to write a sudoers file to prevent people from running certain system utilities such as passwd or halt? Easily circumvented by copying passwd to some name that isn't forbidden. Going to stop such copying by "chmod a-rw" to all those utilities? What chmod can do, chmod can just as easily undo. And, that doesn't stop all sorts of other ways around such a feeble barrier. That's the sort of thing SELinux can stop. The question is whether some security from those sorts of problems is worth the pain of administering SELinux. For most situations, SELinux isn't worth the trouble. If I wanted to take a step towards a tiny bit more security, I would run my browser under a different uid, so that if it picked up something bad, it couldn't do something like, say, trash my home directory. Go through the hassle of having to move downloads between user accounts all the time, just to guard against a very unlikely threat? Nah.

How relevant? (1)

weighn (578357) | more than 7 years ago | (#19406133)

How relevant is it for the normal user?

I've looked over a few setup guides recently for MythTV on Fedora or Ubuntu (sorry but the urls are on my home machine). They nearly all say "turn SELinux off and save days of configuration pain".

I can't see the point of persisting with it if you have a SPI router and something like Firestarter.

Re:How relevant? (2, Informative)

init100 (915886) | more than 7 years ago | (#19408289)

I've looked over a few setup guides recently for MythTV on Fedora or Ubuntu (sorry but the urls are on my home machine). They nearly all say "turn SELinux off and save days of configuration pain".

I think those guides may be a bit outdated. SELinux were a royal PITA back in the days, but you almost never run into it on the newer Fedoras. Fedora 7 even has a little icon popping up in the notification area when SELinux denied some access request. For me it have just happened after suspend and hibernate, and then it was only two blocked file accesses.

I'm actually surprised how well Fedora 7 works. I installed it on my Dell Latitude D810 laptop yesterday, and both wireless network with WPA2, 3D desktop with Compiz on ATI Radeon Mobility X600, suspend and hibernate works fine out of the box. Never did before. And of course, running with SELinux enforcing and see almost no warnings.

AVC (server) = UAC (desktop) (1, Insightful)

OutOnARock (935713) | more than 7 years ago | (#19405731)

Seems an awful like the different implementations of the same idea.

Of course MS sucks and Linux rules because its /., but how is "training" AVC to know what is allowed to touch the kernel and what is not, any different from "training" UAC to know what is allowed to touch the kernel and what is not?

Let the flaming begin

Re:AVC (server) = UAC (desktop) (1)

compro01 (777531) | more than 7 years ago | (#19405797)

the idea is sound, but the implimentation is the thing.

windows with it's constant prompts to do stuff while performing the same task gets very annoying and will quickly train the user to just click the allow, rendering it practically pointless.

in my experiance, other implimentations of this will prompt once in a given task and also encourage the user to think a little more as they prompt for their password (yes, i know windows can do this, but it doesn't by default)

Re:AVC (server) = UAC (desktop) (3, Funny)

Volante3192 (953645) | more than 7 years ago | (#19406045)

Very off topic, but I was just thinking...

windows with it's constant prompts to do stuff while performing the same task gets very annoying and will quickly train the user to just click the allow, rendering it practically pointless.

Clearly, in order to make users think about this, a 5 second delay has to be introduced before the Allow/Deny buttons are active...

Vastly different... (1)

Ayanami Rei (621112) | more than 7 years ago | (#19406047)

UAC is all about getting the user's input on activities that the Administrator would normally do (but not necessarily want to do if it was done behind their back).

AVC is a way for an end-administrator to customize policy (or get hints on what files or network features to label for access by a service). Generally, the system administrator SHOULD NOT have to create policy unless the administrator is deploying a novel service. And its' not interactive; you don't use it during normal use, you use it during testing to refine your policy.

A similar approach with vastly different intents and use cases.

100% Secure (4, Interesting)

whterbt (211035) | more than 7 years ago | (#19405737)

Ignoring for now that nowhere in the article does he claim that SELinux provides or is required for "100% security", there's no such damn thing. Unless you pull out the power cord, of course.

Yes, we disable SELinux at our shop. As the article mentions, it's a pain in the ass, and the tools to manage it are not mature enough. If all you have is RHEL, and you have nothing else to do, you can look at configuring it. If you have a bunch of corporate mucky-mucks breathing down your neck, and you have to get the latest version of GnuWhatever compiled for 5 different OSs, there's no time to deal with this nonsense.

SELinux probably works just great for what it was designed for - NSA top-secret systems. There's always a tradeoff between security and usability, and right now, SELinux is just above yanking the power cord.

Re:100% Secure (1)

dbIII (701233) | more than 7 years ago | (#19406167)

SELinux probably works just great for what it was designed for - NSA top-secret systems. There's always a tradeoff between security and usability

If it's for a webserver/ftpserver/mailserver with ssh access it's pretty trivial to set up and use. If it's for something running a commercial *nix app that uses a dozen ports for weird undocumented stuff plus NFS disk access via amd it then becomes a pain.

Re:100% Secure (1)

ryanov (193048) | more than 7 years ago | (#19406253)

Walk into your boss and tell them that you've decided to trade security for time (if indeed you're talking about multiuser systems here). My boss would tell me "sorry, that's not your call."

SELinux is NOT one step above yanking the power cord -- how did this get moderated so high?

I know, I must be new here.

Re:100% Secure (1)

profplump (309017) | more than 7 years ago | (#19406747)

You're right, it's not always my call. But I've never, ever had the call go for security over time, no matter who makes it.

How the hell did you get a boss with a clue?

Re:100% Secure (1)

ryanov (193048) | more than 7 years ago | (#19406937)

You know, I didn't even really get a boss with a clue. The boss that was let go recently (for being a fly in the ointment of the new VP) was originally a UNIX tech who worked his way up. My current boss was a DBA at one point, but years and years ago. Thing is, though, she trusts her staff generally (and can tell when someone's bullshitting her). So there are probably cases where if no one said anything to her, she wouldn't know something was important... but she gets CERT advisories just like the rest of us, etc.

Re:100% Secure (1)

init100 (915886) | more than 7 years ago | (#19408313)

SELinux is NOT one step above yanking the power cord -- how did this get moderated so high?

Maybe because it was, back in the days. :)

In other words, maybe some people need to update their opinions a bit. They install new releases of their distributions, but turn off SELinux just like last time without even looking at the new SELinux configuration tools, etc.

SE Linux is rarely noticable and easy to fix (2, Informative)

r00t (33219) | more than 7 years ago | (#19406493)

I've never once hit an SE Linux problem when running the stuff shipped with Fedora Core 6 and Fedora 7.

Stuff can get painful if you go grabbing 3rd-party crap from proprietary developers without neither a clue nor a care.

Even there though, the popular stuff has already been figured out. For example, suppose you want acroread or flash or vmware. Use google, and search for the stuff being spewed into the log. Skip past the idiots who just disable SE Linux; it may help to add "chcon" (an SE Linux command that fixes many such problems) to your google query.

Typically you find instructions for some "chcon -t foo_t /usr/lib/" command, often needed because the app developers were total idiots who couldn't figure out how to run gcc correctly. Run that and be happy.

(not that you should trust 3rd-party binaries to be free of malware, but hey I understand...)

Re:SE Linux is rarely noticable and easy to fix (1)

andymadigan (792996) | more than 7 years ago | (#19407167)

Speaking as a developer:

The binary was probably generated correctly, and cc was probably called correctly as well. Your system isn't behaving because you installed something that deals with permissions in a non-standard way (standard == POSIX). If the makers of your distro make sure the binaries they generate are tagged properly for whatever system they are using that is great, but I find it unlikely that there is anything in the binary that is there specifically for SE Linux.

example: text relocations (3, Informative)

r00t (33219) | more than 7 years ago | (#19407495)

Common problem: you built a library (a *.so file) without compiling all the object files (the *.o things) with gcc's -fpic or -fPIC option, and/or you forgot to specify -shared when linking.

When you make this kind of screw-up, you cause something called "text relocations". These don't even work on non-x86 and Debian bans them anyway for reasons related to memory usage. A text relocation means that the loader patches the code itself, rather slowly, when loading the shared library. This requires memory to be both writable and executable, which is a no-no for security against buffer overflows. SE Linux is usually set up to prohibit this by default.

If your broken shit runs as a server or gets loaded into a web browser, you greatly decrease security. You suck. Fix your shit.

I'm a developer too. I've upped my standards. Up yours!

Re:SE Linux is rarely noticable and easy to fix (1)

init100 (915886) | more than 7 years ago | (#19408331)

it may help to add "chcon" (an SE Linux command that fixes many such problems) to your google query.

It may also be easier to remember the chcon command if you know that it means CHange CONtext.

Re:100% Secure (1)

jkrise (535370) | more than 7 years ago | (#19406605)

SELinux probably works just great for what it was designed for - NSA top-secret systems. There's always a tradeoff between security and usability, and right now, SELinux is just above yanking the power cord.

I simply yank the network cable instead.

Some good network security tools that I use. []

Better, but still a way to go. (2, Interesting)

Cozminsky (452030) | more than 7 years ago | (#19405767)

Although SELinux is a step in the right direction it's still basically a system of ACLs. It still suffers from the problem of the confused deputy [] . I think proponents of object-capability based security are correct in their thinking. Some interesting stuff going on in this respect is the E programing language [] .

nope, SE Linux solves that (1)

r00t (33219) | more than 7 years ago | (#19406557)

Well actually you don't even need SE Linux.

First of all, don't make the compiler have setuid-like rights and don't give it arbitrary write control over a home directory. That was pure idiocy.

For ages, UNIX-like systems have used setgid (not setuid) to solve this for game high-score files. It does allow a bug in the game (an exploit perhaps) to corrupt the files, but your favored solution doesn't fix that either. Linux adds append-only files, which might be desirable for the compiler log example.

SE Linux is overkill, but we can certainly use it as an alternative to setgid. Make the file world writable. Invent an SE Linux type for it, such as fort_stat_t. Invent an SE Linux role for the compiler, such as fort_r. Mark the files appropriately. Define SE Linux policy such that processes in the fort_r role can only write to files with type fort_stat_t or with the type you use for home directories. Also define SE Linux policy such that nothing else may write to files that have type fort_stat_t.

That's not entirely true. (1)

bitbucketeer (892710) | more than 7 years ago | (#19405783)

There is no 100% protection. There are only SELinux rulesets for less than two dozen server applications, which is a very small percentage of the over 1100 packages which make up RHEL5. Even so, there's a decent book from O'Reilly, and Linux Journal recently covered SELinux... so only ignorant, overpaid sysadmins would blindly disable SELinux in the datacenter!

Re:That's not entirely true. (1)

timmarhy (659436) | more than 7 years ago | (#19405917)

not many employee's are overpaid in IT. consultants on the other hand.....

Re:That's not entirely true. (2, Funny)

crawly (890914) | more than 7 years ago | (#19406081)

consultants on the other hand.....

So where do I go to sign up for one of those consultants jobs then. I'm sure I could turn off SELinux just as well as anyone else.

Re:That's not entirely true. (1)

r00t (33219) | more than 7 years ago | (#19406571)

Maybe true: "two dozen server applications"

Maybe true: "over 1100 packages which make up RHEL5"

Not true: anywhere near 1100 server applications in RHEL5

RHEL5 probably ships about two dozen server applications. That's plenty. What, you need a gopher server?

News flash buddy... (1)

bitbucketeer (892710) | more than 7 years ago | (#19407571)

SELinux isn't just for protecting server applications. It's a per-app set of rules for how the program is expected to operate so that it keeps the unexpected from happening. Now, I'll give you that the very nature of free software development will make keeping an external ruleset in sync with a project very difficult. So, it's very unlikely to happen (generating rulesets for the rest of the apps in RHEL, that is).

I'm not sure of the advantages over xp sp2 (0, Troll)

King_of_Prussia (741355) | more than 7 years ago | (#19405815)

It adds a "security center" which badgers people into running Windows Firewall, having antivirus software and letting security updates be downloaded and installed automatically. But that's not all!

There are some neat updates to the wireless networking stuff, adding pretty boxes to make the whole thing somewhat more comprehensible to your average computer user, complete with a huge "this is an open network, anyone can connect to it!" type message.

The update also adds the "information bar" to IE, a little bar that slides down when it blocks a pop-up or activex control. You have to click the bar and then click the right option on the menu to get either things to display. Dialog boxes make more sense: yes/no in activex prompts has been replaced with "install/don't install" and a "never install from [whoever]" option added. "Open/Save" becomes "Run/Save" in the dialog box for download executables. Little shields pop up all over the place to alert you if you're about to do something insecure.

Compare this to SELinux, which -- quite apart from screwing things up whenever I try to install it -- has all sorts of insecure services that no-one would use enabled by default. If you sign up to something like the Mandrake security mailing list, you get a ludicruous number of emails -- and I don't think SELinux has any real equivalent to this completely-hands-off automatic update functionality.

So which OS is more secure? Windows gives you the tools you need, while SELinux gives you just enough rope to hang yourself with.

Incidentally, Snape dies so Harry can kill Voldemort and survive []

Re:I'm not sure of the advantages over xp sp2 (1)

thegrassyknowl (762218) | more than 7 years ago | (#19406559)

I am not sure whether this is funny, a stupid poster or a troll.

I wish I had mod points or the time to address the post on the merits of all 3 points. I'm going to go with Stupid Poster, because that seems to be a good median place for the ~6bn people on earth!

Re:I'm not sure of the advantages over xp sp2 (1)

BKX (5066) | more than 7 years ago | (#19406849)

I don't why whoever modified you as interesting did so, considering how confused you seem (I don't mean to sound insulting; I'm just in one of those snarky moods. :) ). SELinux doesn't have any services to begin with. It's a security layer that provides fine grained control of permissions for individual executables and services. Perhaps you were refering to Red Hat Enterprise Linux (RHEL), which does come with a buttload of services at install (and can use SELinux), although I don't believe any are configured to run by default (except for sane services like ssh, and even then I'm not sure.).

SELinux is a problem (1, Interesting)

Henry V .009 (518000) | more than 7 years ago | (#19405829)

I've never run an RHEL server for more than 24 hours without experiencing an SELinux problem. Every new release, the same story.

Just the other day, I tried to install "rt" on a brand new RHEL 5 box for a demo (we're looking into new ticket systems). I found that "yum install mysql-server" hung forever. Same with the apache install. It turns out the SELinux thinks that useradd being run by the mysql rpm (to add user "mysql") was trying to attack /dev/random. So SELinux blocks reads to /dev/random and useradd hangs which makes yum hang. And yum is one process that I sure don't want to kill.

This wasn't a hacked up RHEL box or anything. I had installed it that morning.

There were suggested fixes in my logs, but they did not work. My solution? Disable SELinux. It's just not ready for prime-time. Or production environments.

Re:SELinux is a problem (0)

Anonymous Coward | more than 7 years ago | (#19405845)

My solution: install Solaris. Containers really do work.

Containers.... (1)

thule (9041) | more than 7 years ago | (#19405893)

..,under Trusted Solaris? Or how about a container that provides a trusted environment? Explain.

Re:SELinux is a problem (3, Informative)

farkus888 (1103903) | more than 7 years ago | (#19405913)

saying that you can't install things while selinux is running is a flaw of selinux is like complaining about needing to be root to install things. its job is to keep shit from changing, changes like installing mysql could be done while it was running it wouldn't be doing its job. disabling it long enough to make changes is just like su or sudo to get temporary root access inside your normal user environment.

disclaimer -- I may be completely off base because I don't use it in a production environment, I disable it during install whenever putting a fedora box up for use.

Re:SELinux is a problem (1)

Henry V .009 (518000) | more than 7 years ago | (#19406013)

Sure, I've come to the conclusion that that's the only way to use SELinux if you're going to. But Red Hat documentation doesn't suggest that method of administering your server. Also, notice how yum gives no warning about SELinux being on when you use it to install packages? SELinux is always there to bite you, even if you're following all of Red Hat's system administration guidelines. It's not worth the aggravation.

SELinux - set permissive temporarily (1)

ancientt (569920) | more than 7 years ago | (#19405971)

You can set it to temporarily permissive with setenforce 0.

Ironically enough when I install systems I leave it enabled, but our security administrator turns it off. He used to try to leave it on but after pulling out what little hair he had, he is opting for the easy solution these days. Fortunately he doesn't set many machines up. I think he'll go back to using it as we move to RHEL 5 since it seems to be more sanely configured.

You can find a nice note on it at: [] which is on an EnGarde Linux page; they're one of the groups who spend some time studying and working with SELinux.

doubt this is true (1)

r00t (33219) | more than 7 years ago | (#19406619)

Granted, I'm using something a tad different. I've used all three of Fedora Core 5, Fedora Core 6, and Fedora 7. Not a one of them have had SE Linux prevent yum from working. I just su to root and install stuff. I can't imagine that RHEL would be worse than all 3 of the most recent Fedora versions.

That's with the default policy. The strict policy is harder, but not by much. You just need to log in with the correct role; this is a RTFM problem.

Re:doubt this is true (1)

Henry V .009 (518000) | more than 7 years ago | (#19406837)

You think I'm making it up? Well, I can prove it with logs:

May 21 07:56:34 mimir setroubleshoot: SELinux is preventing /usr/sbin/usera dd (useradd_t) "read" to random (random_device_t). For complete SELinux mes sages. run sealert -l 918e1f4a-e9d6-4703-8b36-29d2a444339a

And I didn't even notice this until just now when I was greping the log:

May 21 10:01:38 mimir setroubleshoot: SELinux prevented /usr/bin/procmail f rom reading files stored on a NFS filesytem. For complete SELinux messages. run sealert -l 1703d21b-1b0a-416d-ad2e-4e6c47d5f5a3

Joy, it looks like SELinux sent some of my mail to oblivion.

Re:doubt this is true (1)

ryanov (193048) | more than 7 years ago | (#19407133)

Did you install something that changed the security context of /dev/random?

Try "restorecon /dev/random"

Better yet, run "man restorecon" and then decide what to type.

Re:doubt this is true (1)

Henry V .009 (518000) | more than 7 years ago | (#19407267)

That was the first thing I tried.

Re:doubt this is true (1)

r00t (33219) | more than 7 years ago | (#19407525)

Well, this is really off the wall. I find it hard to believe that the last 3 Fedora releases all worked fine, yet RHEL5 does not. Perhaps it was based on Fedora Core 4? It doesn't sound all that old.

In case you hadn't noticed, "ls -Z" and "ps -M" are helpful.

Just disable it for certain apps (5, Informative)

KidSock (150684) | more than 7 years ago | (#19405873)

For those who may not fully understand what SELinux actually does, let me give you an example.

With SELinux enabled, by detault Apache will be prevented from accessing files other than those of very basic web apps, it cannot open sockets to other hosts, etc.

For IntErnet applications this is quite reasonable and with the machine on the most hostile network around you really should use SELinux. It won't stop a break in but it can seriously curtail the effects of one.

For an IntrAnet application that is trying to write to custom log files and talk to LDAP servers and such, SELinux is not going to let you do that. At this point you have two choices - 1) tweek SELinux properties to allow only the specific functionality required by the application or 2) disable SELinux for that entire application. Considering an IntrAnet affords some physical protection, SELinux is less important in that environment and therefore, in this scenario, if you're really not savvy with SELinux and you don't have the time to get into it, I recommend just disabling it for entire application using it.

For example, to disable SELinux just for Apache you do:

# setsebool -P httpd_disable_trans 1
# service httpd restart

Note that SELinux uses db files that remember these changes so they will persist across reboots and there are no config files to edit. It's a nice system because it's easy to add these commands to install scripts and such.

So don't get bent about SELinux. Learn enough to disable it for specific apps and then turn it on all over. Keep an eye on the log files. If SELinux is stopping access to things by apps it will report it in the log file. Then determine if the app should be doing that and if so disable SELinux just for that app.

I'd rather just enable it for certain apps (0)

Anonymous Coward | more than 7 years ago | (#19406739)

Like apache or whatever. That's probably the most gain for the least pain. But when you bleeding-edgers get it sorted maybe I'll turn it back on.

anecdotes... (1)

jdogalt (961241) | more than 7 years ago | (#19405919)

First, my name doesn't have to be Bruce Schneier to dismiss anybody claiming "100% protection".

Second, I have nothing against SELinux, though I will consider it broken until a default install handles this situation correctly-

1) I install the OS, leaving the default selinux enabled
2) after running a webserver for awhile, I decide I want to move my apache's docroot from /var/www/html to /mnt/data/www/html, after having mkfs.ext3'd some partition and mounted it at /mnt/data.
3) naturally after "cp -av /var/www /mnt/data" as root, I edit /etc/httpd/conf/httpd.conf, changing any instance of /var/www to /mnt/data/www"
4) I run 'service httpd restart' (reload should work as well of course)

The last time I tried this with a version of redhat/fedora that had selinux enabled, it failed. And for most of the sites I'm serving (many that are never seen outside my home non-internet-connected lan), I see no motivation to invest my time in selinux.

Now mind you, I completely expect things like this to be worked out by the selinux folks, if they haven't been already. The last redhat person I spoke with who defended the above, claimed that they didn't want people mucking around with commandlines and editing configfiles. I then asked that person how I should have gone about changing my DocRoot in such a way that SELinux "just worked". I got no reply. Given no reply, I can speculate as to one- They expect /var/www/html to always be the docroot, and /var to be on LVM and online expandable. Ok. Whatever.

Re:anecdotes... (1)

farkus888 (1103903) | more than 7 years ago | (#19405963)

of course they expect /var/www/html to always be the docroot. its an ACL. it expects certain important files to be in their default location so it can allow/deny access appropriately. if there is no way to change the config so selinux can be told the new docroot then there is a problem. personally I couldn't tell you how or if it can be changed but I wager its in the documentation somewhere.

Re:anecdotes... (1)

ScriptedReplay (908196) | more than 7 years ago | (#19405983)

Let me introduce you to the -c option of cp, also known as --preserve=context.

Re:anecdotes... (1)

atomic-penguin (100835) | more than 7 years ago | (#19406329)

Let me introduce you to the -c option of cp, also known as --preserve=context.
Here's the thing, cp -a implies -p or --preserve=context as you put it. So the parent was doing just as you described.

It's not just Apache that will refuse to start after you've archived a mountpoint and moved it to a different device or location. I had a similar experience using RHEL with SELinux enabled. I cloned a RHEL template in VMWare virtual center. Then I went into single user mode, and stopped remaining services writing to /var, at this point I archived /var. I added a new virtual disk, formatted it, mounted it up as /var and restored from my archive.

At this point I should be able to reboot or change the runlevel and start back up using the new /var mountpoint. Syslog hung on startup! I ended up troubleshooting this problem several hours with no logging available. The most puzzling part was when I tried to start up syslog from the command line and it would take off just fine. It would inexplicably hang every time it was called from an init script.

It turns out SELinux was preventing syslog to startup. It was impossibly hard to track down why syslog was failing, and why syslog was the only thing writing to /var which seemed to be affected.

Let me re-iterate the point. This problem I and the grandparent poster experienced has nothing to do with "preservation" of context, permission modes, ownership, timestamps, ACLS, or any other file or filesystem attribute.

Re:anecdotes... (2, Interesting)

chill (34294) | more than 7 years ago | (#19406677)

The problem you and the grandparent have is not grokking what RBAC and MAC are and how the traditional Unix/Linux root == God method of security is fundamentally flawed.

SELinux makes sure things that are set up don't get arbitrarily changed. It isn't prescient to know that YOU have proper authority to make those changes. You have to tell it that.

So, with SELinux you have one more step when you make substantive changes. Tell SELinux about it.

Simply moving folders or files around as root and modifying program config files is NOT enough. What the hell is the difference between YOU doing it and a HACKER doing it? SELinux doesn't know. Hell, things like moving my Apache docroot around is something I'd really want to have secured.

SELinux (and Solaris 10) try to fix that by implementing RBAC, MAC and Type Enforcement. []

Re:anecdotes... (1)

ScriptedReplay (908196) | more than 7 years ago | (#19406799)

Here's the thing, cp -a implies -p or --preserve=context as you put it. So the parent was doing just as you described. Here's the thing, straight from the horse's mouth ... err ... man (that is, man cp)

-p same as --preserve=mode,ownership,timestamps
--preserve[=ATTR_LIST] preserve the specified attributes (default: mode,ownership,timestamps), if possible additional attributes: links, all
So -p does not preserve contexts; -c does. Hint: backwards compatibility.

Re:anecdotes... (1)

atomic-penguin (100835) | more than 7 years ago | (#19407177)

The grandparents 'cp' flags are irrelevant in preventing what occurred. SELinux is hooking in and preventing him making that change before any file permission or filesystem attribute is ever taken into account. So enlighten me how context preservation applies to this situation whatsoever?

Where in the manual of cp, coreutils documentation, or SELinux documentation, does it say context preservation has anything to do with SELinux?

Re:anecdotes... (0)

Anonymous Coward | more than 7 years ago | (#19407501)

context manipulation (for instance through -c, -Z) is a specific SELinux-related addition to cp, as it pertains to preserving the files' SELinux security context (aka label) on copy. In particular, a strict enough policy for Apache could forbid it to access files that do not have the correct security context - useful for instance in preventing write access to unauthorized areas (note that a SELinux write interdiction takes precedence over +w for the httpd user, so "cp -p" is not sufficient to ensure that things relying on write access won't break after copy)

Do you feel enlightened yet? (I have some 1-8xx-ABUDDHA number that you can try if all else fails :-) barring that, this is the best I can do without RTFM-ing you)

Re:anecdotes... (2)

jdogalt (961241) | more than 7 years ago | (#19406355)

Great, after decades with --archive --verbose being sufficient cp flag knowlege, now I have to pay attention to some new crap. (i.e. the main point I was making). Somehow having to learn to deal with and use --sparse for tar seemed less offensive to me. Mainly I suppose because the --sparse gives me immediate satisfaction of seeing the benefits of a new feature (i.e. free disk space, smaller files, etc...). Wheras the --preserve=context and selinux only give me "security". Personally I'll stick with the philosophy that security should be part of the foundation, invisible to the user interface. (not that I won't use selinux where appropriate, just that I'll continue to be vocally annoyed).

Re:anecdotes... (1)

ryanov (193048) | more than 7 years ago | (#19406483)

Only security, eh? I hope you are not responsible for major systems is all I can say. You might not like command line flags, but... come on. How can security be totally invisible to the person supposedly managing the system?

Re:anecdotes... (1)

jdogalt (961241) | more than 7 years ago | (#19406539)

It's called software design you idiot. The apache webserver was designed so that if I want to move docroot, I edit a setting in httpd.conf. THAT ADMINISTRATOR ACTION IS WHAT TELLS THE SYSTEM THAT APACHE IS NOW ALLOWED TO ACCESS THE FILES IN THE NEW LOCATION.

Any further administrative actions required which DO NOTHING MORE THAN EMPHASIZE THE INTENTION OF THE ORIGINAL ACTION, are evidence of a poorly designed security system. IMO.

Re:anecdotes... (1)

ryanov (193048) | more than 7 years ago | (#19407035)

No, it is not. That administrator action is what tells the system that that is where Apache should look for the files, and that is all it does.

If that directory does not exist or is chmoded 000, it is still not going to work -- that might require further administrative action to correct, but it doesn't mean that Linux or Apache have anything wrong with them; that is just how the system works.

SELinux works in much the same way, except there are policy files you can edit that will automatically apply permissions for you if they are written right. You can set them by hand as well.

Re:anecdotes... (1)

fimbulvetr (598306) | more than 7 years ago | (#19406651)

Oh yeah, heh, that progress thing again. Sorry about that. Will try harder to keep everything at 1970s technology so you don't have to do that "learning" thing "again". KTHXBYE.

Re:anecdotes... (1)

ryanov (193048) | more than 7 years ago | (#19407225)

In addition, most fileutils commands accept the -Z flag, which does the SELinux related thing on whatever that command is:

# ls -laZ
drwxr-xr-x  root     root     system_u:object_r:var_log_t      .
drwxr-xr-x  root     root     system_u:object_r:var_t          ..
-rw-r-----  root     root     user_u:object_r:var_log_t        acpid
-rw-------  root     root     user_u:object_r:var_log_t        anaconda.log
-rw-------  root     root     user_u:object_r:var_log_t        anaconda.syslog
drwxr-x---  root     root     system_u:object_r:var_log_t      audit
-rw-------  root     root     system_u:object_r:var_log_t      boot.log
-rw-------  root     root     system_u:object_r:var_log_t      boot.log.1
-rw-------  root     root     system_u:object_r:var_log_t      boot.log.2
-rw-------  root     root     system_u:object_r:var_log_t      boot.log.3
-rw-------  root     root     system_u:object_r:var_log_t      boot.log.4


Re:anecdotes... (2, Insightful)

ryanov (193048) | more than 7 years ago | (#19406327)

Just because you don't know how to do something doesn't make it broken. There are additions to almost all of the common GNU fileutils that support SELinux. You could alias them in .profile or equivalent if you wanted, like many distros do with -i on rm, etc.

Of course, it sounds like many of your uses don't call for it, but really, what's next? Saying "I yelled at the PC to copy my files -- it didn't. Until they work this out, I consider it broken."

Re:anecdotes... (2)

jdogalt (961241) | more than 7 years ago | (#19406519)

I think at some point, SELinux was touted as being a *transparent* security enhancement. Which sounded really cool to me. Then I discovered that it was a _vastly complex beast that required constant attention in order to prevent breakage of applications in situations where those applications were being used precisely as the application developers had intended_.

SELinux is hard to use. The amount of energy required by my brain to contemplate MAC policies for all the types of situations I run into, is not worth the security it is bringing me.

Just because all the coders who wrote the linux kernel, apache webserver, and distribution I was using didn't know how to implement SELinux's features in the first place, does NOT mean that they were stupid, or that their code was broken.

The question is whether or not selinux is worth the trouble. I'm arguing (not alone dare I say) that in a lot of situations (majority? vast majority?) it is not. But don't give me this bullshit about 'because I don't know how to use it doesn't mean it's broken'.

Re:anecdotes... (1)

ryanov (193048) | more than 7 years ago | (#19406985)

It's really only transparent if the default installation is set up properly. This is really up to the person who is installing the software. In all cases I've seen, if you have something that is officially supported by RedHat, you're in the clear. I haven't had any problems with RedHat's Apache RPM's, or MySQL or the rest. The trouble I've had is from installing shit from scratch. In that case, yes, you do need to install stuff the right way.

The features are properly implemented in those places from what I can see (and really, it's not Apache's place necessarily to "support SELinux," they just need to collaborate with the SELinux people to make the permissions they actually require known. Really, any group that can read source code could do that without Apache's help... from what I've seen, this has happened. If you build from source, though, you're probably on your own.

Very few things on a computer can be completely transparent -- you do still have to know what you're doing if it is something at this level.

Less complex alternatives exist to SELinux. (5, Interesting)

liftphreaker (972707) | more than 7 years ago | (#19405935)

Whatever Redhat says, the fact remains that SELinux is an incredibly complex, and incredibly undocumented (or under-documented) piece of software. It took me two months to really understand how it worked and what exactly to configure when I needed to fine-tune access rights and permissions on our servers. That is a nightmare I wouldn't wish on anyone.

Redhat is not going to get much traction from this unless there is a very easy to use tool (preferably with GUI) to configure and customize SELinux, out of the box. The default tools on RHEL allow a few options during install time, but it is truly primitive.

There really doesn't need to be this huge love/hate relationship with SELinux, in fact why not just throw it out and use something far simpler and neater? There are several options out there. Off the top of my head I can think of GRSEC : []

We've been using this on two of our server farms and it's been doing a superb job, and it is very very easy to customize compared to the SElinux nightmare.

Re:Less complex alternatives exist to SELinux. (1)

ryanov (193048) | more than 7 years ago | (#19406345)

Undocumented [] you say? I think not.

Something you may not be thinking about -- understanding where you need your permissions on your systems is something that I'd personally recommend REGARDLESS of SELinux.

SE Linux creating problems. (1)

Zombie Ryushu (803103) | more than 7 years ago | (#19405973)

Yes, I've had my share of problems with SE Linux on CentOS. I tend to disable it. I've had SE Linux cause badly configured CentOS Boxes on a CentOS 5.0 Beta (4.92) hang the machine because of SE Linux Policies. However, correctly configured, SE Linux can prevent a unit from being tampered with.

On the issue of security. There are some Network and Domain Level hiccups. Ideally, all Linux applications should support Kerberos for their Single Sign on facility. However, in a lapse of forethought, there are some important ones that do not.

One of these is KDE's Kontact when using XMLRPC. Why is this a problem? If you use Kolab, or eGroupware, you have to manually enter username and passwords for Users. This is a replay vulnerability, and, if your password is changed in LDAP and Kerberos, Kontact doesn't know it, and Kontact repeatedly sends the wrong User name and password to the XMLRPC Server until it blocks the user. Now, with IMAP4 and IMAPS? Click the "Use GSSAPI" Checkbox in server properties in Kontact, and Mail will use Kerberos no problem.

If advanced Linux projects like KDE are serious about security, and I think they are, extensive use of Kerberos in a Domain Environment like mine is a must.

frist St0p?! (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19406023)

BE A COCK-SUCKING chosen, whatever by the poSlitickers AT&T and Berkeley OpenBSD wanker Theo Keep unnecessary

No thanks (0, Troll)

Blackknight (25168) | more than 7 years ago | (#19406073)

SELinux is a huge pain in the ass and most apps don't support it. I know that Cpanel doesn't work with it which is pretty much the industry standard for web hosting control panels. I've even got our kickstart server configured to boot every new server with selinux=0, we simply don't have time to screw around with it trying to make things work.

The traditional unix security model is fine, it's worked for over 40 years, why change it now? People that need more restrictions are free to install selinux, grsec, openwall, or anything else that they want, we don't need SELinux shoved down our throats by Redhat or any other vendor.

Re:No thanks (1)

ryanov (193048) | more than 7 years ago | (#19406385)

I defer to those with more SELinux-fu than me (apparently not you -- no offense), but is it even possible for an application to not be compatible, period, with SELinux? I'm under the impression that it's not -- that would almost be like saying that an app required all of its files to be chmoded 777 in order to run. That may be the easy way out, but there is certainly a more restrictive set of permissions that would work (for example, I doubt there are any binaries that need the permission to write to themselves as they run).

Re:No thanks (1)

fimbulvetr (598306) | more than 7 years ago | (#19406703)

You're talking about cpanel - I wouldn't recommend touching that with a 10 foot pole. Cpanel isn't even compatible with itself.

RHEL = Red Hat Enterprise Linux (0)

Anonymous Coward | more than 7 years ago | (#19406765)

For those of us wondering what the article is about, RHEL = Red Hat Enterprise Linux.

Applications need to be reworked for SELinux (1)

Animats (122034) | more than 7 years ago | (#19407247)

We know how to do serious security. Programs have to be divided into big parts that are untrusted, and small parts that are trusted. Only the latter get much in the way of privileges. The key concept is that only a small fraction of the code is trusted, and you make that code simple, paranoid, and well reviewed.

That's the application model for which SELinux is designed. This was all figured out in the early 1980s and used in a few systems in the DoD community, but the commercial community wasn't worried about security back then. Which is how we got into the mess we have now.

Complicating the problem is that these separate parts have to intercommunicate, and interprocess communication on Linux/Unix still isn't very good after thirty years. Pipes and FIFOs are too limited, and shared memory breaks security boundaries. System V IPC is the best mechanism for communication across a security boundary, and it's well supported in SELinux, but almost nobody uses it.

SELinux locks out self-modifying code (1)

Myria (562655) | more than 7 years ago | (#19407639)

Sorry, but I don't want to have to get the administrator's permission to write my own program that makes self-modifying code. This is also why a user-local install of Wine is impossible when SELinux is enabled.

Of course, SELinux does nothing about the problem that a rogue program could pipe out to gdb, a program flagged for ptrace(), and do that stuff anyway.

The only SELinux tip you will ever need: (0, Troll)

skinfitz (564041) | more than 7 years ago | (#19407979)

Edit /etc/selinux/config

Make sure you have this line:

Save the file and reboot.

Discover that all those things you couldn't get working on Linux suddenly start working meaning no, you don't have to go back to Windows.

yuko fail 1t (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19408113)

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?