Continue reading »]]> It’s been three years since we upgraded the hardware that hosts our various sites. I contacted my provider (Crucial Paradigm) and got some competitive offers. Stefan, my friend in Berlin that I split the server with, and I agreed on the following specs:

• Athlon 64 x2 4000 (2 cores @ 2.1GHz, 512K L2 each)
• 4GB RAM, 160GB SATA, 100Mbps
• CentOS 5
• Apache, BIND, MySQL, Postifx, Spam Assassin, ClamAV, Cyrus IMAP
• SELinux enforcing

Once again this is going to be a dedicated, remote, hosted server. A few days later and they contacted me with the login information. I’m going to describe the move from a high-level. I’m not going to go through the individual config file modifications or how to dump a Cyrus database.

It only took me about a day to prep the new system for the move. Stefan was gone for a week so I could move pretty much all of my stuff but I would wait until he got back to move the shared mail services. It is rather difficult to incrementally move users from one system to another using Cyrus so I just did a test migration of the IMAP spools and databases but waited on actually updating the DNS MX records.

First I updated the glue records and name servers at my registrar. I made the new system master and the old system I just modified to run as a slave. I also had Josh fix his config since he is my DNS buddy (I highly recommend using the DNS buddy system). With DNS up and running I added entries for the new server.

Then I moved my website. I just dumped my databases and pulled them into the new system. A few Apache tweaks and everything was good to go. I was pulling my hair out at one point trying to figure out why the CentOS default page was appearing but I finally tracked it down to a welcome.conf configuration file. I removed that and found I could debug Apache config problems more easily.

I decided to tackle all of the SSL stuff at once. I setup Apache, Cyrus, and Postfix w/ certs and CAs. I tested each service to ensure I had the directory permissions correct and had the authentication mechanisms properly configured. It is at this point that I tested a Cyrus migration knowing that I would be repeating the process again later.

Then I moved on to configuring the rest of the Postfix chain using Amavis, Spam Assassin, and ClamAV. There was plenty of documentation on this process available online. Note that ClamAV (and maybe a few of the others) are only available in the rpmforge yum repos. These programs aren’t officially part of the CentOS/RHEL distributions but are commonly used by the user communities. As a result their configuration files don’t mesh precisely with the rest of the services, for example storing the virus database in /var/clamav by default instead of /var/lib/clamav. I fixed these discrepancies and would recommend you do the same. It did take me a while to track all of these down. freshclam (the ClamAV updater) was running from a Cron job. It was trying to write to “/var/clamav” which didn’t exist. As a result the virus signatures weren’t updating. I discovered this only through reviewing the logs.

As soon as Stefan got back he moved all of his services and data. Finally we cut the mail over to the new system by fixing the MX records and using the Postfix transport map feature on the old system to force it to relay to the new server. That completed the migration.

SELinux
Upon login I discovered SELinux was disabled despite my specific request that it be enabled. I decided to fix it by hand instead of letting Brickwall fix it automatically to show that going from disabled to permissive to enforcing isn’t bad and shouldn’t be scary. It should be done regardless of the presence of a management tool like Brickwall. I changed the flag in /etc/selinux/config to enforcing and ran # touch /.autorelabel.

I also added enforcing=0 to the ends of the kernel command lines in /boot/grub/menu.lst.

Tangent – I chose this route, modifying the grub file, for going into permissive mode during configuration and testing instead of setting the flag in /etc/selinux/config to permissive. Applications, such as those built into Red Hat and CentOS as well as third party applications like Brickwall, modify the settings in /etc/selinux/config. It is possible for me to inadvertently set the system to boot into enforcing before I am ready using these applications. Since this is a remote server and the configuration is in flux I want to make sure a quick remote reboot request gets me back in to my system. It is the exact same as using iptables remotely; you don’t load the firewall rules automatically on boot until you’re sure you can get back in through SSH. As soon as I’m confident that I typed in the SSH network settings properly the system boots into enforcing mode.

After setup is complete remember to remove the kernel command line flag – always going into permissive mode on reboot, much like not auto-loading firewall rules, is a patentable bad idea on a production system.

I disabled all unnecessary services (everything except SSH at this point) and rebooted. The system relabeled and came up in permissive mode. Everything was working fine and running in the proper SELinux domains according to # ps axZ. I ran # setenforce 1 to go into enforcing mode for the first time.

Nothing bad happened. The world didn’t end. The system didn’t stop responding. I’m also assuming the rampant rumor that SELinux kills Giraffes in enforcing mode is false because I watched the news and saw nothing Giraffe related. This SELinux stuff really isn’t as hard, or as mean as people make it sound. BTW Brickwall would have taken care of all of this editing of SELinux config files and relabeling stuff for me if I wasn’t such a control freak.

Well turning it on is one thing. Really using it is a whole ‘nother thing right? That is where Brickwall comes into play (disclaimer [1]). I mentioned it before but think “SELinux Management” and there are free versions for Fedora and demos for RHEL and CentOS. Because I’m cool I get to use the Enterprise Edition. Mere mortals may have to run Professional or Standard via “ssh -X”. There is no difference in configurability. Both use the same configuration GUI. The only policy difference is the policy for the remote daemon – not really needed if the remote enterprise management daemon isn’t installed. One has centralized/remote management, the other does not.

Brickwall Enterprise Edition has two components, the centralized manager application with configuration editor and the remote daemon. The centralized management application takes different plug-ins – I’m only going to be using Brickwall plug-in that supports general SELinux configuration. I installed the Enterprise Manager with the Brickwall Enterprise component on my desktop RHEL 5 system. This installation process generated the remote daemon RPMs for me. These packages include SSL keys tying the remote daemon to this specific Enterprise Manager install. The SSL keys are used to encrypt the network traffic between the manager and the client daemons.

I installed the remote daemon on the new system. It is just a little daemon that facilitates remote management of SELinux policy. I added one of the IPs of this system to a group in my Enterprise Manager. The system had to be “activated” which means Brickwall had to switch from the standard targeted policy to a Brickwall policy. There aren’t really any functional differences between the two policies – a default Brickwall policy is semantically equivalent to a targeted policy as shipped by Red Hat/CentOS. But the Brickwall policy contains the structure we need in-place to customize the policy later.

Continuing w/ Brickwall I started restricting network settings for the services I would be running (listed above). I restricted things like the spam, virus, mysql, and other mail filtering services to local host only. I restricted service ports to meet my requirements. I applied the configuration changes and rebooted and went into enforcing to verify services came up in the proper domain after a reboot.

All of the SELinux domain names show exactly what processes they target so run`ps axZ`. All of you key services should be running as “*:*:servicename_t”, such as “mysqld_t” or “httpd_t” or “postfix_smtp_t”.

The only thing that should be “unconfined_t” is user processes or custom services that aren’t targeted by SELinux. Note that there are some 200 odd applications or services covered by SELinux so there is a good chance your “custom service” is covered.

[1] Disclaimer: I work for the company that makes Brickwall. Since I’m only an amateur blogger (not commerically endorsed, still eligible for the Bloglympics) and since this doesn’t appear on tresys.com I’m not going to be writing a review or praise the software, I’m just going to run through using it to batten down the hatches on my system.

Continue reading »]]> Lately conversations keep turning up new slogans for SELinux. I figure this is as good a place as any to keep a running list so here we go:

• SELinux – Because users do weird shit.
• SELinux – Fuck root.
• SELinux – Hampering administrators since before it was cool.
• SELinux – Take revenge against the BOFH
• SELinux – High-security gone haywire.
• SELinux – Turning it off is like removing the batteries from a smoke detector. Sure it sounds better but you might get burned.
• SELinux – Because life is too simple.
• SELinux – AppArmor sucks.
• SELinux – It’s too early in the morning to be cleaning up after 11-year old kiddies.
• SELinux – Too powerful for our own good.
• SELinux – Here’s our root password, what’s yours?
• SELinux – Didn’t they teach you about using protection in high-school?
• SELinux – Blind faith not required

Thinking about slogans actually got me thinking about “short reasons to use SELinux”.

• SELinux will save you tons of money, your TCO will go down and your ROI will go up.
• SELinux supports 3-letter acronyms out of the box, no complex policy changes required.
• Zero day vulnerabilities are a fact. Do something about it.
• Trusted Solaris has been end-of-lifed and you’re not in the government space to begin with.
• Path-named based access control is weak.
• Implicitly trusting admins doesn’t have to be SOP.
• You’re not a security expert, let us do the hard work.
• The US military (and others) trust SELinux with their information, shouldn’t you? [1]

These are just a few.

[1] The answer to this question might actually be a resounding “no!” Don’t worry, I’m not offended.

Continue reading »]]> Jarno over at F-Secure commented on the recent “trojan” for the iPhone :

Hopefully this serves as a warning for those who have opened their iPhones using a security hole in the system and then installing unverified software without a second thought to what they are doing.

Warning noted. The lesson here is not that we, the hacked iPhone community, should not take advantage of the holes; the lesson is use some common fucking sense. Especially if you’re using a hacked phone with wireless stuff coming out of the wazoo.

Those of you reading this via RSS can fuck off… just about… now.

<!–more–>

Sorry, I’ve been meaning to do that for awhile.

Take note of three four things [1]:

• 1. It is portable
• B. It is highly networked
• 3. You can install all sorts of things at the touch of a finger
• 4. It might run some derivation of the almighty Unix, we’re not really sure. And the terminal emulation app is no help.

When you combine these things plus a pinch or two of stupidity and you have yourself the makings of a good time. iPhone users and smartphone users in general need to understand the power of the devices in their pockets.

The more power a system has the more likely someone is going to hack it. CPU cycles, bandwidth, data, and prestige are fragments of this power. A random server in China ready to be rootkit’d to serve copyrighted material on IRC, the credit card companies database server, and the really popular and trendy pocket-sized computer – they all have this aura, this power. An 11 y/o [q] is drawn to this power like a moth to light. You can’t really stop the kid, just like you can’t stop the moth. But you can turn off the light.

But think about power in relation to other devices. A bluetooth headset: portable, networked, but you can’t really do a whole lot with one. If you find a flaw in my Jawbone’s Bluetooth implementation and manage to exploit the flaw BFD. I don’t care if you can hack my headset. No power here. But the iPhone, I do care if you hack my iPhone. It plays a big role in communication.

When it comes down to it the iPhone is really just a server from your operations center shrunk down a bit. You’re walking around with a full BSD variant here, be aware of that fact. You wouldn’t install random, untrusted applications on your server in the op center, don’t do it on the server in your pocket without carefully exploring the source (code or person). Common sense. Plain and simple.

Verifying the source is only one way to protect yourself. You might still get hacked but at least you didn’t do the dirty work for the kiddie.

Now back to Jarno. Personally I would rather mod my iPhone rather than leave it stock. One of the open doors used by the mod community was a TIFF exploit. A TIFF exploit that allowed any arbitrary website to execute arbitrary code on my phone. The mod used the exploit to gain entry to the system and then closed the door behind itself. Had I not used the trusted exploit to mod my iPhone some random guy in Russia could be using it to server porn. All without me installing some random kids malicious package. Just to be clear: I’m pretty sure my iPhone is “more secure” now than it was when I started. Perhaps that warning is mis-placed. If you aren’t a retard your iPhone will be may be more secure after you have hacked it using the existing mods.

Yes I have to be careful. Yes others should be careful. Understand that someone will be attempting to hack the device in your pocket as long as that aura of power exists. Read reviews of the application, explore the source code, verify the source (website/person). Change the password when you install SSH. Turn off unused services like AFSd and SSH. You know, just look up any UNIX best security practices guide and read through it, most of it will apply here. Then pick up any book about embedded security, all of that will apply. Now go back to the library and pickup a book on wireless security. Or instead of reading, which I hate, you could just stop being a dumbass.

I couldn’t find a reasonable place to drop this one so here: “is that an iPhone in your pocket or did I just Trojan your Troy?” [2]

[1] The iPhone is actually all-knowing as well but I didn’t want to debate the omnipotence of the device. Debating over its powers only serves to anger the iPhone.

[2] This is not funny.

[q] I’m not trying to pick on eleven year-olds here. Twelve y/o works just as well. Eleven just seems like a good age for people to get interested in computer security and they also seem to discover capitalization and leet speak.

Continue reading »]]> Well like any good end-user I immediately installed the latest version of OS X without looking for problems others were having. Well my friend at work, Chris Ashworth, pointed out that my install didn’t list Windows shares in the Finder window under “Shares”. I was only seeing Bonjour systems and didn’t have the “All…” item like he had. Being a computer guy I was obligated to waste entirely to much time figuring out such a small problem. I tried all sorts of things like enabling file sharing (which should have zero impact), entering the SMB system through finder using command+k, and staring at the wall for 45 minutes. None of this helped.

Finally today I re-visited my firewall settings in the security preference pane. I, once again like any good user, had immediately turned on the second option blocking all ports except SSH which I had enabled in the sharing preference pane. I tried the first option, allow all traffic, and low and behold a few seconds later the “All…” item had appeared in Finder and clicking it revealed numerous Windows shares. File selection windows also provided access to the Windows shares. Strange right?

Now I’m no security expert, but having to turn off the firewall to browse for Windows shares seems sub-optimal. Of course given the tiff exploit I just posted about here, I’m beginning to wonder if Apple needs to shift their focus back to security a bit. I’m sure someone at Apple knows something about security and testing. Or did Apple spend the security budget on the 200+ patents in the iPhone?

On a side note, I have forgotten how much fun troll baiting (no jokes – too easy) actually is.

Update: Sometimes being sooooo right is a bad thing

Continue reading »]]> We in the security community have been trying to explain the benefit of MAC to developers in the embedded device arena for awhile now. Maybe if people keep threatening devices with radio chips and tons of proprietary crap the embedded developers will jump onboard. Motorola has been using SELinux/SEBSD on the A1200 and other devices for awhile now. Given the high-level view of the policy and lack of knowledge about the proprietary software and architecture driving the device I can’t really jump to any conclusions about the completeness of their policy but they are at least trying.

The reason I’m mentioning this is the most recent tiff exploit in the iPhone. Some hackers (the good kind) got ahold of it and used it to slip Installer.app on the iPhone. They were even kind enough to close the door they come in through; the exploit patches the vulnerability after it has installed Install.app.

I know this is SELinux and not SEBSD, although these permissions are in both IIRC, but lets try to count the permissions SELinux would have at its disposal to stop such an “attack”:

• memory protection
• file write protection (although Erica Sadun says this is done by “reassigning the root of the file tree”, whatever the hell that means… chroots? bind mounts? namespaces?)
• execute
• execute_no_trans

Listing these permissions is great, but what if Apple had needed Safari to download and install updates? Perhaps they could use a small app trusted to verify that Apple had signed the apps. Protect this app and it’s resources via SELinux and you’re golden.

I believe that DRM and security are hard to enforce when the keys are in the hands of the users. Someone will likely figure out how to view the filesystem or at least how to access it by sniffing USB traffic or looking at the hardware being used (in the case of DVD players etc). In this case, if you created a kernel that refused to boot in permissive mode would that be sufficient? Perhaps not, they could feasibly load their own kernel but that would be much more difficult given a properly architected MAC policy protecting the kernel itself.

Continue reading »]]> I reckon about three people a day enter the #selinux channel on freenode, ask a question, and than leave a few minutes later without giving anyone a chance to respond. Since no question askers read the topics or have the time to idle I figured I’d start posting their questions here. There is a good chance I won’t be able to answer them without more detail, but hell, its gotta be better than nothing (maybe). This quote is from the IRC channel so forgive the formatting.

how can i give a user read access to the /etc/mail (etc_mail_t) sendmail.cf?
when i try to connect to sendmail: NOQUEUE: SYSERR(rattler):
/etc/mail/sendmail.cf: line 0: cannot open: Permission denied


On a targeted system a “user”, as in the traditional Unix sense, is not confined in any manner. On a default FC6 install I can read /etc/mail/sendmail.cf with no denials in enforcing mode with any user logged in at the local console or via SSH.

So given the fact that any user can read the file I can only assume you mean the daemon itself. Well, once again on a default system, the sendmail daemon can read the file you specified. On my system the file has the type:

[spencer@sshimko-fc6 ~]$ ls -Z /etc/mail/sendmail.cf
-rw-r--r-- root root system_u:object_r:etc_mail_t:s0 /etc/mail/sendmail.cf


Make sure your file is labeled similarly. If not, run “restorecon /etc/mail/sendmail.cf” and restart the mail service. If this still doesn’t work could you please give more details?

Continue reading »]]> OK I’m going to go ahead and post this in the hopes it forces me to finish the series. Check back for updates. Not going to be this weekend, but by next weekend I promise. I’ve had the thoughts saved since I started part 1, but things kinda went awry (marriage, and then things just went downhill from there ). Regardless here is a teaser of the final segment of the series. BTW, if you guys actually cared you woulda hounded me to finish. Still, I promise I’ll finish up this segment this week.

Now back into the role of glibc. The role of glibc was defined well before mature mandatory access controls like SELinux came into the Linux picture. It was defined in a general fashion that allowed it to be extended by a few userland modifications and of course the kernel support discussed in the last article.

__libc_enable_secure in rtld.c (responsible for most of the runtime linking environment cleansing)

-How does SELinux solve this problem?
-I will delve into the details… security_bprm_secureexec in binfmt_elf.c
-AT_SECURE actually enforced by glibc elf/dl-support.c and elf/dl-sysdep.c
-Static apps have no problems (aside from the usual problems)
-The linker is the only _real_ threat for dynamically linked apps.
-OK so the people that implemented SELinux were smart so we’re safe right?
-Delve into problems with shell scripts, interpreted code, etc

Continue reading »]]> Fedora 7 has been officially released. Hurry and get yours while they last. I expect Brickwall support (read -> free SELinux tools) to be out momentarily. Hmm…. I’ll go ahead and change this to FC 8 just to keep ahead of the trend

Anyways the Fedora Core 7 (FC7) release of Brickwall can be found here when available.

Continue reading »]]> Two blogs ago I felt the urge to promote something my team was working on at Tresys that was only available for Red Hat Enterprise Linux 4. Well I’m pleased to announce Tresys has released a new version of our Brickwall Security Suite for Fedora Core 6. Not only our standard version, but our professional version as well!

The professional version adds additional SELinux targets, aka protects additional services and daemons, and adds the ability to create a custom policy with little to no knowledge of SELinux.

I highly suggest Fedora users start checking out Brickwall as opposed to listening to most bloggers that tell you to just “disable SELinux by setting the Grub command line to selinux=0″. This is a far superior solution since you have all the security benefits of SELinux with an amazing amount of configurability and ease-of-use.

Check it out.