EasyApache4 symlink race protection

[ThinIce]

Yes exactly. The patch directory answers this question for those capable of reading it, so a link to the current one on the docs page at least would be handy but I do feel it would be worth stating in plain English.

The only other question that immediately occurs as bound to arise is how much (if any) lag you expect for publishing kernel updates to your repo once these are released by upstream.

Many thanks

 

[ThinIce]

At the risk of looking like I've completely lost the plot... is the mirror at Index of /cpanelsync/repos/CentOS/6/cPkernel/x86_64 missing the cPkernel.repo file currently?

 

[ThinIce]

I took a guess at the contents of the cPkernel.repo file

[cpanel-kernel]
name=cPanel kernel
type=rpm-md
baseurl=http://httpupdate.cpanel.net/cpanelsync/repos/CentOS/6/cPkernel/x86_64
gpgcheck=1
gpgkey=https://securedownloads.cpanel.net/cPanelPublicRPMKey.asc
enabled=1

This worked after accepting the key and rebooting into the new kernel on a pv test vm running on Rackspace cloud.

 

[cPanelMichael]

At the risk of looking like I've completely lost the plot... is the mirror at Index of /cpanelsync/repos/CentOS/6/cPkernel/x86_64 missing the cPkernel.repo file currently?

I've confirmed cPkernel.repo is missing from the download location referenced in that document. I've opened a case with our documentation team to clarify the correct download path to this file, and I'll update this thread once the updated document is published.

In addition, I've asked for clarifications regarding your other questions, and I'll update this thread with more information as soon as it's available.

Thank you.

 

[ThinIce]

Looks like the docs at How to Harden Your cPanel System's Kernel - cPanel Knowledge Base - cPanel Documentation have now been updated with the correct location for the .repo file, many thanks.

 

[cPanelMichael]

Hello,

Yes, to update, the document is now updated to reflect the correct download path:

https://securedownloads.cpanel.net/cPkernel/cPkernel.repo

Thanks!

 

[cPanelMichael]

The only other question that immediately occurs as bound to arise is how much (if any) lag you expect for publishing kernel updates to your repo once these are released by upstream.

Hello @ThinIce,

The plan is to have the kernel automatically apply the patch, build, and publish itself. However, this is still a work in-progress.

Thank you.

 

[quizknows]

Not really suggesting a feature. I think this is more of a server administrator's discretion.

But is my suggestion actually true? The whole symlink "issue" isn't so much an issue with server security, it's just a basic misunderstanding of file permissions, something that Linux already addresses. World readable files are world readable. Why get mad at the system for allowing other users to read world readable files?

Granted, some files (most?) don't contain sensitive enough information to worry if they are world readable. A static .html file on your web hosting account might be world-readable... but if I go to your website and read the source... I get the same thing. Changing static files to 640 where the files are part of the nobody group doesn't change anything, because nobody has still got to be able to read the files (where nobody is the web server user). But there shouldn't be anything that sensitive in a static HTML document anyway.

I think a lot of us race around trying to find a solution to a problem instead of working to understand the problem and figuring out if the problem is really the problem.

The symlink hack isn't just a linux file perms issue; it's an Apache issue. World readable isn't the only thing in play here. Just because a file is world readable doesn't make it open to everyone if the directory it falls under is not world readable (or technically, is not world executable). I could have a file set to 777 but if the directory it's in is 700 then only the owner of that dir can actually manipulate or read the file inside it.

The issue comes in because public_html dirs are set to user:nobody, 750. In other words, not world readable. Obviously that's a good thing, however, by using apache to follow a symlink, you gain access to everything "nobody" (Apache) can read. I've worked abuse desks for a long time and this was a huge issue until the rack911/bluehost patches came along. I cannot tell you how many hours I spent restoring peoples backups or even hand cleaning code and databases. You would think that html/php files shouldn't contain sensitive data, but in the case of webapps, they almost always have the DB creds, and that's all you need to hack each site. And you can't just view-source on a php file and get code that's not programmed to display, otherwise every WP site on the internet could be hacked pretty much instantly.

I know in a perfect world people would use Kernel level protections but we can't just force them on people. I know everyone calls the bluehost patch a "last resort" but believe it or not I've seen it do its job extremely well on thousands of servers. Of the many servers I cleaned/fixed before that patch, I've never had to clean one after applying that patch.

I'm glad to see I can finally use ModSecurity with RUID2. This works for me on my own servers, but unfortunately, it's not a config I can force on thousands of users.

I hope none of this sounds rude, just trying to clarify some things as this "hack" is frequently misunderstood.

Also in reference to a previous post of yours, setting php files to 600 (at least ones like wp-config) could certainly help mitigate this. However in this case without RUID2, apache would still need read access to any files it has to serve (images etc) so those would have to be left with higher perms (not a security issue, but more an issue of confused users when php files work as 600 but other stuff doesn't).